Andre Majorel <[EMAIL PROTECTED]> writes:
>> And weird ones, too. These arguments are of type "pointer to
>> fd_set". What would HPUX like to see there?
>
> HP-UX 10 wants (int *). However it defines fd_set as
>
> struct
> {
> long[];
> }
>
> so it works anyway.
>
> HP-UX 10 is wrong. SUS2 (and POSIX ?) say (fd_set *). HP-UX 11
> has it right.
>
> I suppose the best thing to do is to ignore those warnings.
Agreed.
>> I think I'll use something like:
>>
>> #ifndef h_errno
>> extern int h_errno;
>> #endif
>
> h_errno is not necessarily a macro !
I know that. The above code says: "if h_errno is a macro, do
nothing. otherwise, declare it."
> What do you think of Maciej's proposal ?
It sounds like the right thing to do.
>> Two questions here:
>>
>> * Does HPUX really not have snprintf()? It sounds weird that a modern
>> OS wouldn't have it.
>
> I find describing HP-UX 10 as a modern OS mildly amusing. :-)
How old is it? I used to work on HPUX 9, and I'm not old by most
definitions of the word.
> I completely disagree with your perception that snprintf() is to be
> taken for granted. It's only since C99 that's it's part of C.
It's been a part of C since C99, that's true. But Wget relies on a
lot of functionality not strictly in C, from alloca to the socket
interface.
Also, snprintf has become a big security thing recently, when a number
of exploits was based on overflowing a buffer written to by sprintf.
The pressure on vendors might be responsible for some of them being
unusually swift in providing the function.
But yes, I know I can't take it for granted, hence the provided
replacement.
> But to answer your question, no HP-UX doesn't have it (neither in
> the headers nor in libc).
HPUX 11 doesn't have it either? Interesting.
>> * short int is promoted to int, ok. Does that go for all the
>> architectures, or just some? Should I simply replace "short int"
>> with "int" to get it to compile?
>
> Yes, replace short int and unsigned short by int. It's not
> architecture specific, the same thing happened to me on x86. GCC
> 2.95 doesn't care, GCC 2.96 and 3.0 complain.
Ah, ok. Thanks for the info.
