Project

General

Profile

Actions
Copy link

Bug #836

closed

Bug in socketvar.h?

Added by Johannes.Hofmann almost 18 years ago. Updated almost 18 years ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

After reading
http://www.onlamp.com/pub/a/bsd/2007/11/01/whats-new-in-bsd-42.html
(last question) I noticed that we seem to have the same makro.
Though I don't know any details, it looks wrong to me too.
The problematic part is:

#define ssb_lock(ssb, wf) ((ssb)->ssb_flags & SSB_LOCK ? \
(((wf) == M_WAITOK) ? _ssb_lock(ssb) : EWOULDBLOCK) : \
((ssb)->ssb_flags |= SSB_LOCK), 0)

that in its current form always evaluates to 0.

Johannes
Actions
Copy link
 #1

Updated by dillon almost 18 years ago

:After reading
:http://www.onlamp.com/pub/a/bsd/2007/11/01/whats-new-in-bsd-42.html
:(last question) I noticed that we seem to have the same makro.
:Though I don't know any details, it looks wrong to me too.
:The problematic part is:
:
:#define ssb_lock(ssb, wf) ((ssb)->ssb_flags & SSB_LOCK ? \
: (((wf) == M_WAITOK) ? _ssb_lock(ssb) : EWOULDBLOCK) : \
: ((ssb)->ssb_flags |= SSB_LOCK), 0)
:
:
:that in its current form always evaluates to 0.
:
: Johannes

Interesting.  That could account for some of the weird network bugs that
    have cropped up over the years.  Ours definitely has the same bug.
I think I'll convert it to the inline version mentioned in the article.
-Matt
                    Matthew Dillon 
                    <>
Actions
Copy link

Also available in: Atom PDF