Wendy Palm <[EMAIL PROTECTED]> writes: > ! # if UINT_MAX == _UINT_MAX_64 > ! typedef unsigned int md5_uint32; > ! # else > ! /* The following line is intended to evoke an error. > ! Using #error is not portable enough. */ > ! "Cannot determine unsigned 32-bit data type." > ! # endif
Sorry, I don't quite follow the need for this change. Does that host have a working <limits.h>? If so, <limits.h> should define UINT_MAX, USHRT_MAX, and ULONG_MAX. Is the problem that there is no 32-bit integer type on that platform? I worry that the code won't work in that case: it really assumes the presence of a 32-bit int. I have the same questions about the similar change to src/shred.c. > ! bin_PROGRAMS = \[ chgrp chown chmod cp dd dircolors du \ Ouch. I suspect that this will break 'make' programs on other hosts, as there's no backslash-escape mechanism like that in standard 'make'. What exactly is the problem if you use it without the backslash? Perhaps there's another way to work around the problem. > + #ifdef _UNICOS > + int endusershell (); > + int setusershell (); > + #else > void endusershell (); > void setusershell (); > + #endif /* _UNICOS */ I notice that su.c already does this: /* Hide any system prototype for getusershell. This is necessary because some Cray systems have a conflicting prototype (returning `int') in <unistd.h>. */ #define getusershell _getusershell_sys_proto_ Does a similar trick work for endusershell and setusershell? That would be more consistent. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
