Re: Word For Today: “Uglification”

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

On Wed, 13 Mar 2024 08:06:28 -0700, Keith Thompson wrote:

Any library from outside the implementation ...

>
So you are now distinguishing between libraries from “outside the
implementation” from those that are within it?

The standard makes that distinction.

                                               And saying that those from
“outside” have no right to use mechanisms (such as they are) to minimize
name conflicts with regular user code?

I didn't say "no right".  I said that third-party library code can't
safely define identifers that are reserved to the implementation.  Do
you disagree?

Please read section 7.1.3 and tell me what *you* think the rules are.

The fact that certain identifers are reserved for use by the
implementation implies that they cannot safely be used by code that is
not part of the implementation.  The standard does not distinguish
between third-party library code and ordinary user code.

As I've said before, third-party library code can probably get away with
using implementation-reserved identifiers if there don't happen to be
any actual collisions.  But if my libfoo.h header defines
__SOME_IDENTIFIER, and then a future version of some implementation's
<stdio.h> defines __SOME_IDENTIFIER for its own purposes, then as the
author of libfoo.h *I'm* responsible for resolving the conflict, because
I've written code that doesn't work with a fulli conforming C
implementation..  (If I can resolve the conflict by persuading the
authors of the <stdio.h> to use a different identifier, that's fine.)

Reserved identifiers are a mechanism for avoiding name conficts between
the implementation and other code.  C doesn't have great mechanisms for
avoiding name conflicts between third-party libraries.  It's not ideal,
and nobody said it is.

--
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 */