Re: standards/50983: stddef.h max_align_t conflicts with pkgsrc firefox

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 21 Mar 2016 08:57:20 +0100
    From:        Klaus Klein <kleink%kleink.org@localhost>
    Message-ID:  <20160321075720.GA27540%kleink.org@localhost>

  | The _t suffix is reserved for the implementation
  | (in POSIX compilation environments).

This message has nothing to do with the bug in question, as there's
nothing we can do about what I am about to rant on below, but...

(I have deleted a bunch of addresses from the To/Cc lines, including
all related to gnats, as this message has nothing to do with the problem
reported, nor its resolution.)

That technique is (while seemingly useful) one of the most useless
ways to handle namespaces and namespace pollution that exists.

It is essentially the same as the (old, and now fortunately gone) way
that e-mail headers used to allocate names starting with X to the
community to use, and reserve all others to the standard.   It just
doesn't work.

Eg: in the case in question, one might say that "The Network is the Computer"
and these days "The Web (WWW) is the Network", and "Firefox is (one of)
the implementations of the WWW" - hence firefox is part of the implementation,
(one of several alternative implementations) and so perfectly entitled to
create new _t names according to the standard.  (The applications are
javascript, php, etc... everything underneath firefox is just support code.)

Now I know that one is perhaps a bit of a stretch, but there are other
examples that are not.

Eg: is gcc permitted to define new _t types?   Is it part of the
implementation, or just an application?

What about on a system where gcc is the standard compiler, and you could
argue that it is part of the implementation, is clang (if added as an add-on)
allowed to define new _t types?   If not, how could it ever be prepared to
be a replacement for gcc?  If it is, what makes it be "the implementation" ?

Or, if the system include files, added from part of libc need a new _t to
allow the interface, is that permitted, or do they have to choose some other
name for the type?   What if the library function in question was from
libutil instead of libc?   Or perhaps libX11 ?   Or libnmh ?  Or libnss
or xulrunner?

The scheme is just unworkable, as what is "the implementation" varies
depending upon just where you observe from.   If you're building and
distributing PCs then you could argue that the BIOS is part of the
implementation, but all the other software is not.   That's probably not
pretending to be a posix environment, but the way BOIS's are growing, it
could be sometime soon...

My advice would be to simply forget attempting to apply that rule as a
rule we must obey, and handle mis-matches between type names that end in _t
using the same techniques that are used to deal with name clashes anywhere
else in the name space, and not just fall back on "thou shalt not..."

kre