Re: queue.7, stailq.3, (simpleq.3): Document SIMPLEQ as an alias of STAILQ

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 10, 2021 at 11:24 AM Alejandro Colomar (man-pages)
<alx.manpages@xxxxxxxxx> wrote:
> On 2/10/21 5:05 PM, Zack Weinberg wrote:
> > On Wed, Feb 10, 2021 at 10:53 AM Alejandro Colomar (man-pages)
> > <alx.manpages@xxxxxxxxx> wrote:
> >> On 2/10/21 4:38 PM, Zack Weinberg wrote:
> >>>
> >>> I don't know about anyone else on the glibc team, but I personally
> >>> consider the entirety of <sys/queue.h> to be provided only for some
> >>> degree of backward compatibility with old applications that were
> >>> ported from BSD; new code should not use it.  I'd *like* to formally
> >>> deprecate it, but I expect that would cause too much breakage to be
> >>> viable.  Anyway, I hope you can understand why I'm not interested in
> >>> messing with its contents at all.
> >>>
> >>> (Can we add a statement to the effect that new code should not use
> >>> <sys/queue.h> to all of the related manpages, please?)
> >>
> >> Would you mind explaining your reasons for the deprecation?  Performance?
> >
> > No, portability and reliability.   The contents of <sys/queue.h> are
> > not consistent among the various operating systems that offer it, and
> > some versions have outright bugs.
>
> About portability, I guess you are referring to the fact that some
> systems don't provide some of the newest macros?  Such as OpenBSD not
> providing SIMPLEQ_LAST()?
>
> But for those that offer macros of the same family (with the same name),
> I guess they all offer the same interface, don't they?

I don't remember specific details anymore -- the troubles I had with
it were going on ten years ago now -- but based on experience
tinkering with user space applications and libraries that tried to use
queue.h, missing macros were unpredictable and varied, and macros with
the same name did *not* reliably provide the same interfaces.

> About bugs, I don't know which, but considering that the BSDs use these
> macros, I guess they'll fix whatever new bugs they find.

The trouble here is that the BSDs' unified source tree means that they
can and do address problems by changing all *their* users to avoid the
bug, rather than fixing the bug in the header.  (This may sound
ridiculous but I've seen it happen dozens of times and not just with
sys/queue.h.)  glibc doesn't have that luxury -- but that means code
developed on Linux becomes unportable by virtue of not having to avoid
bugs that are present on the BSDs.

> If you need to have a high performance linked list, yes, probably it
> pays off writing your own.  But for a prototype or some code that isn't
> critical, having a libc interface that already provides (somewhat
> standard) linked lists is great, IMHO.

Again, it's about correctness, not performance.  I just don't *trust*
sys/queue.h.

zw



[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux