Re: coreutils-6.0 on BeOS (9)
Bruno Haible [EMAIL PROTECTED] writes: Compiling the current coreutils CVS on MacOS X 10.3.9 now gives this error: stat.c: In function `print_statfs': stat.c:416: error: incompatible types in initialization Thanks for reporting this. Oops, this is another MacOS problem (I got misled by the subject line and thought I was done with MacOS). I hope it's the last one for now, but with this many fixes I probably messed something up. Anyway, I installed this patch, which I hope fixes things. 2006-08-29 Paul Eggert [EMAIL PROTECTED] * src/stat.c (HAVE_STRUCT_STATXFS_F_FSID_VAL, FSID_VAL): New macros, to work around a Mac OS X porting problem reported by Bruno Haible in http://lists.gnu.org/archive/html/bug-coreutils/2006-08/msg00308.html. (print_statfs): Use them. * m4/stat-prog.m4 (cu_PREREQ_STAT_PROG): Check for __val versus val components of fsid. Omit some checks that stat.c doesn't care about. --- src/stat.c 24 Aug 2006 21:47:37 - 1.99 +++ src/stat.c 29 Aug 2006 21:53:01 - @@ -19,6 +19,8 @@ #include config.h +/* Keep this conditional in sync with the similar conditional in + ../m4/stat-prog.m4. */ #if (STAT_STATVFS \ (HAVE_STRUCT_STATVFS_F_BASETYPE || HAVE_STRUCT_STATVFS_F_FSTYPENAME \ || (! HAVE_STRUCT_STATFS_F_FSTYPENAME HAVE_STRUCT_STATVFS_F_TYPE))) @@ -69,6 +71,7 @@ #if USE_STATVFS # define STRUCT_STATVFS struct statvfs # define HAVE_STRUCT_STATXFS_F_FSID___VAL HAVE_STRUCT_STATVFS_F_FSID___VAL +# define HAVE_STRUCT_STATXFS_F_FSID_VAL HAVE_STRUCT_STATVFS_F_FSID_VAL # define HAVE_STRUCT_STATXFS_F_TYPE HAVE_STRUCT_STATVFS_F_TYPE # if HAVE_STRUCT_STATVFS_F_NAMEMAX # define SB_F_NAMEMAX(S) ((S)-f_namemax) @@ -111,14 +114,22 @@ statfs (char const *filename, struct fs_ # define f_ffree free_nodes # define STRUCT_STATVFS struct fs_info # define HAVE_STRUCT_STATXFS_F_FSID___VAL 0 +# define HAVE_STRUCT_STATXFS_F_FSID_VAL 0 # define STATFS_FRSIZE(S) ((S)-block_size) # else # define STRUCT_STATVFS struct statfs # define HAVE_STRUCT_STATXFS_F_FSID___VAL HAVE_STRUCT_STATFS_F_FSID___VAL +# define HAVE_STRUCT_STATXFS_F_FSID_VAL HAVE_STRUCT_STATFS_F_FSID_VAL # define STATFS_FRSIZE(S) 0 # endif #endif +#if HAVE_STRUCT_STATXFS_F_FSID___VAL +# define FSID_VAL __val +#elif HAVE_STRUCT_STATXFS_F_FSID_VAL +# define FSID_VAL val +#endif + #ifdef SB_F_NAMEMAX # define OUT_NAMEMAX out_uint #else @@ -404,13 +415,13 @@ print_statfs (char *pformat, size_t pref case 'i': { -#if HAVE_STRUCT_STATXFS_F_FSID___VAL - uintmax_t val0 = statfsbuf-f_fsid.__val[0]; - uintmax_t val1 = statfsbuf-f_fsid.__val[1]; +#ifdef FSID_VAL + uintmax_t val0 = statfsbuf-f_fsid.FSID_VAL[0]; + uintmax_t val1 = statfsbuf-f_fsid.FSID_VAL[1]; uintmax_t fsid = (val1 - + (sizeof statfsbuf-f_fsid.__val[1] sizeof fsid - ? val0 (CHAR_BIT * sizeof statfsbuf-f_fsid.__val[1]) + + (sizeof statfsbuf-f_fsid.FSID_VAL[1] sizeof fsid + ? val0 (CHAR_BIT * sizeof statfsbuf-f_fsid.FSID_VAL[1]) : 0)); #else uintmax_t fsid = statfsbuf-f_fsid; --- m4/stat-prog.m4 21 Aug 2006 07:30:47 - 1.7 +++ m4/stat-prog.m4 29 Aug 2006 21:53:01 - @@ -52,16 +52,28 @@ $ac_includes_default # endif #endif - AC_CHECK_MEMBERS([struct statfs.f_basetype],,,[$statxfs_includes]) - AC_CHECK_MEMBERS([struct statvfs.f_basetype],,,[$statxfs_includes]) AC_CHECK_MEMBERS([struct statfs.f_fstypename],,,[$statxfs_includes]) - AC_CHECK_MEMBERS([struct statvfs.f_fstypename],,,[$statxfs_includes]) - AC_CHECK_MEMBERS([struct statfs.f_type],,,[$statxfs_includes]) - AC_CHECK_MEMBERS([struct statvfs.f_type],,,[$statxfs_includes]) - AC_CHECK_MEMBERS([struct statfs.f_fsid.__val],,,[$statxfs_includes]) - AC_CHECK_MEMBERS([struct statvfs.f_fsid.__val],,,[$statxfs_includes]) - AC_CHECK_MEMBERS([struct statfs.f_namemax],,,[$statxfs_includes]) - AC_CHECK_MEMBERS([struct statvfs.f_namemax],,,[$statxfs_includes]) - AC_CHECK_MEMBERS([struct statfs.f_namelen],,,[$statxfs_includes]) - AC_CHECK_MEMBERS([struct statvfs.f_namelen],,,[$statxfs_includes]) + dnl Keep this long conditional in sync with the USE_STATVFS conditional + dnl in ../src/stat.c. + if test $ac_cv_header_sys_statvfs_h = yes +{ AC_CHECK_MEMBERS( + [struct statvfs.f_basetype, +struct statvfs.f_fstypename, +struct statvfs.f_type],,, + [$statxfs_includes]) + test $ac_cv_member_struct_statvfs_f_basetype = yes || + test $ac_cv_member_struct_statvfs_f_fstypename = yes || + { test $ac_cv_member_struct_statvfs_f_type = yes + test $ac_cv_member_struct_statfs_f_fstypename != yes; }; }; then +AC_CHECK_MEMBERS( + [struct statvfs.f_fsid.__val, struct statvfs.f_fsid.val, + struct statvfs.f_namelen, struct statvfs.f_namemax],,, + [$statxfs_includes]) + else +AC_CHECK_MEMBERS( + [struct
Re: coreutils-6.0 on BeOS (9)
Paul Eggert wrote: 2006-08-23 Paul Eggert [EMAIL PROTECTED] * src/stat.c (HAVE_STRUCT_STATXFS_F_FSID___VAL): Define. This macro was being used without being defined. Compiling the current coreutils CVS on MacOS X 10.3.9 now gives this error: stat.c: In function `print_statfs': stat.c:416: error: incompatible types in initialization Preprocessed output snippet: # 416 stat.c unsigned long long int fsid = statfsbuf-f_fsid; The reason is that fsid_t is defined like this: typedef struct fsid { int32_t val[2]; } fsid_t; The code that tests HAVE_STRUCT_STATXFS_F_FSID___VAL should also have an alternative that tests HAVE_STRUCT_STATXFS_F_FSID_VAL (and augment stat-prog.m4 accordingly). Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.0 on BeOS (9)
Hi Bruno, Thanks for all of your recent BeOS porting work. We've received very few reports about BeOS problems, other than yours. I'm curious: what's your motivation for using it? Bruno Haible [EMAIL PROTECTED] wrote: ... After producing this patch, I noticed that the replacement 'statfs' that I put into stat.c would also be useful for df -i (because the f_files, f_ffree numbers in 'struct statvfs' are only dummies whereas those in 'struct fs_info' are real ones). So, more unification between lib/fsusage.c and src/stat.c seems desirable. I propose to create a 'struct gnu_statvfs' that contains the usual POSIX fields plus 'char f_fstypename[]', containing the filesystem name, and a few minor fields that src/stat.c uses, and to transform the lib/fsusage.c code into a gnu_statvfs function that could be used by both df and stat. Does this seem worthwhile? Yes, it does. Can the SVR2 code (this is the only code in lib/fsusage.c that makes use of the 'disk' argument) be dropped in the process? I suspect it is dead, but not knowing, it'd be prudent to add a configure-time AC_MSG_FAILURE message like the one in ftruncate.m4. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.0 on BeOS (9)
Jim Meyering asks: I'm curious: what's your motivation for using it? Portability testing. Through the BeOS porting, I found the following problems not limited to BeOS: - check-AUTHORS: applies to any platform that doesn't build all of the programs. - mbchar.h problem: applies to any platform that has mbrtowc() but no wctype.h. - fchmod: applies to any platform without fchmod(); that includes mingw and djgpp. - fsusage.m4: applies to the Hurd. - printf of f_fsid: applies to any platform where f_fsid is not 64 bits. - fchdir: applies to any platform without fchdir(); that includes mingw and djgpp. Other people do portability testing differently. The more different testing strategies are used, the better is quality of the result. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-6.0 on BeOS (9)
The 'df' program needs a small adjustment so that the 'struct statvfs' of BeOS can be used. And the 'stat' program needs porting too; here the 'struct statvfs' cannot be used, because it does not have a f_type or f_fstypename or similar field. Btw, the #ifdef __GLIBC__ in m4/fsusage.m4 looks wrong also for the Hurd, because glibc/sysdeps/mach/hurd/statfs64.c does not appear to access /proc. After producing this patch, I noticed that the replacement 'statfs' that I put into stat.c would also be useful for df -i (because the f_files, f_ffree numbers in 'struct statvfs' are only dummies whereas those in 'struct fs_info' are real ones). So, more unification between lib/fsusage.c and src/stat.c seems desirable. I propose to create a 'struct gnu_statvfs' that contains the usual POSIX fields plus 'char f_fstypename[]', containing the filesystem name, and a few minor fields that src/stat.c uses, and to transform the lib/fsusage.c code into a gnu_statvfs function that could be used by both df and stat. Does this seem worthwhile? Can the SVR2 code (this is the only code in lib/fsusage.c that makes use of the 'disk' argument) be dropped in the process? 2006-08-19 Bruno Haible [EMAIL PROTECTED] * m4/fsusage.m4 (gl_FILE_SYSTEM_USAGE): Don't consider BeOS statvfs as unusable. * src/stat.c (USE_STATVFS) [BeOS]: Set to 0. (STRUCT_STATVFS, statfs, f_fsid, f_blocks, f_bfree, f_bavail, f_bsize, STATFS_FRSIZE, f_files, f_ffree, STATXFS_FILE_SYSTEM_TYPE_MEMBER_NAME) [BeOS]: Define. --- m4/fsusage.m4.bak 2006-04-26 17:34:42.0 +0200 +++ m4/fsusage.m4 2006-08-19 17:00:54.0 +0200 @@ -1,4 +1,4 @@ -#serial 18 +#serial 19 # Obtaining file system usage information. # Copyright (C) 1997, 1998, 2000, 2001, 2003, 2004, 2005, 2006 Free Software @@ -50,10 +50,12 @@ # SVR4 AC_CACHE_CHECK([for statvfs function (SVR4)], fu_cv_sys_stat_statvfs, [AC_TRY_LINK([#include sys/types.h -#ifdef __GLIBC__ +#if defined __GLIBC__ !defined __BEOS__ Do not use statvfs on systems with GNU libc, because that function stats all preceding entries in /proc/mounts, and that makes df hang if even one of the corresponding file systems is hard-mounted, but not available. +statvfs in GNU libc on BeOS operates differently: it only makes a system +call. #endif #include sys/statvfs.h], [struct statvfs fsd; statvfs (0, fsd);], --- src/stat.c.bak 2006-07-09 19:20:43.0 +0200 +++ src/stat.c 2006-08-19 20:23:04.0 +0200 @@ -20,7 +20,8 @@ #include config.h #if (STAT_STATVFS \ - (HAVE_STRUCT_STATVFS_F_BASETYPE || ! HAVE_STRUCT_STATFS_F_FSTYPENAME)) + (HAVE_STRUCT_STATVFS_F_BASETYPE \ +|| (! HAVE_STRUCT_STATFS_F_FSTYPENAME ! HAVE_OS_H))) # define USE_STATVFS 1 #else # define USE_STATVFS 0 @@ -47,6 +48,8 @@ # include nfs/nfs_clnt.h # include nfs/vfs.h # endif +#elif HAVE_OS_H /* BeOS */ +# include fs_info.h #endif #include system.h @@ -79,6 +82,41 @@ # endif # define STATFS statfs # define STATFS_FRSIZE(S) 0 +# if HAVE_OS_H /* BeOS */ +/* BeOS has a statvfs() function, but it does not return sensible values + in the f_files, f_ffree, f_favail fields, and also does not have a + f_type/f_basetype/f_fstypename field. So we use 'struct fs_info' + instead. */ +# undef STRUCT_STATVFS +# define STRUCT_STATVFS struct fs_info +static int statfs (const char *filename, struct fs_info *buf) +{ + dev_t device = dev_for_path (filename); + if (device 0) +{ + errno = (device == B_ENTRY_NOT_FOUND ? ENOENT : + device == B_BAD_VALUE ? EINVAL : + device == B_NAME_TOO_LONG ? ENAMETOOLONG : + device == B_NO_MEMORY ? ENOMEM : + device == B_FILE_ERROR ? EIO : + 0); + return -1; +} + /* If successful, buf-dev will be == device. */ + return fs_stat_dev (device, buf); +} + /* The printf below expects f_fsid to be a 64-bit integer, but dev is only + 32-bit. So convert it to 'unsigned long long'. */ +# define f_fsid dev + (unsigned long long) 0 +# define f_blocks total_blocks +# define f_bfree free_blocks +# define f_bavail free_blocks +# define f_bsize io_size +# undef STATFS_FRSIZE +# define STATFS_FRSIZE(S) ((S)-block_size) +# define f_files total_nodes +# define f_ffree free_nodes +# endif #endif #ifdef SB_F_NAMEMAX @@ -94,6 +132,8 @@ #else # if HAVE_STRUCT_STATFS_F_FSTYPENAME # define STATXFS_FILE_SYSTEM_TYPE_MEMBER_NAME f_fstypename +# elif HAVE_OS_H /* BeOS */ +# define STATXFS_FILE_SYSTEM_TYPE_MEMBER_NAME fsh_name # endif #endif ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.0 on BeOS (9)
Btw, the #ifdef __GLIBC__ in m4/fsusage.m4 looks wrong also for the Hurd, because glibc/sysdeps/mach/hurd/statfs64.c does not appear to access /proc. /proc doesn't exist on GNU, never did. Cheers. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.0 on BeOS (9)
Bruno Haible [EMAIL PROTECTED] writes: The 'df' program needs a small adjustment so that the 'struct statvfs' of BeOS can be used. And the 'stat' program needs porting too; here the 'struct statvfs' cannot be used, because it does not have a f_type Thanks. While testing this on GNU/Linux I uncovered several other problems. At least one serious problem leading to undefined behavior was masked by a cast (arggh!!!) so I removed a lot of casts while I was at it. There is still some undefined behavior in there, with bad formats, but I ran out of time to fix this right now. Probably printf-parse or the code in printf.c should be applied. I don't think there are any buffer overruns on any real platforms, but still it should get fixed eventually. I installed the following combined patch. I also installed the gnulib patch you sent. I propose to create a 'struct gnu_statvfs' that contains the usual POSIX fields plus 'char f_fstypename[]', containing the filesystem name, and a few minor fields that src/stat.c uses, and to transform the lib/fsusage.c code into a gnu_statvfs function that could be used by both df and stat. Does this seem worthwhile? It would clean up the code, I think. Perhaps Jim has an opinion? Can the SVR2 code (this is the only code in lib/fsusage.c that makes use of the 'disk' argument) be dropped in the process? I don't know why we need that old code any more, and it'd be fine with me if it vanished. 2006-08-23 Paul Eggert [EMAIL PROTECTED] * src/stat.c (HAVE_STRUCT_STATXFS_F_FSID___VAL): Define. This macro was being used without being defined. (SB_F_NAMEMAX): Remove cast. (f_fsid) [BeOS]: Likewise. (OUT_NAMEMAX): Renamed from NAMEMAX_FORMAT, with a new meaning. All uses changed. (out_string, out_int, out_uint, out_uint_o, out_uint_x): New functions. (xstrcat): Remove. All uses changed to use the above functions. (print_statfs, print_stat): 2nd arg is now the prefix len, not the buffer len. All uses changed. Output '?', not '*', for unknown data or errors. Do not assume signed values can be interchanged with unsigned when printing. (print_statfs): For %i, print the fsid as a single int, not as a pair. (print_it): Quote invalid format better. 2006-08-23 Bruno Haible [EMAIL PROTECTED] * src/stat.c (STRUCT_STATVFS, statfs, f_fsid, f_blocks, f_bfree) [BeOS]: (f_bavail, f_bsize, STATFS_FRSIZE, f_files, f_ffree) [BeOS]: (STATXFS_FILE_SYSTEM_TYPE_MEMBER_NAME) [BeOS]: Define. --- src/stat.c 20 Aug 2006 15:17:28 - 1.97 +++ src/stat.c 23 Aug 2006 23:39:55 - @@ -48,6 +48,8 @@ # include nfs/nfs_clnt.h # include nfs/vfs.h # endif +#elif HAVE_OS_H /* BeOS */ +# include fs_info.h #endif #include system.h @@ -66,28 +68,63 @@ #if USE_STATVFS # define STRUCT_STATVFS struct statvfs +# define HAVE_STRUCT_STATXFS_F_FSID___VAL HAVE_STRUCT_STATVFS_F_FSID___VAL # define HAVE_STRUCT_STATXFS_F_TYPE HAVE_STRUCT_STATVFS_F_TYPE # if HAVE_STRUCT_STATVFS_F_NAMEMAX -# define SB_F_NAMEMAX(S) ((uintmax_t) ((S)-f_namemax)) +# define SB_F_NAMEMAX(S) ((S)-f_namemax) # endif # define STATFS statvfs # define STATFS_FRSIZE(S) ((S)-f_frsize) #else -# define STRUCT_STATVFS struct statfs # define HAVE_STRUCT_STATXFS_F_TYPE HAVE_STRUCT_STATFS_F_TYPE # if HAVE_STRUCT_STATFS_F_NAMELEN -# define SB_F_NAMEMAX(S) ((uintmax_t) ((S)-f_namelen)) +# define SB_F_NAMEMAX(S) ((S)-f_namelen) # endif # define STATFS statfs -# define STATFS_FRSIZE(S) 0 +# if HAVE_OS_H /* BeOS */ +/* BeOS has a statvfs function, but it does not return sensible values + for f_files, f_ffree and f_favail, and lacks f_type, f_basetype and + f_fstypename. Use 'struct fs_info' instead. */ +static int +statfs (char const *filename, struct fs_info *buf) +{ + dev_t device = dev_for_path (filename); + if (device 0) +{ + errno = (device == B_ENTRY_NOT_FOUND ? ENOENT + : device == B_BAD_VALUE ? EINVAL + : device == B_NAME_TOO_LONG ? ENAMETOOLONG + : device == B_NO_MEMORY ? ENOMEM + : device == B_FILE_ERROR ? EIO + : 0); + return -1; +} + /* If successful, buf-dev will be == device. */ + return fs_stat_dev (device, buf); +} +# define f_fsid dev +# define f_blocks total_blocks +# define f_bfree free_blocks +# define f_bavail free_blocks +# define f_bsize io_size +# define f_files total_nodes +# define f_ffree free_nodes +# define STRUCT_STATVFS struct fs_info +# define HAVE_STRUCT_STATXFS_F_FSID___VAL 0 +# define STATFS_FRSIZE(S) ((S)-block_size) +# else +# define STRUCT_STATVFS struct statfs +# define HAVE_STRUCT_STATXFS_F_FSID___VAL HAVE_STRUCT_STATFS_F_FSID___VAL +# define STATFS_FRSIZE(S) 0 +# endif #endif #ifdef SB_F_NAMEMAX -# define NAMEMAX_FORMAT PRIuMAX +# define OUT_NAMEMAX out_uint #else /* NetBSD 1.5.2 has neither f_namemax nor