Re: Word For Today: “Uglification”

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

From /usr/include/«arch»/bits/select.h on my Debian system:
>
    #define __FD_ZERO(s) \
      do {       \
        unsigned int __i;       \
        fd_set *__arr = (s);       \
        for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i)       \
          __FDS_BITS (__arr)[__i] = 0;       \
      } while (0)
>
Note how this macro brings the entire expression for “s” into the
scope containing those temporary “__i” and “__arr” variables. You just
better hope they won’t clash.
>
I think there is a clause in the C spec that says names beginning with
underscores (“uglified” names, I think they’re called) are reserved
for library implementors or something. But what happens if one library
implementation depends on another? What keeps the choices of names
from clashing in that situation? Just luck, I guess.

N1570 7.1.3:

    All identifiers that begin with an underscore and either an
    uppercase letter or another underscore are always reserved for any
    use.

    All identifiers that begin with an underscore are always reserved
    for use as identifiers with file scope in both the ordinary and tag
    name spaces.

I've never heard them call "uglified", though I suppose it's somewhat apt.

If the standard library includes code from two or more different
implementers, all implementers have a very strong interest in avoiding
any clashes.  I don't see a real problem here.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */