Re: Bug, well not really but could be?

(* Reply to dev null'd *)

Paul Procacci wrote:

> I have the following definition of accept:
> 
> int accept(int s, struct sockaddr * restrict addr, socklen_t * restrict
> addrlen);

Note that the 3rd argument wasn't always socklen_t; it initially was int
(pre-Posix something).

> socklen_t is defined as "an unsigned opaque integral type of length of
> at least 32 bits" yet this call is passing a signed int (see
> socket_accept.c).  I would have thought we would be passing an 'unsigned
> int'.

No, you would be passing a socklen_t (pedantically, an address to).  You're
not supposed to know, or care, what the underlying type is (although I
think there are issues if it's anything other than sizeof(int)).

Provided that the sizeof (struct sockaddr_in) remains less than 2GB in
size (which I hope so for the immediate future) there shouldn't be an
issue (too early in the morning for me to be doing signed arithmetic).

> I'm curious if this was simply an oversight (meaning it should be
> unsigned int), or if there was a real reason behind it.

Note that quite a few of the source files in djbdns (I presume this is the
socket_accept.c you're talking about - it also appears in ucspi) also lack
function prototypes, which should provide a gentle hint as to which era this
software was written in.

>  I question it only because my compiler is yelling and screaming.

Don't make the folly of applying standards of today to software that
was written nearly 10 years (or probably greater) ago.


-- 
Regards,
  Daryl Tester

"Scheme is an exotic sports car. Fast. Manual transmission. No radio.
 Common Lisp is Howl's Moving Castle."
  -- Steve Yegge, comparing Lisp families to cars.