Fix for [f]statfs64/[f]statfs aliasing patch
Commit Message
This patch is a fix to my earlier statfs patch
(https://sourceware.org/ml/libc-alpha/2016-11/msg00360.html) that allowed
statfs/fstatfs to be aliases of statfs64/fstatfs64 but broke the alpha
build. When doing this aliasing it is necessary that the prototypes of
[f]statfs not be seen because they differ from that of [f]statfs64. They
have the same structures but different names, so GCC will complain when
doing the aliasing. My initial patch used a #define to hide the prototypes
of [f]statfs and __[f]statfs when defining [f]statfs64 but I hadn't noticed
that when __ASSUME_STATFS64 is 0, the [f]statfs64 function calls __[f]statfs
and if we have changed the name of this with a define then [f]statfs64 will
call the wrong (and undefined) function. This only happens on alpha which is
the only platform where __ASSUME_STATFS64 is 0.
This patch fixes the problem by only hiding the [f]statfs definitions if
STATFS_IS_STATFS64 is set to non-zero, which is also the only time we do the
aliasing. To do this I had to change the order of the includes because we
cannot check STATFS_IS_STATFS64 until after we have included kernel_stat.h
but we must do it before including sys/stat.h which is where the [f]statfs
prototypes are defined.
I have tested this and verified that it builds for alpha (using the
build-many-glibcs.py script) and also verified it builds and has no testsuite
regressions on x86 and aarch64.
OK to checkin?
Steve Ellcey
sellcey@caviumnetworks.com
2016-11-23 Steve Ellcey <sellcey@caviumnetworks.com>
* sysdeps/unix/sysv/linux/fstatfs64.c: Reorder include files,
only alias fstatfs and __fstatfs if STATFS_IS_STATFS64 is non-zero.
* sysdeps/unix/sysv/linux/statfs64.c: Ditto for statfs and __statfs.
Comments
On Nov 23 2016, Steve Ellcey <sellcey@caviumnetworks.com> wrote:
> This patch fixes the problem by only hiding the [f]statfs definitions if
> STATFS_IS_STATFS64 is set to non-zero, which is also the only time we do the
> aliasing. To do this I had to change the order of the includes because we
> cannot check STATFS_IS_STATFS64 until after we have included kernel_stat.h
> but we must do it before including sys/stat.h which is where the [f]statfs
> prototypes are defined.
A simpler approach would probably be to move the #undef up directly
after the include.
Ok either way.
Andreas.
@@ -16,20 +16,23 @@
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
+#include <errno.h>
+#include <string.h>
+#include <stddef.h>
+#include <sysdep.h>
+#include <kernel_stat.h>
+
/* Hide the prototypes for __fstatfs and fstatfs so that GCC will not
complain about the different function signatures if they are aliased
to __fstat64. If STATFS_IS_STATFS64 is not zero then the statfs and
statfs64 structures have an identical layout but different type names. */
-#define __fstatfs __fstatfs_disable
-#define fstatfs fstatfs_disable
-
-#include <errno.h>
-#include <string.h>
+#if STATFS_IS_STATFS64
+# define __fstatfs __fstatfs_disable
+# define fstatfs fstatfs_disable
+#endif
#include <sys/statfs.h>
-#include <kernel_stat.h>
-#include <stddef.h>
-#include <sysdep.h>
+
#include <kernel-features.h>
/* Defined in statfs64.c. */
@@ -16,20 +16,23 @@
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
+#include <errno.h>
+#include <string.h>
+#include <stddef.h>
+#include <sysdep.h>
+#include <kernel_stat.h>
+
/* Hide the prototypes for __statfs and statfs so that GCC will not
complain about the different function signatures if they are aliased
to __stat64. If STATFS_IS_STATFS64 is not zero then the statfs and
statfs64 structures have an identical layout but different type names. */
-#define __statfs __statfs_disable
-#define statfs statfs_disable
-
-#include <errno.h>
-#include <string.h>
+#if STATFS_IS_STATFS64
+# define __statfs __statfs_disable
+# define statfs statfs_disable
+#endif
#include <sys/statfs.h>
-#include <kernel_stat.h>
-#include <stddef.h>
-#include <sysdep.h>
+
#include <kernel-features.h>