Bug #836

Bug in socketvar.h?

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

Status:ClosedStart date:
Priority:HighDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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

History

#1 Updated by dillon almost 7 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
<>

Also available in: Atom PDF