Re: m4-1.4.7: inconsistency in src/m4.h

[Martin Koeppe]

Hi Eric,

On Fri, 13 Oct 2006, Eric Blake wrote:

> OK, you are right that POSIX states that <unistd.h> must define
> _POSIX_VERSION.  And non-POSIX platforms, such as Mingw, are in their best
> interest to advertise that they are not POSIX compliant by having
> <unistd.h> leave this undefined.
>
> My question is whether having m4 provide the builtin __unix__ is even the
> right thing for Interix.  It's a shame that there are so many viable
> porting targets for Windows.  Mingw, for example, implements system(2) by
> calling Windows cmd.exe instead of /bin/sh, therefore, I made sure that
> when M4 is compiled for mingw, it provides the builtin __windows__ instead
> of __unix__.  On the other hand, cygwin intentionally strives for Linux
> compatibility, and having m4 provide the builtin __unix__ is absolutely
> the right thing to do.  Does Interix provide a /bin/sh that is good enough
> for system(2), and therefore m4's syscmd builtin, to really behave like a
> true Unix system?  Perhaps it would be better if Interix stuck with
> __windows__?  But since Interix does define _POSIX_VERSION in <unistd.h>,
> it is worth a shot to let it behave like a unix implementation.

I now see your point. But yes, if for cygwin it is absolutely ok to 
have __unix__, then for interix it's double absolutely ok to have 
__unix__ :-). interix, which should be seen as just another unix, is 
much more POSIX conformant than cygwin as far as the kernel is 
concerned. You have a case sensitive file system, chroot() and SETUID 
bits for example. The userland, well ..., that's why I build m4 for 
it, to get it better :-)

> > The problem was on src/builtin.c. The very first #include is "m4.h", and
> > there the only #include before the test is "config.h", so no chance for
> > <unistd.h> I think.
> >
> > On other platforms the compiler may #define unix or such itself, so the
> > test succeeds. Indeed if I would use the MS compiler, this would be the
> > case according to docs, but with gcc, it apparently isn't.
>
> gcc has a set of pre-defined macros according to the platform it is
> targeting.  The fact that "unix" is not one of them on Interix is an
> interesting observation; especially since on Cygwin, gcc DOES define
> "unix" by default.

Yes, this may be a fault on my side, but I didn't yet have a close 
look.

> > > By the way, M4 can include <unistd.h> blindly, thanks to gnulib
> > > portability code (and in fact, already does so, via "unistd--.h").  There
> > > is no need to check for HAVE_UNISTD_H, only to rearrange the
> > > gnulib header inclusion to occur prior to the platform macro detection
> > > section.

This one I don't yet understand. Looking at "unistd--.h" shows that 
<unistd.h> is also included unconditioned. Maybe the test should be 
made here? I couldn't find any file named "unistd.h" in m4's source 
which could be included instead, if the system doesn't have one.
So what will happen if you "delete" your system's <unistd.h> before 
building m4?

And if <unistd.h> is absolutely needed, then configure should stop 
when not finding it, saying that platforms without it aren't 
supported, shouldn't it? At least as it checks for it...

> Here's what I'm installing.  Let me know if you would be willing to try a
> snapshot tarball on Interix before I release 1.4.8 in the next few weeks.

Yes, sure I can / am willing to do that.

Martin