Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #383532 > unrolled thread

Word For Today: “Uglification”

Back to article view | Back to comp.lang.c

Contents

  Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 00:14 +0000
    Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-11 18:15 -0700
      Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 01:34 +0000
        Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-11 19:56 -0700
    Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-12 03:30 +0000
      Re: Word For Today: “Uglification” Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 10:23 -0700
        Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 14:31 -0700
          Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-14 23:59 +0000
            Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-15 00:01 +0000
            Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 17:11 -0700
              Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-15 00:33 +0000
              Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-15 09:15 +0100
          Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 17:15 -0700
            Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-15 00:34 +0000
              Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 19:19 -0700
                Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-15 03:17 +0000
                  Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 20:44 -0700
                    Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-15 09:22 +0100
          Re: Word For Today: “Uglification” Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 19:49 -0700
    Re: Word For Today: “Uglification” James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-12 01:33 -0400
      Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 06:14 +0000
        Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 06:21 +0000
        Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-12 07:44 +0000
          Re: Word For Today: “Uglification” Richard Kettlewell <invalid@invalid.invalid> - 2024-03-12 08:03 +0000
            Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-12 11:10 +0100
              Re: Word For Today: “Uglification” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-03-12 17:46 +0300
                Re: Word For Today: “Uglification” bart <bc@freeuk.com> - 2024-03-12 14:53 +0000
                  Re: Word For Today: “Uglification” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-03-12 18:09 +0300
                    Re: Word For Today: “Uglification” bart <bc@freeuk.com> - 2024-03-12 15:42 +0000
                      Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-12 18:50 +0000
                        Re: Word For Today: “Uglification” bart <bc@freeuk.com> - 2024-03-12 22:29 +0000
                          Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-12 16:00 -0700
                            Re: Word For Today: “Uglification” bart <bc@freeuk.com> - 2024-03-13 11:45 +0000
                              Re: Word For Today: “Uglification” Michael S <already5chosen@yahoo.com> - 2024-03-13 14:12 +0200
                                Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 08:15 -0700
                                  Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-13 18:47 +0100
                                    Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 11:56 -0700
                                      Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-13 22:07 +0100
                                Re: Word For Today: “Uglification” David Brown <david.brown@hesbynett.no> - 2024-03-13 16:40 +0100
                                Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-13 15:48 +0000
                              Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 09:03 -0700
                                Re: Word For Today: “Uglification” bart <bc@freeuk.com> - 2024-03-13 16:44 +0000
                            Re: Word For Today: “Uglification” Nick Bowler <nbowler@draconx.ca> - 2024-03-13 17:01 +0000
                          Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-13 02:53 +0000
                  Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-12 18:42 +0000
              Re: Word For Today: “Uglification” Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-12 22:07 +0000
            Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 23:13 +0000
              Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-12 16:29 -0700
                Re: Word For Today: “Uglification” Richard Kettlewell <invalid@invalid.invalid> - 2024-03-13 09:01 +0000
                  Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 08:06 -0700
                    Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-13 21:51 +0000
                      Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-13 22:16 +0000
                      Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 15:26 -0700
                      Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-13 22:33 +0000
                        Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-13 22:50 +0000
                          Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-13 16:06 -0700
                            Re: Word For Today: “Uglification” Richard Kettlewell <invalid@invalid.invalid> - 2024-03-13 23:32 +0000
                            Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-14 00:40 +0000
                          Re: Word For Today: “Uglification” scott@slp53.sl.home (Scott Lurndal) - 2024-03-13 23:15 +0000
                    Re: Word For Today: “Uglification” Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 23:09 -0700
              Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-13 00:23 +0000
        Re: Word For Today: “Uglification” James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-12 11:51 -0400
          Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 21:31 +0000
            Re: Word For Today: “Uglification” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-12 15:21 -0700
            Re: Word For Today: “Uglification” James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-13 03:36 -0400
              Re: Word For Today: “Uglification” Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-13 21:52 +0000
                Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-13 22:10 +0000
                Re: Word For Today: “Uglification” James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-13 20:47 -0400
    Re: Word For Today: “Uglification” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-12 06:15 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#383586

bart <bc@freeuk.com> writes:
> On 12/03/2024 23:00, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> That is undesirable, unless you specifically want to shadow the
>>> standard headers. In the examples I saw, that was not the case.
>> You didn't mention that.  If you'd tell us what project you're
>> talking about, maybe we could discuss it.  Perhaps
>
> That's not really relevant. Suffice that they are amateur projects and
> clearly they were using using string.h etc for their own purposes 
> without thinking.

