On 2001-12-03 18:30 +0100, Hrvoje Niksic wrote:
> Andre Majorel <[EMAIL PROTECTED]> writes:
>
> > gcc -I. -I. -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local/etc/wgetrc\"
>-DLOCALEDIR=\"/usr/local/share/locale\" -O2 -Wall -Wno-implicit -c connect.c
> > connect.c: In function `test_socket_open':
> > connect.c:190: warning: passing arg 2 of `select' from incompatible pointer
>type
> > connect.c: In function `select_fd':
> > connect.c:283: warning: passing arg 2 of `select' from incompatible pointer
>type
> > connect.c:283: warning: passing arg 3 of `select' from incompatible pointer
>type
> > connect.c:283: warning: passing arg 4 of `select' from incompatible pointer
>type
> >
> > (These are just warnings.)
>
> 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.
> I think I'll use something like:
>
> #ifndef h_errno
> extern int h_errno;
> #endif
h_errno is not necessarily a macro ! What do you think of
Maciej's proposal ?
> 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. :-) 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.
But to answer your question, no HP-UX doesn't have it (neither
in the headers nor in libc).
> * 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.
> > The error message is misleading, IMO. The real problem is that
> > we're initialising an auto array, which is something C does
> > not support, at least not C89/C90.
>
> Indeed. I wonder why I thought that was legal C. Ok, I'll apply your
> patch.
Not enough cafeine. :-)
--
Andr� Majorel <URL:http://www.teaser.fr/~amajorel/>
(Not speaking for my employer, etc.)
