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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#383541

On Tue, 12 Mar 2024 01:33:00 -0400, James Kuyper wrote:

> They are called "reserved identifiers", a name which more directly
> addresses their purpose. They don't just start with underscores - there
> are several different sets of identifiers, reserved for different
> purposes. See section 7.1.3 for details. They are provided by *an*
> implementation. Note the use of the singular.

Looking at the C99 spec, section 7.1.3:

    Also reserved for the implementor are all external identifiers
    beginning with an underscore, and all other identifiers beginning
    with an underscore followed by a capital letter or an underscore.
    This gives a name space for writing the numerous behind-the-scenes
    non-external macros and functions a library needs to do its job
    properly.

The problem I have with that is the singular form of “library”. In a
typical Linux distro, you could have thousands of libraries installed.
I just did this command on my Debian system:

    dpkg-query -l lib*dev | wc -l

and the answer came back “1037”. The idea that a C-language
implementation and run-time environment is any sense monolithic seems
hopelessly out of touch.

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

#383543

On Tue, 12 Mar 2024 06:14:58 -0000 (UTC), I wrote:

> I just did this command on my Debian system:
> 
>     dpkg-query -l lib*dev | wc -l

Let me amend that: the more accurate command (counting only installed 
libraries, not all the ones the package system knows about) would be

    dpkg-query -l lib\*dev | grep ^i | wc -l

which produces a result of 320 on my system.

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

#383544

On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> The problem I have with that is the singular form of “library”. In a
> typical Linux distro, you could have thousands of libraries installed.
> I just did this command on my Debian system:
>
>     dpkg-query -l lib*dev | wc -l
>
> and the answer came back “1037”. The idea that a C-language
> implementation and run-time environment is any sense monolithic seems
> hopelessly out of touch.

There is no such out-of-touch idea. In (say) a Glibc-based system, only
the GCC, Glibc and kernel headers are part of the implementation (which
comprises C, POSIX plus GNU and Linux extensions), and only the GCC and
Glibc library components and their external names.

Other libraries are third parties; the __ and _[A-Z] namespace
simply doesn't belong to them.

C doesn't provide any special tools for the application developer and
third party code to avoid clashes among themselves.

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

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

#383545

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> and the answer came back “1037”. The idea that a C-language
>> implementation and run-time environment is any sense monolithic seems
>> hopelessly out of touch.
>
> There is no such out-of-touch idea. In (say) a Glibc-based system, only
> the GCC, Glibc and kernel headers are part of the implementation (which
> comprises C, POSIX plus GNU and Linux extensions), and only the GCC and
> Glibc library components and their external names.
>
> Other libraries are third parties; the __ and _[A-Z] namespace
> simply doesn't belong to them.
>
> C doesn't provide any special tools for the application developer and
> third party code to avoid clashes among themselves.

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.

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

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

#383546

On 12/03/2024 09:03, Richard Kettlewell wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> and the answer came back “1037”. The idea that a C-language
>>> implementation and run-time environment is any sense monolithic seems
>>> hopelessly out of touch.
>>
>> There is no such out-of-touch idea. In (say) a Glibc-based system, only
>> the GCC, Glibc and kernel headers are part of the implementation (which
>> comprises C, POSIX plus GNU and Linux extensions), and only the GCC and
>> Glibc library components and their external names.
>>
>> Other libraries are third parties; the __ and _[A-Z] namespace
>> simply doesn't belong to them.
>>
>> C doesn't provide any special tools for the application developer and
>> third party code to avoid clashes among themselves.
> 
> 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.
> 

No, it is /not/ what Lawrence is complaining about.  He is complaining 
about clashes within the reserved namespace, because he didn't 
understand the difference between the library and headers that make up a 
C implementation, and other libraries that he happens to have on the 
system.  It's an understandable confusion, since it is an overload of 
the term "library".  But hopefully he understands that now.

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.)

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

#383547

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.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

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

#383548

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?

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

#383549

bart:
> Anton Shepelev:
> > 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?

A much lower probability.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

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

#383551