As far as I can tell from what you've written, they may have been using
"string.h" correctly, as a local file that's part of the project.

>> Read section 6.10.2 of the standard.  It describes the search rules for
>> the #include directive.
>
> Not in N1570 it doesn't. It seems mainly concerned with the syntax.

"""
A preprocessing directive of the form
    # include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters,
"""
and so on.  That's what I meant when I said it describes the search
rules.  It doesn't completely define them.

> I understand that the algorithm for finding include files was
> implementation-defined, and typically depended on these inputs:
>
> * Whether the filename used "..." or <...>
> * Whether the file-name specified was absolute or relative
> * The path of the source file in which the #include occurs
> * Possibly, the complete stack of paths for the current sequence set of
>   nested #includes
> * Possibly, on the CWD
> * On where the compiler keeps its standard headers (which in turn may
>   depend on OS)
> * On the set of -I directives given to the compiler  (this is
>   something outside the remit of the standard, AIUI)

Yes -- but you left out a major part of it, that if a search for a ""
header fails, it continues by treating it as if it were a <> header.
Thus #include "stdio.h" will use a header file by that name if it
exists, and is equivalent to #include <stdio.h> otherwise.

>> To summarize, #include <foo.h> searches for a header (probably but
>> not necessarily a file) identified by foo.h.  #include "foo.h"
>> searches for a *file* called foo.h, and if that fails it then
>> searches for a header identified by <foo.h>.  The sequences for both
>> searches are implementation-defined.
>
> This is something new I saw today: suppose I have hello.c in a
> directory (hello.c uses '#include <stdio.h>').
>
> If I create an empty file called 'stdio.h', then 4 compilers I tried
> all picked up that file instead of their official stdio.h. That looks
> a dangerous practice to me.

If they're behaving as you're describing, then they're not conforming.
I've tried gcc, clang, and tcc, and all pick up the correct <stdio.h>
header even if there's a "stdio.h" file in the current directory.

It's possible in principle that a compiler could include the current
directory in the <> search path, but that would be surprising, and none
of the compilers I've tried do so.

What are these 4 compilers?  Are you sure you used <stdio.h> and not
"stdio.h"?  Did you use any additional command line options?  Might you
have set some environment variable like $C_INCLUDE PATH that affects the
behavior?

> It also seems, for a <...> file, to ignore the official repository and
> look first within the user's project. So what exactly is the
> difference between <...> and "..."? Is it just an extra set of backup
> paths to look if it can't find anything within the user's files?

The difference is as I've described above.

> (The 5th compiler I tried ignored it and worked as normal; that was
> mine. I can make it fail using my '-ext' option to look elsewhere than 
> the official headers location. I don't make a distinction between
> <...> and "...".)

Perhaps I'm missing something.  If your compiler doesn't distinguish
between <> and "", then #include "stdio.h" should be equivalent to
#include <stdio.h>.  You say it ignores a stdio.h file in the current
directory.  Then how can a source file include *any* header file in the
current directory?

    #include <stdio.h> // This includes the system header.
    #include "stdio.h" // You say this ignores any local file and
                       // includes the system header.
    #include "foo.h"   // Does this not include a local file named "foo.h"?

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

[toc] | [prev] | [next] | [standalone]

#383588

On 13/03/2024 16:03, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:

>> I understand that the algorithm for finding include files was
>> implementation-defined, and typically depended on these inputs:
>>
>> * Whether the filename used "..." or <...>
>> * Whether the file-name specified was absolute or relative
>> * The path of the source file in which the #include occurs
>> * Possibly, the complete stack of paths for the current sequence set of
>>    nested #includes
>> * Possibly, on the CWD
>> * On where the compiler keeps its standard headers (which in turn may
>>    depend on OS)
>> * On the set of -I directives given to the compiler  (this is
>>    something outside the remit of the standard, AIUI)
> 
> Yes -- but you left out a major part of it, that if a search for a ""
> header fails, it continues by treating it as if it were a <> header.

I didn't attempt to describe the algorithm, only to list the various 
variables.



>> If I create an empty file called 'stdio.h', then 4 compilers I tried
>> all picked up that file instead of their official stdio.h. That looks
>> a dangerous practice to me.
> 
> If they're behaving as you're describing, then they're not conforming.
> I've tried gcc, clang, and tcc, and all pick up the correct <stdio.h>
> header even if there's a "stdio.h" file in the current directory.
> 
> It's possible in principle that a compiler could include the current
> directory in the <> search path, but that would be surprising, and none
> of the compilers I've tried do so.
> 
> What are these 4 compilers?  Are you sure you used <stdio.h> and not
> "stdio.h"?  Did you use any additional command line options?  Might you
> have set some environment variable like $C_INCLUDE PATH that affects the
> behavior?

My observations were erroneous. It turned out I'd been messing about 
with hello.c (when investigating these matters a few days ago) so that 
it was using "stdio.h" rather than <stdio.h>.

So 3 of the 4 compilers (gcc, tcc, dmc) behave as Michael S described, 
and will only look at the current directory, or wherever the source file 
is, if -I. or -Ipath is used.

The 4th compiler is lccwin32 which still looks first inside the same 
directory as the source file (not CWD). I now remember this from many 
years ago when it caused some trouble because of a rogue stdio.h lying 
about.


>> (The 5th compiler I tried ignored it and worked as normal; that was
>> mine. I can make it fail using my '-ext' option to look elsewhere than
>> the official headers location. I don't make a distinction between
>> <...> and "...".)
> 
> Perhaps I'm missing something.  If your compiler doesn't distinguish
> between <> and "", then #include "stdio.h" should be equivalent to
> #include <stdio.h>.  You say it ignores a stdio.h file in the current
> directory.  Then how can a source file include *any* header file in the
> current directory?

>      #include <stdio.h> // This includes the system header.
>      #include "stdio.h" // You say this ignores any local file and
>                         // includes the system header.
>      #include "foo.h"   // Does this not include a local file named "foo.h"?
> 

<...> are not special, but it knows which are the standard headers 
because there is a list of them in the compiler.

So if an include file is one of those, then it will look inside the 
compiler because that's where the headers files are embedded. This 
allows the compiler to be self-contained.

To override that, the `-ext` option is used, then an include file is 
searched for like any ordinary file.

(Which is first in the directory containing the current source file, 
then CWD, then any extra include paths specified.

I think it's more elaborate than that, because if this is a nested 
include, there will be a stack of 'current source files' whose paths are 
searched in top-down order.

Probably CWD should not be part of this, but the process is already so 
convoluted that I can't be bothered to change it.

In my non-C language, any auxiliary files are looked in exactly ONE 
location. Then you don't have the problem of C where if an include file 
is missing or renamed, it might instead find an identically-named but 
WRONG file in another location.)

[toc] | [prev] | [next] | [standalone]

#383589

On Tue, 12 Mar 2024 16:00:05 -0700, Keith Thompson wrote:
> (The standard does mention the possibility that the "foo.h" search is
> not supported.  Any such implementation would not be able to handle
> user-defined header files; perhaps they would have to be installed as
> "headers" somehow.  In every implementation I know about, the compiler
> will *at least* find the foo.h file if it's in the same directory as
> the file that includes it.

The POSIX-standard compiler commands (c89, c99) require #include
searches to work this way so it's not surprising that today, most
compilers work like this.

However some traditional compilers (for example, VAX C) search relative
to the current working directory of the running compiler for #include
"foo.h", rather than the directory containing the source file.

Standard C does not forbid such behaviour and standard C predates the
first version of POSIX.2 by a few years so there are probably some
standard C compilers that work like VAX C.

[toc] | [prev] | [next] | [standalone]

#383569

On 2024-03-12, bart <bc@freeuk.com> wrote:
> On 12/03/2024 18:50, Kaz Kylheku wrote:
>> On 2024-03-12, bart <bc@freeuk.com> wrote:
>
>
>>> I tried my C compiler with a couple of open source projects recently
>>> that both failed for the same mysterious reason.
>>>
>>> It turned out that one of them used this line:
>>>
>>>       #include "string.h"
>>>
>>> and the other used:
>>>
>>>       #include "malloc.h"
>> 
>> In the TXR project, I have a "signal.h" header, which must not resolve
>> to <signal.h>. I also have "time.h" and "termios.h", "glob.h",
>> "regex.h", "alloca.h".
>> 
>> Choosing header names that are distinct from an implementation's
>> headers is:
>> 
>> 1) unnecessary due the local-first search strategy of #include "..."
>> 
>> 2) a fool's errand.
>
> It's confusing. So "string.h" means the standard header, so it is the 
> same as <string.h>, unless it happens to find a file called string.h 
> amongst the project files.

