[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] Loss of MSVC support

From: Eric S. Raymond
Subject: Re: [groff] Loss of MSVC support
Date: Tue, 12 Feb 2019 22:31:36 -0500
User-agent: Mutt/1.9.4 (2018-02-28)

Keith Marshall <address@hidden>:
> > I think the Open Group would disagree with you on this.
> >
> That's an entirely specious argument!  The requirement that a POSIX
> conforming implementation must provide stdlib.h is not commutative;
> Microsoft have always provided stdlib.h, even with their MS-DOS C
> compilers, (dating back to the mid-1980s, and thus pre-dating not only
> MSVC, but even Windows itself); in no way does this imply that either
> MS-DOS, or MS-Windows could, by any stretch of the imagination, be
> classified as a POSIX conforming system.

We seem to be talking different languages. But I'm not going to argue maps;
the important thing is the territory.
> > You seem to be saying that we *cannot* require C99/POSIX conformance
> > from toolchains on target systems without critical breakage.
> That's exactly what I'm saying.  POSIX requires fork(2); Windows doesn't
> support it.  Where groff sets up a pipeline, using fork(2) and exec(3),
> with I/O hook-up performed between, Windows *must* perform the I/O
> hook-up in the parent, then call spawn(), (or the significantly uglier
> CreateProcess()), to invoke the child, and then revert the effect of the
> I/O hook-up in the parent.  There is no other way of getting around this
> Windows limitation; that's the purpose of the bulk of groff's
> Windows-specific code, and the spawn() API has remained substantially
> unchanged, in over 20 years.

Well, that's a showstopper, then.  I won't pursue the matter.
                <a href="";>Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute:
Please visit their site and donate: the civilization you save might be your own.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]