On 12/03/2024 15:09, Anton Shepelev wrote:
> bart:
>> Anton Shepelev:
>>> 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?
> 
> A much lower probability.
> 

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"

Notice they use "..." rather than <...>. These are not the standard 
headers, but user-written headers with the same names. (My compiler 
looks for them in the wrong order.)

People like reusing the same popular module names so much, they will 
even use the names of standard headers! Any exported function name is 
likely to be linked to the name of the module.

 >>> returning a struct with pointers to all the public
 >>> functions of a module.

There may be an additional clash-point with exposing the name of the struct.

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

#383555

On 2024-03-12, bart <bc@freeuk.com> wrote:
> On 12/03/2024 15:09, Anton Shepelev wrote:
>> bart:
>>> Anton Shepelev:
>>>> 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?
>> 
>> A much lower probability.
>> 
>
> 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.

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?

There is no such rule that when you name a "whatever.h", you must
ensure there does not exist a <whatever.h>.

> People like reusing the same popular module names so much, they will 
> even use the names of standard headers!

Sometimes deliberately so. Why did I call that header "termios.h"
is that the module is relates to is related to the POSIX termios;
the source file is called termios.c and includes <termios.h> as
well as its own "termios.h". This makes things readable; someone
looking at the directory listing can guess that these files
constitute a module which wraps termios.

Any other naming would obscure that to some degree, other than
perhaps longer names that contain "termios" as a substring.

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

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

#383561

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.

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


> 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!

> 
> 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"

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.


>> People like reusing the same popular module names so much, they will
>> even use the names of standard headers!
> 
> Sometimes deliberately so. Why did I call that header "termios.h"
> is that the module is relates to is related to the POSIX termios;
> the source file is called termios.c and includes <termios.h> as
> well as its own "termios.h". This makes things readable; someone
> looking at the directory listing can guess that these files
> constitute a module which wraps termios.

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

If it is your file, does it wrap the standard one, or replace it? 
Generally if you want to wrap X, you call the wrapper Y; having both 
called X is troublesome. Supposed somebody wanted to wrap your X, and 
they wanted theirs called X too.

Suppose you want two different wrappers for X...

> Any other naming would obscure that to some degree, other than
> perhaps longer names that contain "termios" as a substring.

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

#383564

bart <bc@freeuk.com> writes:
> 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"

Note that malloc.h is not a standard header.

Apparently this helped you find and fix a bug in your compiler.

>> 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.

Yes.  But it doesn't "happen to" find a file called string.h; that file
is part of the project.  You've just explained it correctly, so I'm not
sure what confuses you.

> 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 

>> 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!
>
>> 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"
>
> With the two headers doing totally different things.

I'm not going to say that programs *should* be allowed to do that, but
the fact is that they *are* allowed to do that.

Read section 6.10.2 of the standard.  It describes the search rules for
the #include directive.

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.

(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.  And if an implementation is able to handle
#include "foo.h", it can also handle #include "string.h".)

If you provide a file called "string.h" as part of your project, and set
up the implementation-defined search paths correctly, then
    #include "string.h"
refers to the file in your project, and
    #include <string.h>
refers to the standard header.

Having <string.h> and "string.h" do "totally different things" would
perhaps be unwise, but nothing in the standard forbids it.  (I wonder
if you think it could or should.)

> 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.

No they wouldn't -- or rather, no they don't.  A program that carelessly
uses #include "string.h" to refer to the standard header will work just
fine as long as the project doesn't have a file by that name.  The
initial search will fail, and then it will find the standard header.
Certainly #include <string.h> is better style.  And a program that
deliberately uses #include "string.h" to refer to its own file by that
name, it will work correctly as long as the search path is set up
correctly.

I'm personally not entirely comfortable with mirroring standard header
names, like using #include "string.h" to use a header file that wraps
the standard header <string.h>.  My first thought on seeing that would
be to think that the author should have used <> rather than "".  There's
also some risk that if you don't set up the search path correctly,
#include "string.h" could refer to the standard header.  But I can see
how it would be useful, and nothing in the language forbids it.  If a
project uses such a scheme consistently, I have no problem with it,
beyond a brief moment of "Oh, that's what you're doing".

I might prefer #include "string_wrapper.h".

[snip]

-- 
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]

