On 10/29/07, Dražen Kačar <[EMAIL PROTECTED]> wrote:
> Micah Cowan wrote:
>
> > AFAIK, _no_ system supports POSIX 100%,
>
> AIX and Solaris have certified POSIX support. That's for the latest,
> IEEE Std 1003.1-2001. More systems have certified POSIX support for the
> older POSIX release.
>
> OTOH,
Micah Cowan wrote:
> AFAIK, _no_ system supports POSIX 100%,
AIX and Solaris have certified POSIX support. That's for the latest,
IEEE Std 1003.1-2001. More systems have certified POSIX support for the
older POSIX release.
OTOH, all POSIX releases have optional parts which don't have to be
imple
Micah Cowan <[EMAIL PROTECTED]> writes:
> I can't even begin to fathom why some system would fail to compile
> in such an event: _XOPEN_SOURCE is a feature request, not a
> guarantee that you'll get some level of POSIX.
Yes, but sometimes the system headers are buggy. Or sometimes they
work just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hrvoje Niksic wrote:
> Micah Cowan <[EMAIL PROTECTED]> writes:
>
>>> Or getting the definition requires defining a magic preprocessor
>>> symbol such as _XOPEN_SOURCE. The man page I found claims that the
>>> function is defined by XPG4 and links t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Daniel Stenberg wrote:
> On Fri, 26 Oct 2007, Micah Cowan wrote:
>
>>> I very much doubt it does, since we check for it in the curl configure
>>> script, and I can see the output from it running on Tru64 clearly state:
>>>
>>> checking for sigsetjmp
On Fri, 26 Oct 2007, Micah Cowan wrote:
I very much doubt it does, since we check for it in the curl configure
script, and I can see the output from it running on Tru64 clearly state:
checking for sigsetjmp... yes
Note that curl provides the additional check for a macro version in the
config
Micah Cowan <[EMAIL PROTECTED]> writes:
>> Or getting the definition requires defining a magic preprocessor
>> symbol such as _XOPEN_SOURCE. The man page I found claims that the
>> function is defined by XPG4 and links to standards(5), which
>> explicitly documents _XOPEN_SOURCE.
>
> Right. But w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hrvoje Niksic wrote:
> Micah Cowan <[EMAIL PROTECTED]> writes:
>
>> Note that curl provides the additional check for a macro version in
>> the configure script, rather than in the source; we should probably
>> do it that way as well. I'm not sure ho
Micah Cowan <[EMAIL PROTECTED]> writes:
> Note that curl provides the additional check for a macro version in
> the configure script, rather than in the source; we should probably
> do it that way as well. I'm not sure how that helps for this,
> though: if the above test is failing, then either it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Daniel Stenberg wrote:
> On Sat, 27 Oct 2007, Hrvoje Niksic wrote:
>
Do you say that Tru64 lacks both sigsetjmp and siggetmask? Are you
sure about that?
>>>
>>> That is the only system we are currently talking about.
>>
>> I find it hard
Daniel Stenberg <[EMAIL PROTECTED]> writes:
>> It is quite possible that the Autoconf test for sigsetjmp yields a
>> false negative.
>
> I very much doubt it does, since we check for it in the curl
> configure script,
Note that I didn't mean "in general". Such bugs can sometimes show in
one prog
On Sat, 27 Oct 2007, Hrvoje Niksic wrote:
Do you say that Tru64 lacks both sigsetjmp and siggetmask? Are you
sure about that?
That is the only system we are currently talking about.
I find it hard to believe that Tru64 lacks both of those functions;
for example, see
http://h30097.www3.hp.co
Micah Cowan <[EMAIL PROTECTED]> writes:
>> I know nothing of VMS. If it's sufficiently different from Unix that
>> it has wildly different alarm/signal facilities, or no alarm/signal at
>> all (as is the case with Windows), then it certainly makes sense for
>> Wget to provide a VMS-specific run_w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hrvoje Niksic wrote:
> Micah Cowan <[EMAIL PROTECTED]> writes:
>
>> Okay... but I don't see the logic of:
>>
>> 1. If the system has POSIX's sigsetjmp, use that.
>> 2. Otherwise, just assume it has the completely unportable, and not
>> even BSDi
Micah Cowan <[EMAIL PROTECTED]> writes:
> Okay... but I don't see the logic of:
>
> 1. If the system has POSIX's sigsetjmp, use that.
> 2. Otherwise, just assume it has the completely unportable, and not
> even BSDish, siggetmask.
Are you sure siggetmask isn't BSD-ish? When I tested that cod
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hrvoje Niksic wrote:
> Micah Cowan <[EMAIL PROTECTED]> writes:
>
>>>We ain't go no siggetmask(). None on VMS (out as far as V8.3),
>>> either, should I ever get so far.
>> siggetmask is an obsolete BSDism; POSIX has the sigprocmask function,
>>
Micah Cowan <[EMAIL PROTECTED]> writes:
> I wasn't really expecting VMS to have sigprocmask(); but I expect
> future systems may conceivably have it and lack the BSD ones (and
> perhaps such systems are already in the wild). Anyway, we'll use
> what's available.
I think you're misunderstanding th
Micah Cowan <[EMAIL PROTECTED]> writes:
>>We ain't go no siggetmask(). None on VMS (out as far as V8.3),
>> either, should I ever get so far.
>
> siggetmask is an obsolete BSDism; POSIX has the sigprocmask function,
> which we should prefer.
We do prefer the POSIX way, which is to use sigset
Steven M. Schweda wrote:
> From: Micah Cowan <[EMAIL PROTECTED]>
>
>>>Next problem on Tru64:
>>> [...]
>>> ld:
>>> Unresolved:
>>> siggetmask
>>We ain't go no siggetmask(). None on VMS (out as far as V8.3),
>> either, should I ever get so far.
>>
>> siggetmask is an obsolete BSDism; POSIX
From: Micah Cowan <[EMAIL PROTECTED]>
> >Next problem on Tru64:
> > [...]
> > ld:
> > Unresolved:
> > siggetmask
>
>We ain't go no siggetmask(). None on VMS (out as far as V8.3),
> either, should I ever get so far.
>
> siggetmask is an obsolete BSDism; POSIX has the sigprocmask function
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
List cc'd
Steven M. Schweda wrote:
>M:
>
>Next problem on Tru64:
>
> cc -g -o wget cmpt.o connect.o convert.o cookies.o ftp.o ftp-basic.o
> ftp-ls.o
> hash.o host.o html-parse.o html-url.o http.o init.o log.o main.o netrc.o
> progre
21 matches
Mail list logo