Re: Patch for coreutils 4.5.7 on Mac OS X

[Petter Reinholdtsen]

[Paul Eggert]
> The <sys/types.h> part of that change seems reasonable, but the
> other change (enclosed below) looks like a maintenance nightmare.
> We don't want to have that kind of #ifdef in the code, since we'd
> then have to add another #ifdef for every kind of processor on such
> operating systems.

I partly agree.  Hardcoding the processor type is a the start of
maintainence nightmare, but making the includes match the protection
should not be.

Why does the code read '#if HAVE_SYSCTL_H then #include
<sys/param.h>'?  This do not make sense.  The header file included is
<sys/param.h>, so the test should use HAVE_SYS_PARAM_H.

> How does MacOS solve this problem?  Does it have a different system
> call that returns the processor name?

After tracing /usr/bin/uname and running 'strings' on the binary, I
suspect MacOS hardcoded the return value.  The binary contains <10
strings, and one of them is 'powerpc'.

> If not, perhaps a better workaround would be something like this:
> 
>  char const *default_processor = 0;
> #ifdef PROCESSOR
>  default_processor = PROCESSOR;
> #endif
> 
> and then use "else element = default_processor;" in the mainline code.
> You can then compile with -DPROCESSOR="\"`uname -p`\"'.  This sort of
> thing could be Autoconf'ed, though it is a bit circular....

This sounds like a good idea to me. :)

configure chould call '/usr/bin/uname -p' and use that as the default
value.  That is in effect what I am doing.  :-)