It's not confusing at all. In projects under my control, you would
never see #include "string.h" where the intent is to include <string.h>.
It is a lousy practice.

> That is undesirable, unless you specifically want to shadow the standard 
> headers. In the examples I saw, that was not the case.

You cannot shadow the standard headers when they are correctly included
using #include <...>, unless you resort to compiler specific tricks,
like reconfiguring the <...> search to look in a specified directory.
>
>
>> Regarding (2), no name that you choose is guaranteed not to be identical
>> to something in the implementation! Suppose I panic and rename
>> my "time.h" to "foo.h".  Who is to say that some implementation doesn't
>> have a <foo.h> header?
>
> The C implementation? Surely that will list all the system headers that 
> it provides; it looks quite easy to avoid a clash!

But there is no clash to avoid. A local header file that accidentally
has the same name as something in your /usr/include or whatever
is no problem at all, if you refer to it using #include "...".

But if there were a clash to be avoided, it would be tricky.

Not all headers are documented, so you would have to actually go looking
into the header file installation.

The information there is no reliable for portability, because all you
learn is what files are present in that installation. 

>> There is no such rule that when you name a "whatever.h", you must
>> ensure there does not exist a <whatever.h>.
>
> You mean that programs should be allowed to do this:
>
>      #include <string.h>
>      #include "string.h"

No I mean, that programs /are/.

> With the two headers doing totally different things.
>
> I can guess the reasons why such a rule doesn't exist, because so many 
> programs just carelessly used "..." instead of <...>, and they would all 
> break if it was imposed.

Those programs don't break, because if "string.h" doesn't exist,
then it is re-tried as if it were <string.h> (effectively).

(I don't think it's the best design; it would be better if "..."
and <...> looked in separate places with no fallback from one
to the other, such that #include "stdio.h" programs not
referencing a local file would break.)

> So, is that /your/ file termios.c, or the one that implements the POSIX 
> termios code?

Since my project isn't an operating system, or library for one,
but a dynamic language runtime, it has to be the former.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#383554

On 2024-03-12, bart <bc@freeuk.com> wrote:
> On 12/03/2024 14:46, Anton Shepelev wrote:
>> David Brown:
>> 
>>> The limited support for avoiding name clashes in C (user-
>>> level C, outside of the implementation internals) is
>>> certainly something that he (or others) /could/ complain
>>> about.  It is a well-known issue, and it's a shame that
>>> the C standards committee have never dealt with it.  I
>>> don't see why the language could not adopt a simple
>>> "namespace" solution that would hugely simplify avoiding
>>> identifier clashes.  (It wouldn't help for macros, but we
>>> have inline functions to handle many cases.)
>> 
>> My hypothetical solution is to have a single function
>> returning a struct with pointers to all the public functions
>> of a module.
>> 
> What stops that function name clashing with the single function exported 
> from other people's modules?

There are multiple possible answers here.

One is that even if such functions have to be uniquely named, that is a
lesser burden than all API functions having to be uniquely named.
The probability of a clash is reduced, and at most one function
has to be renamed if it occurs.

There are ways that this single function can have the same name
in every component.

For instance, under Microsoft COM, COM DLLs provide well-known
functions like DllGetClassObject, DllRegisterServer and
DllUnregisterServer.

These don't clash since they are in different DLLs.

An appliation queries for the COM object using its class ID,
which is a GUID. That must be unique. DllRegisterServer  registers
it in the registry.

Variations on this theme can be done in any system that has dynamic
libraries or loadable modules.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#383559

David Brown wrote:

> The limited support for avoiding name clashes in C (user-level C,
> outside of the implementation internals) is certainly something that he
> (or others) /could/ complain about.  It is a well-known issue, and it's
> a shame that the C standards committee have never dealt with it.  I
> don't see why the language could not adopt a simple "namespace" solution
> that would hugely simplify avoiding identifier clashes.  (It wouldn't
> help for macros, but we have inline functions to handle many cases.)

