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

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

Why is this happening?

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

Contents

  Why is this happening? DFS <nospam@dfs.com> - 2026-03-27 00:12 -0400
    Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-27 05:46 +0100
      Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-27 06:01 +0100
        Re: Why is this happening? DFS <nospam@dfs.com> - 2026-03-27 02:31 -0400
      Re: Why is this happening? Josef Möllers <josef@invalid.invalid> - 2026-03-27 10:15 +0100
        Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-27 16:02 +0000
          Re: Why is this happening? Josef Möllers <josef@invalid.invalid> - 2026-03-28 21:58 +0100
            Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-29 14:30 +0200
              Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-29 18:56 +0000
                Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-30 02:00 +0200
              Re: Why is this happening? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-03-30 00:41 +0100
                Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-30 09:25 +0200
                  Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 11:23 +0300
                    Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-30 11:16 +0200
                      Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 13:06 +0300
        Re: Why is this happening? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-28 01:46 +0000
          Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-27 20:41 -0700
            Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-28 05:17 +0100
              Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-28 10:09 +0100
                Re: Why is this happening? Bart <bc@freeuk.com> - 2026-03-28 11:33 +0000
                  Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-28 16:35 +0100
                    Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-28 16:56 +0000
                    Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-28 16:58 +0000
                      Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-28 19:24 -0400
                      Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-29 11:33 +0200
                        Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-29 16:30 +0100
                          Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-29 10:37 -0700
                            Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-31 16:20 +0200
                              Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-31 17:19 +0100
                        Re: Why is this happening? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-29 13:19 -0700
                          Re: Why is this happening? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-29 13:26 -0700
                          Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 14:14 -0700
                            Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-29 20:47 -0400
                        Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 13:57 -0700
                          Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-31 16:26 +0200
            Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-28 15:14 +0000
              Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-28 10:18 -0700
                Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-29 18:50 +0000
              Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-28 19:12 -0700
                Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-28 22:31 -0700
                  Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 12:11 -0700
                    Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-06 14:20 -0700
                      Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-04-07 02:05 +0300
                        Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-06 17:42 -0700
                      Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-27 20:36 -0700
                        Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-27 20:58 -0700
                Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-29 14:43 -0700
              Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-29 11:50 +0300
                Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 13:54 -0700
                  Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 02:05 +0300
                    Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 16:22 -0700
                      Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 10:57 +0300
                  Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-30 20:37 -0400
                    Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-31 11:48 +0300
                      Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-31 10:51 -0400
                    Re: Why is this happening? candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2026-03-31 19:00 +0000
          Re: Why is this happening? Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-04-03 02:41 +0100

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

#397250

