headers
Paul Procacci | 28 Nov 2009 10:19
Favicon

Bug, well not really but could be?

Gents,

Forgive me in advance as my C programming skills are still maturing.  I
found a discrepancy for the len argument being passed to accept.  On my
machine (FBSD), I have the following definition of accept:

int accept(int s, struct sockaddr * restrict addr, socklen_t * restrict
addrlen);

Here is where I get all fuzzy and warm due to my lack of understanding.

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'.

I'm curious if this was simply an oversight (meaning it should be
unsigned int), or if there was a real reason behind it.  I question it
only because my compiler is yelling and screaming.

Thanks,
Paul

This message may contain confidential or privileged information.  If you are not the intended recipient,
please advise us immediately and delete this message.  See
http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the
risks of non-secure electronic communication. If you cannot access these links, please notify us by
reply message and we will send the contents to you.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daryl Tester | 28 Nov 2009 23:58
Picon

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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Johnson | 1 Dec 2009 20:36
Picon

Re: Bug, well not really but could be?

On Sat, Nov 28, 2009 at 4:58 PM, Daryl Tester
<dt-djb <at> handcraftedcomputers.com.au> wrote:
> (* 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).

Some relevant reading material:

http://portabilityblog.com/blog/archives/7-socklen_t-confusion.html

I switched to socklen_t in my djbdns fork (zinq-djbdns) to avoid the
compiler warnings:

http://zinq.svn.sourceforge.net/viewvc/zinq?view=rev&revision=55

> 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).

In a sane world, socklen_t would always be big enough to contain the result of:

sizeof sa
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daryl Tester | 2 Dec 2009 00:58
Picon

Re: Bug, well not really but could be?

Mark Johnson wrote:

> I consider compiler warnings to be broken windows.

To a certain extent, but to be fair you're talking about gcc here - some
(many?) of its warnings are obtuse and GNU-centric pedantry.  Granted that
your port isn't aiming for non-gcc environments (AFAIK), but how would you
successfully suppress all those warnings for multi-vendors' compilers
(without redirecting stderr to /dev/null)?

--

-- 
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.
Permalink | Reply | 1 comment |

Gmane