Many libraries put a prefix on their identifiers as a form of 
psuedonamespacing.



-- 
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
The law prohibits underwater smoking!

[toc] | [prev] | [next] | [standalone]

#383565

On Tue, 12 Mar 2024 08:03:50 +0000, Richard Kettlewell wrote:

> That’s true, but AFAICT it’s exactly what Lawrence is complaining about:
> there’s nothing in the language spec to help those thousand other
> libraries avoid name clashes.

My specific complaint was about temporary names being used internal to 
library macros. It’s a problem that is essentially impossible to solve 
with string-based macro processors.

[toc] | [prev] | [next] | [standalone]

#383566

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 12 Mar 2024 08:03:50 +0000, Richard Kettlewell wrote:
>> That’s true, but AFAICT it’s exactly what Lawrence is complaining about:
>> there’s nothing in the language spec to help those thousand other
>> libraries avoid name clashes.
>
> My specific complaint was about temporary names being used internal to 
> library macros. It’s a problem that is essentially impossible to solve 
> with string-based macro processors.

Here's the macro definition you cited upthread:
"""
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)
"""

Can you explain how that would cause a problem?

Note the following that precedes the macro definition in
/usr/include/x86_64-linux-gnu/bits/select.h on my Ubuntu system:

"""
#ifndef _SYS_SELECT_H
# error "Never use <bits/select.h> directly; include <sys/select.h> instead."
#endif
"""

so it's not going to be invoked from user-written code.

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

[toc] | [prev] | [next] | [standalone]

#383574

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> My specific complaint was about temporary names being used internal to 
>> library macros. It’s a problem that is essentially impossible to solve 
>> with string-based macro processors.
>
> Here's the macro definition you cited upthread:
> """
> 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)
> """
>
> Can you explain how that would cause a problem?

The implementation can use prefixed names as shown, so that example
won’t cause any trouble as long as the implementors coordinate amongst
themselves (which is a reasonable assumption).

Any library from outside the implementation doesn’t have that privilege
and just has to hope that the internal names it chooses don’t collide
with anything else that’s visible when its header(s) are included.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#383580

Richard Kettlewell <invalid@invalid.invalid> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> My specific complaint was about temporary names being used internal to 
>>> library macros. It’s a problem that is essentially impossible to solve 
>>> with string-based macro processors.
>>
>> Here's the macro definition you cited upthread:
>> """
>> 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)
>> """
>>
>> Can you explain how that would cause a problem?
>
> The implementation can use prefixed names as shown, so that example
> won’t cause any trouble as long as the implementors coordinate amongst
> themselves (which is a reasonable assumption).
>
> Any library from outside the implementation doesn’t have that privilege
> and just has to hope that the internal names it chooses don’t collide
> with anything else that’s visible when its header(s) are included.