#383576

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.

> 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.

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)


> 
> 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.

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 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 "...".)

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

#383577

On Wed, 13 Mar 2024 11:45:31 +0000
bart <bc@freeuk.com> wrote:
>
> 
> 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.
> 
> 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 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 "...".)
> 
> 

I just tried three compilers and [in absence of -I options] all 3 work
as expected, i.e. ignored stdio.h in current directory. 
None of the three was of the variety that you appear to prefer.
Mine's are mundane stuff.

However all three took local file when I had given them an option -I. 
Not sure what to make of this. Whatever happens with
non-default options is probably in "implementation-defined"
domain as far as the C Standard is concerned, but I still
expected that such common option as  -I would not affect standard
headers.

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

#383582

Michael S <already5chosen@yahoo.com> writes:
[...]
> I just tried three compilers and [in absence of -I options] all 3 work
> as expected, i.e. ignored stdio.h in current directory. 
> None of the three was of the variety that you appear to prefer.
> Mine's are mundane stuff.
>
> However all three took local file when I had given them an option -I. 
> Not sure what to make of this. Whatever happens with
> non-default options is probably in "implementation-defined"
> domain as far as the C Standard is concerned, but I still
> expected that such common option as  -I would not affect standard
> headers.

According to the GNU cpp manual, the "-I" option prepends directories to
the search path used for <> headers, and the "-iquote" option prepends
directories to the search path used for "" headers.

I find that a bit surprising.  I had never heard of the "-iquote"
option.

-- 
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]

#383590

On 13/03/2024 16:15, Keith Thompson wrote:
> Michael S <already5chosen@yahoo.com> writes:
> [...]
>> I just tried three compilers and [in absence of -I options] all 3 work
>> as expected, i.e. ignored stdio.h in current directory.
>> None of the three was of the variety that you appear to prefer.
>> Mine's are mundane stuff.
>>
>> However all three took local file when I had given them an option -I.
>> Not sure what to make of this. Whatever happens with
>> non-default options is probably in "implementation-defined"
>> domain as far as the C Standard is concerned, but I still
>> expected that such common option as  -I would not affect standard
>> headers.
> 
> According to the GNU cpp manual, the "-I" option prepends directories to
> the search path used for <> headers, and the "-iquote" option prepends
> directories to the search path used for "" headers.
> 
> I find that a bit surprising.

You are not quite correct - and I find /that/ a bit surprising!

The -I option applies equally to <...> and "..." headers.

>  I had never heard of the "-iquote"
> option.
> 

The complete description is here: 
<https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html>.  (It is the 
same in the cpp manual, but it is better to look at the compiler manual 
for this kind of thing - after all, the gcc driver program can pass 
different options to the cpp subprogram.)

To save people looking it up:



-I dir
-iquote dir
-isystem dir
-idirafter dir

     Add the directory dir to the list of directories to be searched for 
header files during preprocessing. If dir begins with ‘=’ or $SYSROOT, 
then the ‘=’ or $SYSROOT is replaced by the sysroot prefix; see 
--sysroot and -isysroot.

     Directories specified with -iquote apply only to the quote form of 
the directive, #include "file". Directories specified with -I, -isystem, 
or -idirafter apply to lookup for both the #include "file" and #include 
<file> directives.

     You can specify any number or combination of these options on the 
command line to search for header files in several directories. The 
lookup order is as follows:

         For the quote form of the include directive, the directory of 
the current file is searched first.
         For the quote form of the include directive, the directories 
specified by -iquote options are searched in left-to-right order, as 
they appear on the command line.
         Directories specified with -I options are scanned in 
left-to-right order.
         Directories specified with -isystem options are scanned in 
left-to-right order.
         Standard system directories are scanned.
         Directories specified with -idirafter options are scanned in 
left-to-right order.

     You can use -I to override a system header file, substituting your 
own version, since these directories are searched before the standard 
system header file directories. However, you should not use this option 
to add directories that contain vendor-supplied system header files; use 
-isystem for that.

     The -isystem and -idirafter options also mark the directory as a 
system directory, so that it gets the same special treatment that is 
applied to the standard system directories.

     If a standard system include directory, or a directory specified 
with -isystem, is also specified with -I, the -I option is ignored. The 
directory is still searched but as a system directory at its normal 
position in the system include chain. This is to ensure that GCC’s 
procedure to fix buggy system headers and the ordering for the 
#include_next directive are not inadvertently changed. If you really 
need to change the search order for system directories, use the 
-nostdinc and/or -isystem options.

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

#383591

David Brown <david.brown@hesbynett.no> writes:
> On 13/03/2024 16:15, Keith Thompson wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>> [...]
>>> I just tried three compilers and [in absence of -I options] all 3 work
>>> as expected, i.e. ignored stdio.h in current directory.
>>> None of the three was of the variety that you appear to prefer.
>>> Mine's are mundane stuff.
>>>
>>> However all three took local file when I had given them an option -I.
>>> Not sure what to make of this. Whatever happens with
>>> non-default options is probably in "implementation-defined"
>>> domain as far as the C Standard is concerned, but I still
>>> expected that such common option as  -I would not affect standard
>>> headers.
>> According to the GNU cpp manual, the "-I" option prepends
>> directories to
>> the search path used for <> headers, and the "-iquote" option prepends
>> directories to the search path used for "" headers.
>> I find that a bit surprising.
>
> You are not quite correct - and I find /that/ a bit surprising!
>
> The -I option applies equally to <...> and "..." headers.

I believe that's consistent with what I wrote, though I probably wasn't
clear enough.  To expand on it:

There are two lists of locations (typically directories).  Let's call
them the <>-list (described in N1570 6.10.2p2) and the ""-list
(described in N1570 6.10.2p3).

#include <foo.h> searches the <>-list.

#include "foo.h" searches the ""-list; if that fails, it then searches
the <>-list as if for #include <foo.h>.

The -I option prepends directories to the <>-list, which means it
affects both #include <foo.h> and #include "foo.h".  But for
#include "foo.h", a foo.h file in the same directory as the including
file will always be found first if it exists.

[...]

> The complete description is here:
> <https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html>.
[...]
[slightly reformatting quoted text]
>      1. For the quote form of the include directive, the directory of
>         the current file is searched first.
>
>      2. For the quote form of the include directive, the directories
>         specified by -iquote options are searched in left-to-right
>         order, as they appear on the command line.
>
>      3. Directories specified with -I options are scanned in
>         left-to-right order.
>
>      4. Directories specified with -isystem options are scanned in
>         left-to-right order.
>
>      5. Standard system directories are scanned.
>
>      6. Directories specified with -idirafter options are scanned in
>         left-to-right order.

What I called the ""-list is described in steps 1-2.
What I called the <>-list is described in steps 3-6.

[...]

-- 
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]

#383592

On 13/03/2024 19:56, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 13/03/2024 16:15, Keith Thompson wrote:
>>> Michael S <already5chosen@yahoo.com> writes:
>>> [...]
>>>> I just tried three compilers and [in absence of -I options] all 3 work
>>>> as expected, i.e. ignored stdio.h in current directory.
>>>> None of the three was of the variety that you appear to prefer.
>>>> Mine's are mundane stuff.
>>>>
>>>> However all three took local file when I had given them an option -I.
>>>> Not sure what to make of this. Whatever happens with
>>>> non-default options is probably in "implementation-defined"
>>>> domain as far as the C Standard is concerned, but I still
>>>> expected that such common option as  -I would not affect standard
>>>> headers.
>>> According to the GNU cpp manual, the "-I" option prepends
>>> directories to
>>> the search path used for <> headers, and the "-iquote" option prepends
>>> directories to the search path used for "" headers.
>>> I find that a bit surprising.
>>
>> You are not quite correct - and I find /that/ a bit surprising!
>>
>> The -I option applies equally to <...> and "..." headers.
> 
> I believe that's consistent with what I wrote, though I probably wasn't
> clear enough.

