> Wrong place for the fix. POSIX requires that inclusion of <stdio.h> > exposes size_t. Therefore, the real fix is to make the gnulib > replacement header stdio.in.h pull in <stddef.h> to define size_t when > building for SunOS4; at which point every single other file that relies > on the POSIX requirement, like hash.h, will work out of the box.
Good point! Grep does include <stdio.h>, but it does not contain a stdio.in.h file. Should it? > The memmove module was marked obsolete (meaning it is only useful on > unsupported machines, because no modern system has any bugs in it). Any > package that still wants to compile on SunOS4 merely need request use of > the obsolete modules after all. Same story for atexit. Interesting. What would I need to do with the grep source for changing that locally? > > A slightly more complicated issue is in src/dfa.c. The is* functions are > > used, but they are macros on SunOS4 and if you undefine them (which is > > not the case in src/dfa.c), you find there are no functions of the same > > name in libc. In fact I am used to that from other older systems as well, > > so making that more portable would be useful for others, too. > > Gnulib could indeed work around this (there are other cases where gnulib > provides functions as required by POSIX when the library provided only > macros), but again, someone has to do the work, and it won't be me > because I don't have access to a SunOS4 platform. Furthermore, such a > module would probably be marked obsolete, so again, you're back at the > situation of needing to explicitly request obsolete modules before a > package would target SunOS4. If there is a rather standardized way how to include obsolete modules for a GNU package to ease the job, then that's a very nice solution to the problem for those who still run systems requiring them. Michael