Any library from outside the implementation cannot use reserved
identifiers without invoking undefined behavior, any more than ordinary
user code can do so.  In practice, third-party code can (probably) get
away with using reserved identifiers as long as there isn't an actual
collision.  (A compiler could enforce a general restriction on using
reserved identifiers, but I don't know of any that do so.)

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

[toc] | [prev] | [next] | [standalone]

#383593

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? And saying that those from 
“outside” have no right to use mechanisms (such as they are) to minimize 
name conflicts with regular user code?

[toc] | [prev] | [next] | [standalone]

#383596

On 2024-03-13, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 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? And saying that those from 
> “outside” have no right to use mechanisms (such as they are) to minimize 
> name conflicts with regular user code?

Libraries that are not part of the implementation are part of the
C program being presented to the C implementation for translation and
linkage.

They are subject to the requirements placed on a program.

If a program uses identifiers that, for instance, start with double
underscores, then its behavior is undefined, and that goes for those
parts of the program which are libraries.

From the C point of view, external libraries are just translation units
that have been translated and retained in that form, accompanied by
header files.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#383597

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

[toc] | [prev] | [next] | [standalone]

#383598

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? And saying that those from 
>“outside” have no right to use mechanisms (such as they are) to minimize 
>name conflicts with regular user code?

The implementation does not include third-party libraries.

Third party libraries are allowed to use any mechanism they
like to minimize name conflicts other than prefixing with
two underscores.

[toc] | [prev] | [next] | [standalone]

#383599

On Wed, 13 Mar 2024 22:33:02 GMT, Scott Lurndal wrote:

> Third party libraries are allowed to use any mechanism they like to
> minimize name conflicts other than prefixing with two underscores.

But there is no other such mechanism available.

[toc] | [prev] | [next] | [standalone]

#383600

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 13 Mar 2024 22:33:02 GMT, Scott Lurndal wrote:
>> Third party libraries are allowed to use any mechanism they like to
>> minimize name conflicts other than prefixing with two underscores.
>
> But there is no other such mechanism available.

Are you aware that working third party libraries exist, and name
collisions are fairly rare?  How do you think that's possible?

There are no 100% reliable mechanisms.  There are mechanisms that work
well enough in practice, including using library-specific prefixes.

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

[toc] | [prev] | [next] | [standalone]

#383602

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Wed, 13 Mar 2024 22:33:02 GMT, Scott Lurndal wrote:
>>> Third party libraries are allowed to use any mechanism they like to
>>> minimize name conflicts other than prefixing with two underscores.
>>
>> But there is no other such mechanism available.
>
> Are you aware that working third party libraries exist, and name
> collisions are fairly rare?  How do you think that's possible?
>
> There are no 100% reliable mechanisms.  There are mechanisms that work
> well enough in practice, including using library-specific prefixes.

The collisions I recall running into are library headers defining things
like MIN, MAX, TRUE, FALSE - useful in isolation, but a nuisance when
more than one library does it.

Actually the offending headers that spring are mind are supplied by the
implementor of the platform they support, albeit that the headers
involved are not ones specified in standard C.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#383603

On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Wed, 13 Mar 2024 22:33:02 GMT, Scott Lurndal wrote:
>>> Third party libraries are allowed to use any mechanism they like to
>>> minimize name conflicts other than prefixing with two underscores.
>>
>> But there is no other such mechanism available.
>
> Are you aware that working third party libraries exist, and name
> collisions are fairly rare?  How do you think that's possible?

It's possible because firstly, even if there are collisions latent
in the library mixture, not all libraries are used together in one
application. E.g. in an OS distro installation there might be a thousand
libraries, but no application uses all thousand.

Secondly, even if two libraries are used in the same application, where
those libraries have a header-file-level clash, the clash only occurs if
their headers are included in the same translation unit in that program.

Thirdly, mere linkage of two libraries into the same program can only
cause a clash if it involves an external name.

Fourth, even if two libraries have a clashing external name, I think
that under certain dynamic linking paradigms, this is only a problem if
that name is used. If the same name refers to multiple entities, there
is an ambiguity, but if the program doesn't use that name, then the
ambiguity doesn't matter.

Fifth, if we are talking specifically about names used by macros for
naming local symbols inserted into the program, libraries not in the C
implementation in fact can get away with using the __ space.  If these
identifiers don't land on a compiler keyword, there is no actual
problem.  Now a third party library could choose such a name inside its
macro such that the C library has also used the same name inside its
macro.  But for that to cause a clash, the macros have to be nested
together.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#383601

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 13 Mar 2024 22:33:02 GMT, Scott Lurndal wrote:
>
>> Third party libraries are allowed to use any mechanism they like to
>> minimize name conflicts other than prefixing with two underscores.
>
>But there is no other such mechanism available.

Of course there is.  The most simple is to prefix
any external symbols with a library specific
prefix.

Or to suffix any symbol with two underscore characters
and a library-specific string.

Or obfuscate the extern symbols in the library and use #define
macros to map a readable name to the obfuscated symbol
in the corresponding header file(s).

As has been pointed out, extending the double-leading
underscore mechanism outside the implementation requires
some central authority to manage names across all
third-party libraries. (which is generally true for any prefix
mechanism, whether it is __ or fubar_).

We seem to have survived just fine without any such
disambiguation mechanism to date.

[toc] | [prev] | [next] | [standalone]

#386218

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Any library from outside the implementation cannot use reserved
> identifiers without invoking undefined behavior, [...]

Reserved identifiers can be used.  It is only declaring or
defining reserved identifiers (in some contexts) that the C
standard calls out as undefined behavior, not other uses.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web