[Top][All Lists]

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

Re: Cross-platform availability of header files

From: Peter Rosin
Subject: Re: Cross-platform availability of header files
Date: Fri, 15 Mar 2013 14:14:52 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 2013-03-15 05:05, Russ Allbery wrote:
> Zack Weinberg <address@hidden> writes:
>> I think we should try to come up with a principled cutoff for how old is
>> too old, though. I started this thinking POSIX.1-2001 (including XSI,
>> but maybe not any other options) was a reasonable place to draw the
>> line, but it turns out Android omits a bunch of that (and not the old
>> junk either) so it's not so simple.
>> "You can assume a C89 hosted environment" does still seem like a sound
>> assertion, though.
> It's also important not to exclude Windows, which sometimes is missing
> some things that are otherwise universal.  Autoconf can't probe on Windows
> *directly* (without using one of the UNIX-like portability shells, which
> often provide the missing bits as well), but the fact that Autoconf
> generates the conditionals (in config.h for example) is still extremely
> useful in combination with a hand-written that's used by
> Windows MSVC builds.
> (ssize_t was the thing I ran into most recently that Windows doesn't have
> but which is otherwise universal and required by POSIX.)

I just wanted to chime in with the fact that it's working just fine to
use one of said UNIX-like portability environments and have Autoconf
probe MSVC directly. I.e. no need for any handwritten
file. Having said that, it doesn't work for all projects of course,
but if it doesn't work and the project maintainer is willing it should
still be doable. I personally use this regularly and would hate to
see the support for it go away.

The bigger Windows problems will always be missing fork() or something
like that. The tool environment is easy in comparison (or it has been
solved by said UNIX-like environments is perhaps a truer statement).


reply via email to

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