On 28/03/2026 12:33, Bart wrote:
> On 28/03/2026 09:09, David Brown wrote:
>> On 28/03/2026 05:17, Janis Papanagnou wrote:
>>> On 2026-03-28 04:41, Keith Thompson wrote:
>>>> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>>>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef Möllers wrote:
>>>>>
>>>>>>       diffns += 1000000000UL;
>>>>>
>>>>> Can you write
>>>>>
>>>>>        diffns += 1_000_000_000UL;
>>>>>
>>>>> yet?
>>>>
>>>> Not in C.  C23 introduces the apostrophe as a digit separator, copied
>>>> from C++:
>>>>
>>>>        diffns += 1'000'000'000UL;
>>>
>>> I think that's fine, much better than parsing those huge numbers.
>>> (A convention used in Switzerland, IIRC.)
>>>
>>>>
>>>> (I would have preferred underscores, but that would have conflicted
>>>> with C++'s user-defined literals.)
>>>
>>> I wonder why; user-defined literals for names start with alpha or
>>> underscore, no? - Where's the conflict?
>>>
>>
>> 123_456 would, in C++, be parsed as the integer constant 123 then the 
>> user-defined literal identifier _456.  Thus C++ could not use 
>> underscore as a digit separator, and choose apostrophes instead.  C23 
>> followed that because there is a strong preference for keeping 
>> consistency between the languages for common features.  (And maybe 
>> someone will want to add user-defined literals of some kind to C in 
>> the future.)
>>
> 
> Would 123 _456 (with intervening white-space) be meaningful in any of C+ 
> +'s syntax? That is, a numeric literal followed by an identifier.

It would be interpreted as two tokens.  So in this case, it is unlikely 
to be meaningful unless you first had "#define _456 +1", or something 
like that.  Just like for C.

> 
> If not then the lexical grammar could have been changed so that 
> underlines could be part of numeric literals, just not at the start.
> 

Certainly C++ could have be defined to make _ part of the numeric 
literal syntax.

> (I hadn't realised until now that _1234 is a valid identifier in C. 
> Fortunately most haven't either, or sensibly avoid it.)

Well, underscore basically counts as a letter, so it's a valid 
identifier just like "x1234" would be.  Sometimes people use identifiers 
like that for specific purposes, like macro parameters.

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

#397251

On 28/03/2026 15:35, David Brown wrote:
> On 28/03/2026 12:33, Bart wrote:
>> On 28/03/2026 09:09, David Brown wrote:
>>> On 28/03/2026 05:17, Janis Papanagnou wrote:
>>>> On 2026-03-28 04:41, Keith Thompson wrote:
>>>>> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>>>>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef Möllers wrote:
>>>>>>
>>>>>>>       diffns += 1000000000UL;
>>>>>>
>>>>>> Can you write
>>>>>>
>>>>>>        diffns += 1_000_000_000UL;
>>>>>>
>>>>>> yet?
>>>>>
>>>>> Not in C.  C23 introduces the apostrophe as a digit separator, copied
>>>>> from C++:
>>>>>
>>>>>        diffns += 1'000'000'000UL;
>>>>
>>>> I think that's fine, much better than parsing those huge numbers.
>>>> (A convention used in Switzerland, IIRC.)
>>>>
>>>>>
>>>>> (I would have preferred underscores, but that would have conflicted
>>>>> with C++'s user-defined literals.)
>>>>
>>>> I wonder why; user-defined literals for names start with alpha or
>>>> underscore, no? - Where's the conflict?
>>>>
>>>
>>> 123_456 would, in C++, be parsed as the integer constant 123 then the 
>>> user-defined literal identifier _456.  Thus C++ could not use 
>>> underscore as a digit separator, and choose apostrophes instead.  C23 
>>> followed that because there is a strong preference for keeping 
>>> consistency between the languages for common features.  (And maybe 
>>> someone will want to add user-defined literals of some kind to C in 
>>> the future.)
>>>
>>
>> Would 123 _456 (with intervening white-space) be meaningful in any of 
>> C+ +'s syntax? That is, a numeric literal followed by an identifier.
> 
> It would be interpreted as two tokens.  So in this case, it is unlikely 
> to be meaningful unless you first had "#define _456 +1", or something 
> like that.  Just like for C.
> 
>>
>> If not then the lexical grammar could have been changed so that 
>> underlines could be part of numeric literals, just not at the start.
>>
> 
> Certainly C++ could have be defined to make _ part of the numeric 
> literal syntax.
> 
>> (I hadn't realised until now that _1234 is a valid identifier in C. 
>> Fortunately most haven't either, or sensibly avoid it.)
> 
> Well, underscore basically counts as a letter, so it's a valid 
> identifier just like "x1234" would be.  Sometimes people use identifiers 
> like that for specific purposes, like macro parameters.
> 
> 

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

#397252

On 28/03/2026 15:35, David Brown wrote:
> Well, underscore basically counts as a letter, so it's a valid 
> identifier just like "x1234" would be.  Sometimes people use identifiers 
> like that for specific purposes, like macro parameters.

Isn't _UPPERCASE and __anything reserved for the implementation?

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

#397259

On 2026-03-28 12:58, Richard Harnden wrote:
> On 28/03/2026 15:35, David Brown wrote:
>> Well, underscore basically counts as a letter, so it's a valid
>> identifier just like "x1234" would be.  Sometimes people use
>> identifiers like that for specific purposes, like macro parameters.
>
> Isn't _UPPERCASE and __anything reserved for the implementation?

Correct. But _1234 fits neither of those categories. It does fit a third
category:

"All identifiers that begin with an underscore are reserved for use as
identifiers with file scope in both the ordinary and tag name spaces."
(6.4.3.1p7).

However, you can still define such identifiers in other scopes, or in
other name spaces. As far as I can tell, none of those possibilities
helps in this particular case.

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

#397268

On 28/03/2026 17:58, Richard Harnden wrote:
> On 28/03/2026 15:35, David Brown wrote:
>> Well, underscore basically counts as a letter, so it's a valid 
>> identifier just like "x1234" would be.  Sometimes people use 
>> identifiers like that for specific purposes, like macro parameters.
> 
> Isn't _UPPERCASE and __anything reserved for the implementation?
> 
> 

Yes.

And identifiers with _lowercase have implicit internal linkage (when 
they would otherwise have had implicit external linkage).  That's why I 
wrote "underscore /basically/ counts as a letter" - to save mentioning 
all the details.

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

#397272

On 29/03/2026 10:33, David Brown wrote:
> On 28/03/2026 17:58, Richard Harnden wrote:
>> On 28/03/2026 15:35, David Brown wrote:
>>> Well, underscore basically counts as a letter, so it's a valid 
>>> identifier just like "x1234" would be.  Sometimes people use 
>>> identifiers like that for specific purposes, like macro parameters.
>>
>> Isn't _UPPERCASE and __anything reserved for the implementation?
>>
>>
> 
> Yes.
> 
> And identifiers with _lowercase have implicit internal linkage (when 
> they would otherwise have had implicit external linkage).  That's why I 
> wrote "underscore /basically/ counts as a letter" - to save mentioning 
> all the details.
> 

I didn't know that, thanks.

So, at file scope, these are equivalent ... ?
    static int foo;
    int _foo;

Is _foo initialised to zero?

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

#397273

Richard Harnden <richard.nospam@gmail.invalid> writes:

> On 29/03/2026 10:33, David Brown wrote:
>
>> On 28/03/2026 17:58, Richard Harnden wrote:
>>
>>> On 28/03/2026 15:35, David Brown wrote:
>>>
>>>> Well, underscore basically counts as a letter, so it's a valid
>>>> identifier just like "x1234" would be.  Sometimes people use
>>>> identifiers like that for specific purposes, like macro
>>>> parameters.
>>>
>>> Isn't _UPPERCASE and __anything reserved for the implementation?
>>
>> Yes.
>>
>> And identifiers with _lowercase have implicit internal linkage (when
>> they would otherwise have had implicit external linkage).  That's
>> why I wrote "underscore /basically/ counts as a letter" - to save
>> mentioning all the details.
>
> I didn't know that, thanks.

Don't believe everything you read.  Of course, as far as the C
standard is concerned, defining a reserved name is undefined
behavior, but actual compilers have different behavior than what
is suggested above.

> So, at file scope, these are equivalent ... ?
>    static int foo;
>    int _foo;

If you try with gcc or clang (which I did), I expect you will
find that _foo is an ordinary global symbol.  It does not have
"implicit internal linkage".  It is treated just like any other
external definition.

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

#397330

On 29/03/2026 19:37, Tim Rentsch wrote:
> Richard Harnden <richard.nospam@gmail.invalid> writes:
> 
>> On 29/03/2026 10:33, David Brown wrote:
>>
>>> On 28/03/2026 17:58, Richard Harnden wrote:
>>>
>>>> On 28/03/2026 15:35, David Brown wrote:
>>>>
>>>>> Well, underscore basically counts as a letter, so it's a valid
>>>>> identifier just like "x1234" would be.  Sometimes people use
>>>>> identifiers like that for specific purposes, like macro
>>>>> parameters.
>>>>
>>>> Isn't _UPPERCASE and __anything reserved for the implementation?
>>>
>>> Yes.
>>>
>>> And identifiers with _lowercase have implicit internal linkage (when
>>> they would otherwise have had implicit external linkage).  That's
>>> why I wrote "underscore /basically/ counts as a letter" - to save
>>> mentioning all the details.
>>
>> I didn't know that, thanks.
> 
> Don't believe everything you read.  Of course, as far as the C
> standard is concerned, defining a reserved name is undefined
> behavior, but actual compilers have different behavior than what
> is suggested above.
> 
>> So, at file scope, these are equivalent ... ?
>>     static int foo;
>>     int _foo;
> 
> If you try with gcc or clang (which I did), I expect you will
> find that _foo is an ordinary global symbol.  It does not have
> "implicit internal linkage".  It is treated just like any other
> external definition.
> 

Thanks for the correction.  Identifiers starting with an underscore are 
"reserved for file scope".  I believe that means non-static file-scope 
"int _foo;" is therefore UB, but there is no implied "static".

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

#397333

On 31/03/2026 15:20, David Brown wrote:
> On 29/03/2026 19:37, Tim Rentsch wrote:
>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>
>>> On 29/03/2026 10:33, David Brown wrote:
>>>
>>>> On 28/03/2026 17:58, Richard Harnden wrote:
>>>>
>>>>> On 28/03/2026 15:35, David Brown wrote:
>>>>>
>>>>>> Well, underscore basically counts as a letter, so it's a valid
>>>>>> identifier just like "x1234" would be.  Sometimes people use
>>>>>> identifiers like that for specific purposes, like macro
>>>>>> parameters.
>>>>>
>>>>> Isn't _UPPERCASE and __anything reserved for the implementation?
>>>>
>>>> Yes.
>>>>
>>>> And identifiers with _lowercase have implicit internal linkage (when
>>>> they would otherwise have had implicit external linkage).  That's
>>>> why I wrote "underscore /basically/ counts as a letter" - to save
>>>> mentioning all the details.
>>>
>>> I didn't know that, thanks.
>>
>> Don't believe everything you read.  Of course, as far as the C
>> standard is concerned, defining a reserved name is undefined
>> behavior, but actual compilers have different behavior than what
>> is suggested above.
>>
>>> So, at file scope, these are equivalent ... ?
>>>     static int foo;
>>>     int _foo;
>>
>> If you try with gcc or clang (which I did), I expect you will
>> find that _foo is an ordinary global symbol.  It does not have
>> "implicit internal linkage".  It is treated just like any other
>> external definition.
>>
> b
> Thanks for the correction.  Identifiers starting with an underscore are 
> "reserved for file scope".  I believe that means non-static file-scope 
> "int _foo;" is therefore UB, but there is no implied "static".
> 
> 

Thanks.  I think I will simply avoid avoid any variable names prefixed 
with an '_'.

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

#397278

On 3/29/2026 2:33 AM, David Brown wrote:
> On 28/03/2026 17:58, Richard Harnden wrote:
>> On 28/03/2026 15:35, David Brown wrote:
>>> Well, underscore basically counts as a letter, so it's a valid 
>>> identifier just like "x1234" would be.  Sometimes people use 
>>> identifiers like that for specific purposes, like macro parameters.
>>
>> Isn't _UPPERCASE and __anything reserved for the implementation?
>>
>>
> 
> Yes.
> 
> And identifiers with _lowercase have implicit internal linkage (when 
> they would otherwise have had implicit external linkage).  That's why I 
> wrote "underscore /basically/ counts as a letter" - to save mentioning 
> all the details.
> 

Actually, I remember back in the day when I used to use _this. Some 
people said it is actually "okay", then I switched to self...

struct foo
{
     int bar;
};


void foo_init(struct foo* _this);

vs

void foo_init(struct foo* self);


Now, lets ponder on *_t?

struct foo_t ?

intrude into POSIX?

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

#397279

On 3/29/2026 1:19 PM, Chris M. Thomasson wrote:
> On 3/29/2026 2:33 AM, David Brown wrote:
>> On 28/03/2026 17:58, Richard Harnden wrote:
>>> On 28/03/2026 15:35, David Brown wrote:
>>>> Well, underscore basically counts as a letter, so it's a valid 
>>>> identifier just like "x1234" would be.  Sometimes people use 
>>>> identifiers like that for specific purposes, like macro parameters.
>>>
>>> Isn't _UPPERCASE and __anything reserved for the implementation?
>>>
>>>
>>
>> Yes.
>>
>> And identifiers with _lowercase have implicit internal linkage (when 
>> they would otherwise have had implicit external linkage).  That's why 
>> I wrote "underscore /basically/ counts as a letter" - to save 
>> mentioning all the details.
>>
> 
> Actually, I remember back in the day when I used to use _this. Some 
> people said it is actually "okay", then I switched to self...
> 
> struct foo
> {
>      int bar;
> };
> 
> 
> void foo_init(struct foo* _this);
> 
> vs
> 
> void foo_init(struct foo* self);
> 
> 
> Now, lets ponder on *_t?
> 
> struct foo_t ?
> 
> intrude into POSIX?

I like x_y_z, say foolib_read_types where x = foolib, y = read, z = types?

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

#397282

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
[...]
> Now, lets ponder on *_t?
>
> struct foo_t ?
>
> intrude into POSIX?

I don't know.  I know that POSIX reserves the _t suffix for type
names, but I haven't been able to find the actual requirement in
the POSIX standard.  It would depend on the exact wording.

In "struct foo_t", "foo_t is not a type name, but "struct foo_t" is.

I wouldn't use a "_t" suffix on a struct tag.  The required "struct"
keyword is enough to indicate that it's a type.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#397291

On 2026-03-29 17:14, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> [...]
>> Now, lets ponder on *_t?
>>
>> struct foo_t ?
>>
>> intrude into POSIX?
>
> I don't know. I know that POSIX reserves the _t suffix for type
> names, but I haven't been able to find the actual requirement in
> the POSIX standard. It would depend on the exact wording.

Section 2.2.2 "The Name Space" has a table listing headers and their
corresponding reserved identifiers. The very last entry in the table
applies to "any header" and specifies a suffix of "_t". This doesn't
identify the purpose for which it is reserved - which might be explained
elsewhere.

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

#397281

David Brown <david.brown@hesbynett.no> writes:
> On 28/03/2026 17:58, Richard Harnden wrote:
>> On 28/03/2026 15:35, David Brown wrote:
>>> Well, underscore basically counts as a letter, so it's a valid
>>> identifier just like "x1234" would be.  Sometimes people use
>>> identifiers like that for specific purposes, like macro parameters.
>> Isn't _UPPERCASE and __anything reserved for the implementation?
>
> Yes.
>
> And identifiers with _lowercase have implicit internal linkage (when
> they would otherwise have had implicit external linkage).  That's why
> I wrote "underscore /basically/ counts as a letter" - to save
> mentioning all the details.

I don't believe that's correct.  The language defines rules about
which identifiers are reserved depending on how they're spelled,
but I've never seen a rule that says the linkage of an identifier
is affected by its spelling.  (A compiler could take advantage of
undefined behavior to do something weird, but I believe and hope
that no compilers actually do so.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#397331

On 29/03/2026 22:57, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 28/03/2026 17:58, Richard Harnden wrote:
>>> On 28/03/2026 15:35, David Brown wrote:
>>>> Well, underscore basically counts as a letter, so it's a valid
>>>> identifier just like "x1234" would be.  Sometimes people use
>>>> identifiers like that for specific purposes, like macro parameters.
>>> Isn't _UPPERCASE and __anything reserved for the implementation?
>>
>> Yes.
>>
>> And identifiers with _lowercase have implicit internal linkage (when
>> they would otherwise have had implicit external linkage).  That's why
>> I wrote "underscore /basically/ counts as a letter" - to save
>> mentioning all the details.
> 
> I don't believe that's correct.  The language defines rules about
> which identifiers are reserved depending on how they're spelled,
> but I've never seen a rule that says the linkage of an identifier
> is affected by its spelling.  (A compiler could take advantage of
> undefined behavior to do something weird, but I believe and hope
> that no compilers actually do so.)
> 

I was incorrect in what I wrote - I looked it up again after reading 
Tim's post.  Identifiers starting with an underscore are reserved for 
file-scope, but do not automatically get internal linkage.

(I have seen code where it appears the programmer assumed functions with 
names starting with an underscore were internal linkage.  I did not like 
the way it was written, but I had assumed it was correct.  Most likely, 
the code worked fine simply because there were no other uses of the same 
identifier in other TUs.)

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

#397249

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef Möllers wrote:
>>
>>>      diffns += 1000000000UL;
>>
>> Can you write
>>
>>       diffns += 1_000_000_000UL;
>>
>> yet?
>
>Not in C.  C23 introduces the apostrophe as a digit separator, copied
>from C++:
>
>      diffns += 1'000'000'000UL;

Or diffns += 1000ul * 1000ul * 1000ul;

or diffns += 1 * NS_PER_SEC;

with
#define NS_PER_SEC ((1000ul * 1000ul * 1000ul))

>
>(I would have preferred underscores, but that would have conflicted
>with C++'s user-defined literals.)

Likewise, I'd prefer the underscore.   IIRC, that's what is used
in Verilog.

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

#397253

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef Möllers wrote:
>>>
>>>>      diffns += 1000000000UL;
>>>
>>> Can you write
>>>
>>>       diffns += 1_000_000_000UL;
>>>
>>> yet?
>>
>>Not in C.  C23 introduces the apostrophe as a digit separator, copied
>>from C++:
>>
>>      diffns += 1'000'000'000UL;
>
> Or diffns += 1000ul * 1000ul * 1000ul;
>
> or diffns += 1 * NS_PER_SEC;
>
> with
> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))

Why the "1 *"?  And why two sets of parentheses?

An integer constant is always of a type big enough to hold its value.
The same does not hold for larger expressions.  It doesn't matter in
this case, since ULONG_MAX is guaranteed to be bigger than
1'000'000'000, but it can be a problem in more general cases.

>>(I would have preferred underscores, but that would have conflicted
>>with C++'s user-defined literals.)
>
> Likewise, I'd prefer the underscore.   IIRC, that's what is used
> in Verilog.

And Python, and Perl, and Ada, and a number of other languages.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#397276

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef Möllers wrote:
>>>>
>>>>>      diffns += 1000000000UL;
>>>>
>>>> Can you write
>>>>
>>>>       diffns += 1_000_000_000UL;
>>>>
>>>> yet?
>>>
>>>Not in C.  C23 introduces the apostrophe as a digit separator, copied
>>>from C++:
>>>
>>>      diffns += 1'000'000'000UL;
>>
>> Or diffns += 1000ul * 1000ul * 1000ul;
>>
>> or diffns += 1 * NS_PER_SEC;
>>
>> with
>> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))
>
>Why the "1 *"?  And why two sets of parentheses?

a) Because I usually use a variable there.
b) Korn Shell syntax for arithmetic expressions
   when typing on auto-pilot.

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

#397261

scott@slp53.sl.home (Scott Lurndal) writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Lawrence D <<E2>> ??Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M@C3{B6}llers wrote:
>>>
>>>>      diffns += 1000000000UL;
>>>
>>> Can you write
>>>
>>>       diffns += 1_000_000_000UL;
>>>
>>> yet?
>>
>> Not in C.  C23 introduces the apostrophe as a digit separator, copied
>> from C++:
>>
>>      diffns += 1'000'000'000UL;
>
> Or diffns += 1000ul * 1000ul * 1000ul;
>
> or diffns += 1 * NS_PER_SEC;
>
> with
> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))
>
>> (I would have preferred underscores, but that would have conflicted
>> with C++'s user-defined literals.)
>
> Likewise, I'd prefer the underscore.

Ditto.  And there is no reason C could have allowed both,
and C++ be damned.

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

#397262

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Lawrence D <<E2>> ??Oliveiro <ldo@nz.invalid> writes:
>>>> On Fri, 27 Mar 2026 10:15:23 +0100, Josef M@C3{B6}llers wrote:
>>>>>      diffns += 1000000000UL;
>>>>
>>>> Can you write
>>>>
>>>>       diffns += 1_000_000_000UL;
>>>>
>>>> yet?
>>>
>>> Not in C.  C23 introduces the apostrophe as a digit separator, copied
>>> from C++:
>>>
>>>      diffns += 1'000'000'000UL;
>>
>> Or diffns += 1000ul * 1000ul * 1000ul;
>>
>> or diffns += 1 * NS_PER_SEC;
>>
>> with
>> #define NS_PER_SEC ((1000ul * 1000ul * 1000ul))
>>
>>> (I would have preferred underscores, but that would have conflicted
>>> with C++'s user-defined literals.)
>>
>> Likewise, I'd prefer the underscore.
>
> Ditto.  And there is no reason C could have allowed both,
> and C++ be damned.

(I think you omitted a "not".)

Using apostrophes is IMHO far better than either allowing two
arbitrarily distinct syntaxes or a gratuitous incompatibility
with C++.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

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

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

csiph-web