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
