Re: Header bug?

On Mon, Jan 26, 2009 at 2:41 PM, Jeff King <[email protected]> wrote:
> On Mon, Jan 26, 2009 at 01:56:40PM -0600, Mark Johnson wrote:
>
>> C++ compatible headers aren't even on my priority list for
>> zinq-djbdns, but I am trying to clean up the K&R cruft and get rid of
>> compiler warnings.  If I change the declaration and definition of
>> byte_zero to be:
>
> Out of curiosity, are you targeting the same platforms for zinq-djbdns
> that djbdns currently runs on? I had the impression from reading the
> code that a lot of the compiler warnings came from Dan using his own
> abstract data types instead of system-provided ones (like time_t or
> pid_t) because the system-provided ones varied in things like size and
> signedness. Any solution to eliminate those sorts of warnings is
> probably going to be a pain to work cross-platform.

Not necessarily.  I'm not going to go out of my way to screw somebody
on an ancient crufty platform, but I don't know that I'm interested in
expending more than a limited amount of effort accommodating them.  I
did recently switch some of the socket wrapper functions to declare
some vars as socklen_t instead of int.  I did enough research to know
that may hork Tru64, HP/UX and Unixware.  Unixware I seriously don't
care about.  The others, I dunno, I might feel pangs of guilt for not
building on HPUX.  There is an autoconf macro that will typedef
socklen_t to int on platforms that don't define socklen_t.  I'll
probably use that.  I probably won't turn down contributions to
maintain cross platform compatibility, as long as it can be done via
autoconf magic/evil.

I did notice some complaints about _exit being defined as int.  To get
those to go away, I just added #include "exit.h" to some source files.
 I'm guessing maybe the lack of the exit.h include in those files was
an oversight?  I'm content with that fix for now.

There are some other things I'm still researching...const pointers vs
pointers to const.  Signed vs unsigned chars.