On Sat, May 08, 1999 at 01:19:14PM +0100, Ben Laurie wrote:
> Bodo Moeller wrote:
>> But the problem is in the system header files, not in the program.
>> When those header files are not quite as they should be, warnings can
>> be inevitable (on Linux, you cannot compile programs that #include
>> <sys/sockets.h> with -pedantic-erros because there's some zero-length
>> array, and on Solaris you run across various signedness issues).
>> So my suggestion is, don't use compiler options that are that strict,
>> and let the compiler print all those annoying warnings instead of
>> treating them as errors.
> Nah. Sorry. That means I have to read the warnings each time and ensure
> they aren't real warnings. I don't care about broken headers in Linux,
> because Linux appears to be permanently broken anyway; all that means is
> that Linux isn't a suitable platform for cautious programmers.
Yeah, exactly as those systems that use historical types for the
arguments of socket functions. They are broken, and the compiler
complains about that. I don't know why that would be any less broken
than the compatibility hack in the glibc socketbits.h header file.
Possibly your system allows you to define macros to select the correct
declarations for those socket functions (e.g. the problematic
zero-length array in glibc goes away when you define __STRICT_ANSI__).
> The question of what setsockopt's arguments "should be" is a different
> issue: should be according to who?
Any recent standard and draft, as far as I know (X/OPEN, the IEEE
1003.1g drafts).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