Yes, after reading your expanded explanation, I agree with you here 
(both parts).  Thanks for that clarification.

> To expand on it:
> 
> There are two lists of locations (typically directories).  Let's call
> them the <>-list (described in N1570 6.10.2p2) and the ""-list
> (described in N1570 6.10.2p3).
> 
> #include <foo.h> searches the <>-list.
> 
> #include "foo.h" searches the ""-list; if that fails, it then searches
> the <>-list as if for #include <foo.h>.
> 
> The -I option prepends directories to the <>-list, which means it
> affects both #include <foo.h> and #include "foo.h".  But for
> #include "foo.h", a foo.h file in the same directory as the including
> file will always be found first if it exists.
> 
> [...]
> 
>> The complete description is here:
>> <https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html>.
> [...]
> [slightly reformatting quoted text]
>>       1. For the quote form of the include directive, the directory of
>>          the current file is searched first.
>>
>>       2. For the quote form of the include directive, the directories
>>          specified by -iquote options are searched in left-to-right
>>          order, as they appear on the command line.
>>
>>       3. Directories specified with -I options are scanned in
>>          left-to-right order.
>>
>>       4. Directories specified with -isystem options are scanned in
>>          left-to-right order.
>>
>>       5. Standard system directories are scanned.
>>
>>       6. Directories specified with -idirafter options are scanned in
>>          left-to-right order.
> 
> What I called the ""-list is described in steps 1-2.
> What I called the <>-list is described in steps 3-6.
> 
> [...]
> 

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

#383583

On 13/03/2024 13:12, Michael S wrote:
> On Wed, 13 Mar 2024 11:45:31 +0000
> bart <bc@freeuk.com> wrote:
>>
>>
>> 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.

I'd agree it seems a poor choice of defaults.

As you know, the details of the searching mechanism is 
implementation-dependent.  But it is common practice to have two lists 
of paths - one for "system headers" (for #include <...>), and one for 
"user headers" (for #include "...").  (The C standards refer to the 
former as "headers" and the later just as "source files for inclusion", 
but I think the system/user header file distinction is more user-friendly!)

The system header path typically includes first the directory or 
directories containing the standard library headers, but can also 
include OS-specific headers, POSIX headers, and any other headers that 
are considered part of the C implementation.  (For cross-compilers, 
these will directories with for the target's C library headers rather 
than the host files.)

The user header path will typically be just the directory of the source 
file, but may also include the current directory.

Command-line flags generally allow you to replace or extend these.

A failed search for a "..." file should move on to the system header 
path, but not vice-versa.


So, which compilers (and relevant flags) had the system header search 
start in the current directory?  It is not disallowed, AFAIUI, but it 
seems a bad idea to me.


>>
>> 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 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 "...".)
>>
>>
> 
> I just tried three compilers and [in absence of -I options] all 3 work
> as expected, i.e. ignored stdio.h in current directory.
> None of the three was of the variety that you appear to prefer.
> Mine's are mundane stuff.
> 
> However all three took local file when I had given them an option -I.
> Not sure what to make of this.

What exactly was the "-I" option you gave (and which compiler)?  If you 
wrote "-I.", including the dot, then gcc will act the way you describe - 
that's what the flag does.  If you put other directories in the -I list, 
it does not look in the current directory.

<https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html>

> Whatever happens with
> non-default options is probably in "implementation-defined"
> domain as far as the C Standard is concerned, but I still
> expected that such common option as  -I would not affect standard
> headers.
> 

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

#383585

On 2024-03-13, Michael S <already5chosen@yahoo.com> wrote:
> I just tried three compilers and [in absence of -I options] all 3 work
> as expected, i.e. ignored stdio.h in current directory. 
> None of the three was of the variety that you appear to prefer.
> Mine's are mundane stuff.
>
> However all three took local file when I had given them an option -I. 

Yes; the traditional -I option is idiotic for the majority of the use
cases for which it has actually been used. This is why GCC introduced
-iquote; that's what you want to be using within a project for
redirecting your local #include "...".

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

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

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

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

csiph-web