Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #397990 > unrolled thread
| Started by | John Forkosh <forkosh@panix.com> |
|---|---|
| First post | 2026-04-26 13:59 +0000 |
| Last post | 2026-04-26 16:56 +0000 |
| Articles | 20 on this page of 122 — 16 participants |
Back to article view | Back to comp.lang.c
function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 13:59 +0000
Re: function declaration without args no longer works Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-04-26 16:24 +0200
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 16:29 +0000
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-04 19:36 +0000
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-05 00:15 -0700
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-05 09:10 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-05-05 11:17 +0200
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-05 11:07 +0000
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 02:24 -0700
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-05 11:20 +0000
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 18:09 +0000
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-07 12:52 +0000
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 14:51 +0000
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-06 11:41 +0200
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-05 10:03 -0700
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-05-07 12:35 +0000
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 07:36 -0700
Re: function declaration without args no longer works antispam@fricas.org (Waldek Hebisch) - 2026-05-08 18:39 +0000
Re: function declaration without args no longer works richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-04-26 14:32 +0000
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 16:35 +0000
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-29 16:43 -0700
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-30 08:39 +0200
Re: function declaration without args no longer works Michael S <already5chosen@yahoo.com> - 2026-04-26 17:50 +0300
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 16:39 +0000
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-27 00:30 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-27 08:30 +0200
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-28 07:02 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 10:16 +0200
Re: function declaration without args no longer works antispam@fricas.org (Waldek Hebisch) - 2026-04-28 15:33 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 20:24 +0200
Re: function declaration without args no longer works antispam@fricas.org (Waldek Hebisch) - 2026-04-28 20:22 +0000
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-29 06:22 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-29 09:15 +0200
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-29 10:06 +0200
Re: function declaration without args no longer works Michael S <already5chosen@yahoo.com> - 2026-04-29 11:25 +0300
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-29 11:26 +0200
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-29 20:07 -0400
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 00:14 +0000
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-29 17:57 -0700
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-30 03:09 +0200
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 00:48 -0700
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-30 20:18 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-01 04:12 +0000
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-30 23:29 -0700
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-01 19:31 +0200
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-01 13:49 -0400
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-01 12:49 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-01 22:31 +0000
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-02 00:13 +0000
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-01 19:27 -0700
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-01 19:28 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-02 03:07 +0000
Re: function declaration without args no longer works scott@slp53.sl.home (Scott Lurndal) - 2026-05-02 16:16 +0000
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 01:39 +0000
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 00:38 -0700
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-30 03:07 -0700
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 05:54 -0700
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-30 14:32 -0700
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-30 09:45 -0400
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 12:48 -0700
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-04-29 11:05 +0100
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-29 16:32 -0700
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 01:22 -0700
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-29 10:42 +0000
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-29 14:31 -0700
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-30 08:42 +0200
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-30 13:17 +0000
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-30 14:40 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 22:14 +0000
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-29 18:55 +0000
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-29 21:19 +0000
Re: function declaration without args no longer works Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-29 16:46 -0700
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-28 14:25 +0200
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-28 13:13 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 15:48 +0200
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-04-28 15:05 +0100
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 16:37 +0200
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-28 14:02 -0700
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-29 09:29 +0200
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-29 02:49 -0700
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-29 20:06 -0400
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-29 17:13 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 00:45 +0000
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-29 21:11 -0400
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 01:40 +0000
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-29 20:09 -0700
Re: function declaration without args no longer works scott@slp53.sl.home (Scott Lurndal) - 2026-04-30 14:57 +0000
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-30 15:07 +0000
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-04-30 16:20 +0100
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-30 16:10 +0000
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-04-30 17:48 +0100
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-30 22:31 +0200
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-30 22:18 +0000
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-05-01 00:25 +0100
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-01 00:08 +0000
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-05-01 01:24 +0100
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-30 17:46 -0700
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-01 01:55 +0000
Re: function declaration without args no longer works Bart <bc@freeuk.com> - 2026-05-01 10:48 +0100
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-01 11:20 +0000
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-30 20:23 -0700
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-05-01 10:32 +0200
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-30 14:43 -0700
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-30 22:34 +0000
Re: function declaration without args no longer works James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-01 13:32 -0400
Re: function declaration without args no longer works scott@slp53.sl.home (Scott Lurndal) - 2026-05-01 18:12 +0000
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-30 03:50 +0200
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-30 08:52 +0200
Re: function declaration without args no longer works "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-28 14:56 -0700
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-28 15:41 -0700
Re: function declaration without args no longer works Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-29 21:20 +0000
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-28 17:14 +0200
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 17:31 +0200
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-28 19:06 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-28 21:44 +0200
Re: function declaration without args no longer works Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-28 17:06 +0200
Re: function declaration without args no longer works cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-28 19:23 +0000
Re: function declaration without args no longer works David Brown <david.brown@hesbynett.no> - 2026-04-26 17:35 +0200
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 16:50 +0000
Re: function declaration without args no longer works Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-26 15:52 -0700
Re: function declaration without args no longer works Andrey Tarasevich <noone@noone.net> - 2026-04-26 08:38 -0700
Re: function declaration without args no longer works John Forkosh <forkosh@panix.com> - 2026-04-26 16:56 +0000
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-29 11:05 +0100 |
| Message-ID | <10ssl5f$3qhoh$1@dont-email.me> |
| In reply to | #398089 |
On 29/04/2026 09:25, Michael S wrote:
> On Wed, 29 Apr 2026 09:15:47 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>>
>> Other people have been using function prototypes for the last 30
>> years of C programming. You don't need to be working in a vacuum to
>> see C99 code. And while consistency of coding style and standard
>> level is absolutely an important consideration when maintaining or
>> modifying existing code, it is a /consideration/ - not an absolute.
>> If I am making small changes to a piece of old C90 code, I'll use
>> C90, but if I am spending a lot of time working on a big
>> modification, and there are no other overriding requirements, I'll
>> write the new stuff in a better style.
>>
>>> But the world I see is full of pre-existing
>>> complications that frequently can't be precisely predicted, and
>>> that often can affect your choice of coding style. Better to be
>>> conservative and safe than flamboyant and sorry. (Not saying
>>> your suggestions are flamboyant, but the sentence sounded
>>> cuter that way:)
>>
>> Modern C lets you write better C - clearer, safer, more efficient.
>> C90 is "conservative and safe" compared to C99 in the same way that
>> cars from the 1950's are "conservative and safe" compared to modern
>> designs.
>>
>> (Of course you can write good C90 and bad C99 - it's the driver that
>> makes the biggest difference to safety.)
>>
>
> The text above sound as if function prototypes were invented for C99.
> Of course, they are not.
>
> In practice there are only 3 features that make difference between C90
> and C99 for majority of coders and all three are "nice to have" rather
> than make a major difference.
> 1. // comments
> 2. declaration does not have to be at the beginning of {} block
> 3. 'long long' integer types and <stdint.h>
4. Anonymous unions and structs within a struct definition:
struct {
int a;
union {
int b;
int c;
int d;
struct {
int e;
int f;
};
};
int g;
} x;
Here, I can write x.a, x.c, x.e, instead of needing x.a, x.u.c, x.u.s.e
etc when the nested union and struct are named u and s respectively.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-29 16:32 -0700 |
| Message-ID | <86bjf11gws.fsf@linuxsc.com> |
| In reply to | #398092 |
Bart <bc@freeuk.com> writes:
> On 29/04/2026 09:25, Michael S wrote:
>
>> On Wed, 29 Apr 2026 09:15:47 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> Other people have been using function prototypes for the last 30
>>> years of C programming. You don't need to be working in a vacuum to
>>> see C99 code. And while consistency of coding style and standard
>>> level is absolutely an important consideration when maintaining or
>>> modifying existing code, it is a /consideration/ - not an absolute.
>>> If I am making small changes to a piece of old C90 code, I'll use
>>> C90, but if I am spending a lot of time working on a big
>>> modification, and there are no other overriding requirements, I'll
>>> write the new stuff in a better style.
>>>
>>>> But the world I see is full of pre-existing
>>>> complications that frequently can't be precisely predicted, and
>>>> that often can affect your choice of coding style. Better to be
>>>> conservative and safe than flamboyant and sorry. (Not saying
>>>> your suggestions are flamboyant, but the sentence sounded
>>>> cuter that way:)
>>>
>>> Modern C lets you write better C - clearer, safer, more efficient.
>>> C90 is "conservative and safe" compared to C99 in the same way that
>>> cars from the 1950's are "conservative and safe" compared to modern
>>> designs.
>>>
>>> (Of course you can write good C90 and bad C99 - it's the driver that
>>> makes the biggest difference to safety.)
>>
>> The text above sound as if function prototypes were invented for C99.
>> Of course, they are not.
>>
>> In practice there are only 3 features that make difference between C90
>> and C99 for majority of coders and all three are "nice to have" rather
>> than make a major difference.
>> 1. // comments
>> 2. declaration does not have to be at the beginning of {} block
>> 3. 'long long' integer types and <stdint.h>
>
> 4. Anonymous unions and structs within a struct definition:
>
> struct {
> int a;
> union {
> int b;
> int c;
> int d;
> struct {
> int e;
> int f;
> };
> };
> int g;
> } x;
>
> Here, I can write x.a, x.c, x.e, instead of needing x.a, x.u.c,
> x.u.s.e etc when the nested union and struct are named u and s
> respectively.
Anonymous structs and unions were added in C11, not C99.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-30 01:22 -0700 |
| Message-ID | <86ik98zwla.fsf@linuxsc.com> |
| In reply to | #398089 |
Michael S <already5chosen@yahoo.com> writes:
> In practice there are only 3 features that make difference between
> C90 and C99 for majority of coders and all three are "nice to have"
> rather than make a major difference.
> 1. // comments
> 2. declaration does not have to be at the beginning of {} block
> 3. 'long long' integer types and <stdint.h>
In my view several items should be added to the list of essential
C99 features. Some of these items are changes programmers may
not even realize they are benefiting from.
Some C90 behaviors no longer allowed:
REMOVED: implicit int
REMOVED: implicit function declaration
return with expression now disallowed in void function,
and vice versa
Some C90 behaviors expanded or improved:
guaranteed length of global identifiers - went from 6 to 31
(and length of local identifiers went from 31 to 63)
initializers for elements of automatic aggregates and unions
no longer required to be constant expressions
Some added language constructs:
boolean type _Bool
for() statement allows the first clause to be a declaration
compound literals
designated initializers
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-04-29 10:42 +0000 |
| Message-ID | <10ssnbe$jbi$1@reader1.panix.com> |
| In reply to | #398086 |
David Brown <david.brown@hesbynett.no> wrote: > The code you posted /had/ a $ character in its identifiers - you /do/ > use it! Presumably you used it following the conventions for VMS naming. You noticed that code had #include <descrip.h> ??? Not "descrip.h" . $ convention for variables in posted code not optional.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-29 14:31 -0700 |
| Message-ID | <10sttbj$7itj$1@kst.eternal-september.org> |
| In reply to | #398093 |
John Forkosh <forkosh@panix.com> writes:
> David Brown <david.brown@hesbynett.no> wrote:
>> The code you posted /had/ a $ character in its identifiers - you /do/
>> use it! Presumably you used it following the conventions for VMS naming.
>
> You noticed that code had #include <descrip.h> ??? Not "descrip.h" .
> $ convention for variables in posted code not optional.
I'm guessing that your point is that you *used* identifiers with
'$' characters, out of necessity, but did not and would not *define*
such identifiers.
I'm only guessing because you didn't make that point clearly,
and you snipped the text in which you discussed '$' in identifiers.
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-30 08:42 +0200 |
| Message-ID | <10sutkp$fb9e$2@dont-email.me> |
| In reply to | #398098 |
On 29/04/2026 23:31, Keith Thompson wrote: > John Forkosh <forkosh@panix.com> writes: >> David Brown <david.brown@hesbynett.no> wrote: >>> The code you posted /had/ a $ character in its identifiers - you /do/ >>> use it! Presumably you used it following the conventions for VMS naming. >> >> You noticed that code had #include <descrip.h> ??? Not "descrip.h" . >> $ convention for variables in posted code not optional. > > I'm guessing that your point is that you *used* identifiers with > '$' characters, out of necessity, but did not and would not *define* > such identifiers. > > I'm only guessing because you didn't make that point clearly, > and you snipped the text in which you discussed '$' in identifiers. > Looking back, it's possible that what John said he did not do is squabble over the use of $ in identifiers, rather than saying he did not use them himself. I think there are two possible interpretations of what he wrote.
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2026-04-30 13:17 +0000 |
| Message-ID | <10svkpj$5mh$1@reader1.panix.com> |
| In reply to | #398120 |
David Brown <david.brown@hesbynett.no> wrote:
> Keith Thompson wrote:
>> John Forkosh <forkosh@panix.com> writes:
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> The code you posted /had/ a $ character in its identifiers - you /do/
>>>> use it! Presumably you used it following the conventions for VMS naming.
>>>
>>> You noticed that code had #include <descrip.h> ??? Not "descrip.h" .
>>> $ convention for variables in posted code not optional.
>>
>> I'm guessing that your point is that you *used* identifiers with
>> '$' characters, out of necessity, but did not and would not *define*
>> such identifiers.
Yes.
>> I'm only guessing because you didn't make that point clearly,
>> and you snipped the text in which you discussed '$' in identifiers.
Seemed abundantly clear to me.
> Looking back, it's possible that what John said he did not do is
> squabble over the use of $ in identifiers, rather than saying he did not
> use them himself. I think there are two possible interpretations of
> what he wrote.
All the above.
By the way, Keith, we could squabble over your sig instead:
void Void(void) { Void(); } /* The recursive call of the void */
Although that construction is syntactically referred to
as recursive, your use is semantically circular.
It never converges to what's (mathematically, in denotational
semantics) called a least fixed point, and it never returns.
You really want to start a chain of ~40 followups squabbling
over that??? Dana Scott would be proud (Not!)
--
John Forkosh
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-30 14:40 -0700 |
| Message-ID | <10t0i8m$vr7b$2@kst.eternal-september.org> |
| In reply to | #398133 |
John Forkosh <forkosh@panix.com> writes:
> David Brown <david.brown@hesbynett.no> wrote:
>> Keith Thompson wrote:
>>> John Forkosh <forkosh@panix.com> writes:
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> The code you posted /had/ a $ character in its identifiers - you /do/
>>>>> use it! Presumably you used it following the conventions for VMS naming.
>>>>
>>>> You noticed that code had #include <descrip.h> ??? Not "descrip.h" .
>>>> $ convention for variables in posted code not optional.
>>>
>>> I'm guessing that your point is that you *used* identifiers with
>>> '$' characters, out of necessity, but did not and would not *define*
>>> such identifiers.
>
> Yes.
>
>>> I'm only guessing because you didn't make that point clearly,
>>> and you snipped the text in which you discussed '$' in identifiers.
>
> Seemed abundantly clear to me.
>
>> Looking back, it's possible that what John said he did not do is
>> squabble over the use of $ in identifiers, rather than saying he did not
>> use them himself. I think there are two possible interpretations of
>> what he wrote.
>
> All the above.
I found your statement unclear, so I tried to clarify it. That's all.
> By the way, Keith, we could squabble over your sig instead:
> void Void(void) { Void(); } /* The recursive call of the void */
Let's not.
[snip]
--
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]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-30 22:14 +0000 |
| Message-ID | <10t0k8l$10lf6$2@dont-email.me> |
| In reply to | #398133 |
On Thu, 30 Apr 2026 13:17:39 -0000 (UTC), John Forkosh wrote: > Although that construction is syntactically referred to as > recursive, your use is semantically circular. It never converges to > what's (mathematically, in denotational semantics) called a least > fixed point, and it never returns. People too often tend to conflate “recursive” with “circular” (i.e. “endless loop”), and then use that as some kind of excuse to be afraid of recursion ...
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-29 18:55 +0000 |
| Message-ID | <10stk66$kk5$1@reader1.panix.com> |
| In reply to | #398085 |
In article <10ss83f$c4t$1@reader1.panix.com>, John Forkosh <forkosh@panix.com> wrote: >David Brown <david.brown@hesbynett.no> wrote: >> [...] > >[snip] > This endless squabbling that I'm now seeing about >using the $ char in variable names is utterly ridiculous. >I'd never do it, but anybody else can do whatever they like. >End of story, as far as I'm concerned. Some believe it is important to understand the standard and what it allows and does not allow, in order to understand the overall countours of the language and its boundaries. The distinction between what the standard classifies as a permissible extension and what is implementation-defined is important, if you are someone writing a compiler. Granted, most of us are not writing compilers that often, but still, I would not categorize those subthreads as either "squabling" or "uttery ridiculuous." Indeed, you evidently got paid to write code that used those extensions because, at some point, someone sat down and hashed out their understanding of what, exactly, the available references for the language at the time said about this very matter. It is very likely they did so in a very similar way to what is happening now. >> [snip] >> There's nothing wrong with a bit of assembly when it is essential >> (things like task switching in an OS) or make a big difference to the >> efficiency. But there is a lot wrong with a library (or in my current >> situation, an RTOS) that is full of assembly for simple tasks that would >> not only be far clearer in C, but almost certainly much more efficient. > >Absolutely. That's one thing we agree on that 110% (or better). >I've always liked the description of C as "a portable assembly language". As mentioned, C as a "portable macro assembler" hasn't really been true since the first optimizing compilers came along in the 1970s. This is a pretty good read on the subject: https://queue.acm.org/detail.cfm?id=3212479 >You can pretty much look at C code and see more-or-less what an >assembler will do with it. And nowadays cc -O3, or whatever, >frequently does a better job than I would/could if programming >exactly the same thing directly in assembly. Eh.... I mean, a lot of folks can eyeball a line of code and guess more or less the approximate shape of what is going to come out the other end. But that's also true in Fortran or Rust or Pascal. >[snip] >Yeah, as above, prototypes as well as various other stuff you >suggested, for completely new code destined to remain on Unix/C. >But situations are frequently more complicated than just "new code". >Some of your (and others') remarks sound (to me) like you're coding >in a blissful vacuum. But the world I see is full of pre-existing >complications that frequently can't be precisely predicted, and >that often can affect your choice of coding style. Better to be >conservative and safe than flamboyant and sorry. (Not saying >your suggestions are flamboyant, but the sentence sounded >cuter that way:) Prototypes were standardized nearly 40 years ago, and were in a number of implementations prior to that (the 1987 revision to the "Guide to VAX C" lists them, for instance). Both Stratus's C compiler for VOS and HPE's for NonStop support the 1989 ANSI standard; I'd imagine they did so relatively quickly after the standard was ratified. `typedef` was present in the 7th Edition Unix C compiler for so-called "typesetter C" and, outside of a few very constrained compilers hosted on 8-bit environments, has probably been in every compiler since. Of course, `//` as a comment indicator predates C (it came from BCPL: `/* ... */` actually comes from PL/I). It's rare indeed to come across a system that doesn't support at least the 1989 C standard; Multics is an example: despite the last physical DPS/8m not shutting down until 2000, its compiler was a PCC port and was strictly pre-ANSI. I get that one can be constrained by the demands of backwards compatibility with existing environments, but in this specific case, for many of the things listed, "new code" is code that is starting to feel those aching knees and back pain rolling out of bed in the morning. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-29 21:19 +0000 |
| Message-ID | <10stsks$7fn3$1@dont-email.me> |
| In reply to | #398085 |
On Wed, 29 Apr 2026 06:22:39 -0000 (UTC), John Forkosh wrote: > Note that VMS was only one example. I also had contracts requiring C > development on Stratus computers under VOS, on Tandem "nonstop" > (n.b., true, the hardware pretty much never went down, but the > nonstop OS crashed regularly:), and various other lost-to-posterity > platforms. So I simply tried to develop coding habits/style that > would work across them all, and that would remain working for the > then-forseeable future. I would not let such a thing permanently affect my coding style. I would develop a separate “extra-cost” mode for writing code for such old systems, while maintaining my preferred “regular-cost” mode for more modern systems.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-29 16:46 -0700 |
| Message-ID | <86340d1g9j.fsf@linuxsc.com> |
| In reply to | #398085 |
John Forkosh <forkosh@panix.com> writes: [...] > You can pretty much look at C code and see more-or-less what an > assembler will do with it. [...] In all probability reject it for being a malformed input.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-28 14:25 +0200 |
| Message-ID | <10sq8vv$3knhv$8@dont-email.me> |
| In reply to | #398051 |
On 2026-04-28 09:02, John Forkosh wrote:
>
> No particular reason for "K&R2" versus "ANSI C". But overall reason
> for "older C standard" was (but pretty much no longer is) contract
> work on a variety of slightly-weird systems, particularly, for
> example, VMS, which can require, e.g., a variety of very non-standard
> stuff like
> #include <descrip.h>
> ...
> char tabbuf[64]; /* usual declarations */
> char *tabnam;
> struct dsc$descriptor_s /* required descriptor declarations */
> tab_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, &tabbuf[0] },
> log_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, lognam };
> And I found it easier to stick to an older C standard whenever
> possible, just to ensure compliance among as many OSs as possible,
> across as many different platforms as possible.
I don't quite understand; you say you needed such older standards
to support various systems, and you use above code for that. Were
(or are) these $-expressions standard back these days (or still)?
(Looks like some VMS-specific stuff; I seem to recall there were
$-expressions on that OS in various places. On file system? I've
never programmed "C" on VMS as far as I recall.)
> [...]
>
> "Passively", so to speak, chosen, at least by me. So the original post
> refers to a lot of old code, and it would be a big pain in the fingers
> to go back and fix all the int typer(); kind of stuff just to get it
> to compile. -std=gnu17 is a much kinder and gentler (to my fingers)
> solution. And having done that, note that everything now compiles and
> runs correctly with no further change whatsoever.
Tasks accomplished.
Janis
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-28 13:13 +0000 |
| Message-ID | <10sqbpn$i4b$1@reader1.panix.com> |
| In reply to | #398054 |
In article <10sq8vv$3knhv$8@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>On 2026-04-28 09:02, John Forkosh wrote:
>>
>> No particular reason for "K&R2" versus "ANSI C". But overall reason
>> for "older C standard" was (but pretty much no longer is) contract
>> work on a variety of slightly-weird systems, particularly, for
>> example, VMS, which can require, e.g., a variety of very non-standard
>> stuff like
>> #include <descrip.h>
>> ...
>> char tabbuf[64]; /* usual declarations */
>> char *tabnam;
>> struct dsc$descriptor_s /* required descriptor declarations */
>> tab_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, &tabbuf[0] },
>> log_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, lognam };
>> And I found it easier to stick to an older C standard whenever
>> possible, just to ensure compliance among as many OSs as possible,
>> across as many different platforms as possible.
>
>I don't quite understand; you say you needed such older standards
>to support various systems, and you use above code for that. Were
>(or are) these $-expressions standard back these days (or still)?
>
>(Looks like some VMS-specific stuff; I seem to recall there were
>$-expressions on that OS in various places. On file system? I've
>never programmed "C" on VMS as far as I recall.)
DEC liked to use `$` as a token in symbols in various langauges;
it's been an extension to standard C for many years. It was
conventional to use `$` to separate e.g., a short library
identifer and a symbol name in that library. `lib$put_output`
for example; this library routine takes a pointer to a
descriptor for data that is printed to, "the current controlling
output device."
Descriptors (like those above) are VMS-specific, tagged
structures used for bundling pointers up with metadata (types, a
"class", length). Lots of variable-sized objects, like strings,
use them for for describing data passed to libraries, into the
operating system via "system service" calls (system calls), and
similar things.
All practical systems use some kind of "convention" for passing
parameters to functions written in a langauge. The actual
mechanism varies; for example, arguments might be pushed onto
the (hardware) stack in some order, and accessed relative to a
stack or call frame pointer, while on others the first $n$ of
them might be put into general purpose registers, and the rest
spill onto the stack. On some systems, these these conventions
vary from language-to-language (or even compiler-to-compiler).
VMS is an interesting example of a system that started life with
what we'd now call an ABI: there was a calling standard that
pretty much all languages conformed to, that specified how
functions (nee procedures, subroutines, and so on; whatever the
langauge wanted to call them) were invoked, the layout of data
in memory for elements of various types (e.g., 32 and 16 bit
words, pointers, floating point numbers, bytes, etc), and so on.
This made it trivial to call code written in different
languages; pretty much anyone using the DEC tools could invoke
code written in any language they provided a compiler for: C
could call FORTRAN, COBOL, Pascal, Macro-32, etc. It was common
for systems to be written in a variety of languages.
VMS people used to mock the Unix people over this. On Unix
systems, which grew ABIs rather later in the game, it was not
nearly so easy.
Descriptors were (and I suppose still are) a practical way to
abstract the semantics of different languages to make this
possible. VMS strings, for example, are counted; the descriptor
contains the length; many system services are defined to take
some class of descriptors for a variety of data.
None of this is specific to C per se, but it does highlight the
way that extensions can be used to enhance functionality; in
this case, the use of `$` in an identifier.
Personally, I wish the standard would officially allow more
characters in identifiers, instead of making that an extension.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-28 15:48 +0200 |
| Message-ID | <10sqdqs$33m2d$1@dont-email.me> |
| In reply to | #398057 |
On 28/04/2026 15:13, Dan Cross wrote: > this case, the use of `$` in an identifier. > > Personally, I wish the standard would officially allow more > characters in identifiers, instead of making that an extension. > Since C23, implementations can allow $ in identifiers as an extra character - but they are not required to support it. Most have supported it anyway, AFAIK, except perhaps for targets where it messes with the assembler syntax, but now it is implementation-defined support rather than an extension. And of course there have been unicode identifiers since C99, though not all compilers handle them well (or at all). But it has always struck me as a bit inconsistent in the choice of characters that are allowed. Non-ASCII letters are fair enough. But you can also use some symbols, like x² or a·b, while you are not able to use easily typed characters like § ¦ ¤ or @. I am not sure how much all this aids code clarity, but they might find use in things like macro parameters - if your macro parameters have the old Greenlandic letter ĩ in them, they are unlikely to have accidental conflicts with the rest of the code!
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-28 15:05 +0100 |
| Message-ID | <10sqes0$36fgh$1@dont-email.me> |
| In reply to | #398060 |
On 28/04/2026 14:48, David Brown wrote: > On 28/04/2026 15:13, Dan Cross wrote: > >> this case, the use of `$` in an identifier. >> >> Personally, I wish the standard would officially allow more >> characters in identifiers, instead of making that an extension. >> > > Since C23, implementations can allow $ in identifiers as an extra > character - but they are not required to support it. Most have > supported it anyway, AFAIK, except perhaps for targets where it messes > with the assembler syntax, but now it is implementation-defined support > rather than an extension. > > And of course there have been unicode identifiers since C99, though not > all compilers handle them well (or at all). Wait, so Unicode characters have been officially allowed in identifiers from C99, but '$', a long-standing ASCII character, has only been allowed since C23? Most compilers do support '$', but the exceptions included the ones I used! So lccwin32 supports it within an identifier, but not as the first character. Tiny C by default doesn't support it all, unless this option is used: -fdollars-in-identifiers I think adding that option was more effort than always allowing '$'. Actually, the code needed for that is likely shorter than the option itself - in my compiler, it needs exactly 8 characters, and could have been done in 4. (I use '$' extensively within generated code, especially for qualified names which support namespaces.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-28 16:37 +0200 |
| Message-ID | <10sqgnj$33m2d$3@dont-email.me> |
| In reply to | #398062 |
On 28/04/2026 16:05, Bart wrote: > On 28/04/2026 14:48, David Brown wrote: >> On 28/04/2026 15:13, Dan Cross wrote: >> >>> this case, the use of `$` in an identifier. >>> >>> Personally, I wish the standard would officially allow more >>> characters in identifiers, instead of making that an extension. >>> >> >> Since C23, implementations can allow $ in identifiers as an extra >> character - but they are not required to support it. Most have >> supported it anyway, AFAIK, except perhaps for targets where it messes >> with the assembler syntax, but now it is implementation-defined >> support rather than an extension. >> >> And of course there have been unicode identifiers since C99, though >> not all compilers handle them well (or at all). > > Wait, so Unicode characters have been officially allowed in identifiers > from C99, but '$', a long-standing ASCII character, has only been > allowed since C23? Yes. Extended identifiers (with Unicode characters) and allowing $ in identifiers are orthogonal concepts. The order of standardisation and of common implementation has been different - $ has been supported by many (most?) compilers for decades, and only standardised recently, while Unicode characters have been standardised for decades but support in compilers is varied and often relatively recent. I think it would have made sense to standardise $ long ago. > > Most compilers do support '$', but the exceptions included the ones I used! > > So lccwin32 supports it within an identifier, but not as the first > character. I think in C23, that would count as not supporting $ as a nondigit character in identifiers (such missing support is fine - it's implementation defined), and then having an extension to allow $ in identifiers after the first letter. Not that I think it makes any difference to llcwin32. > > Tiny C by default doesn't support it all, unless this option is used: > > -fdollars-in-identifiers > > I think adding that option was more effort than always allowing '$'. > > Actually, the code needed for that is likely shorter than the option > itself - in my compiler, it needs exactly 8 characters, and could have > been done in 4. > > (I use '$' extensively within generated code, especially for qualified > names which support namespaces.) > And now you can be happy that it is standardised, though implementation-defined.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-28 14:02 -0700 |
| Message-ID | <10sr79o$3eovh$1@kst.eternal-september.org> |
| In reply to | #398065 |
David Brown <david.brown@hesbynett.no> writes:
> On 28/04/2026 16:05, Bart wrote:
[...]
>> Wait, so Unicode characters have been officially allowed in
>> identifiers from C99, but '$', a long-standing ASCII character, has
>> only been allowed since C23?
>
> Yes. Extended identifiers (with Unicode characters) and allowing $ in
> identifiers are orthogonal concepts. The order of standardisation and
> of common implementation has been different - $ has been supported by
> many (most?) compilers for decades, and only standardised recently,
> while Unicode characters have been standardised for decades but
> support in compilers is varied and often relatively recent.
>
> I think it would have made sense to standardise $ long ago.
C90 only allows the 52 uppercase and lowercase letters, digits, and
underscore in identifiers. Other characters (like '$') could be
supported as extensions, as permitted in section 4: "A conforming
implementation may have extensions (including additional library
functions), provided they do not alter the behavior of any strictly
conforming program".
C99 updated the syntax for "identifier" to allow
universal-character-names or "other implementation-defined
characters" to be treated as "identifier-nondigit"s (i.e., they
can be the first character of an identifier). C11 and C17 made no
relevant changes as far as I can tell.
I'm not sure I see the point of UCNs other than in machine-generated
code. Something like h\u00e9llo (where character 0xe9 is 'é') certainly
isn't meant to be human-friendly.
An implementation may allow multibyte characters that are not part
of the basic source character set to appear in identifiers; which
characters and their correspondence to universal character names is
implementation-defined.
This, I think, is the wording in C99 through C17 that allows
implementations to permit '$' in identifiers. It's indepedent of the
requirement to support UCNs. And as far as I can tell, h\u00e9llo
and héllo may or may not be treated as the same identifier.
C23 changed the description of "identifier" again. UCNs are still
required, but it also mandates support for XID_Start characters at the
beginning of an identifier and XID_Continue characters anywhere. The
syntax restricts UCNs to those that correspond to XID_Start and
XID_Continue characters.
An XID_Start character is an implementation-defined character
whose corresponding code point in ISO/IEC 10646 has the XID_Start
property. An XID_Continue character is an implementation- defined
character whose corresponding code point in ISO/IEC 10646 has
the XID_Continue property. An identifier is a sequence of one
identifier start character followed by 0 or more identifier
continue characters, which designates one or more entities
as described in 6.2.1. It is implementation-defined if a $
(U+0024, DOLLAR SIGN) may be used as a nondigit character.
I'm not quite sure what "an implementation-defined character" means
here. Certain Unicode code points have the XID_Start property.
Does this mean that an implementation can choose a subset of
those code points to allow in identifiers? I'd need a much deeper
understanding of ISO/IEC 10646 (Unicode) to know how this all works.
As far as I can tell, in all editions of the C standard from C90
to C23, it is implementation-defined whether foo$bar is a valid
identifier. In C90, support for '$' in identifiers is an extension.
In C99 through C17, it's permitted by "other implementation-defined
characters" in the grammar. In C23, it's implementation-defined
whether '$' in particular may be used as a non-digit character.
[...]
>> (I use '$' extensively within generated code, especially for
>> qualified names which support namespaces.)
>
> And now you can be happy that it is standardised, though
> implementation-defined.
I don't think it makes much difference. In all editions of
the C standard, compilers may or may not choose to permit '$' in
identifiers. All that's changed is the rules by which they can make
that choice (and some changes in the rules for other characters).
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-29 09:29 +0200 |
| Message-ID | <10ssc0k$3mum2$2@dont-email.me> |
| In reply to | #398079 |
On 28/04/2026 23:02, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 28/04/2026 16:05, Bart wrote: > [...] >>> Wait, so Unicode characters have been officially allowed in >>> identifiers from C99, but '$', a long-standing ASCII character, has >>> only been allowed since C23? >> >> Yes. Extended identifiers (with Unicode characters) and allowing $ in >> identifiers are orthogonal concepts. The order of standardisation and >> of common implementation has been different - $ has been supported by >> many (most?) compilers for decades, and only standardised recently, >> while Unicode characters have been standardised for decades but >> support in compilers is varied and often relatively recent. >> >> I think it would have made sense to standardise $ long ago. > > C90 only allows the 52 uppercase and lowercase letters, digits, and > underscore in identifiers. Other characters (like '$') could be > supported as extensions, as permitted in section 4: "A conforming > implementation may have extensions (including additional library > functions), provided they do not alter the behavior of any strictly > conforming program". > > C99 updated the syntax for "identifier" to allow > universal-character-names or "other implementation-defined > characters" to be treated as "identifier-nondigit"s (i.e., they > can be the first character of an identifier). C11 and C17 made no > relevant changes as far as I can tell. > > I'm not sure I see the point of UCNs other than in machine-generated > code. Something like h\u00e9llo (where character 0xe9 is 'é') certainly > isn't meant to be human-friendly. > > An implementation may allow multibyte characters that are not part > of the basic source character set to appear in identifiers; which > characters and their correspondence to universal character names is > implementation-defined. > > This, I think, is the wording in C99 through C17 that allows > implementations to permit '$' in identifiers. It's indepedent of the > requirement to support UCNs. And as far as I can tell, h\u00e9llo > and héllo may or may not be treated as the same identifier. I think (and I admit I am on very shaky grounds here) that they can be different, since the UCN version gives a specific character code while the letter é can have different encodings (like in UTF-8 or Latin-9). I think such details would have to be implementation dependent. As for the point of UCN's, which are - as you say - not very human friendly, I can see several uses. Machine-generated code is one thing you mentioned. They could also be generated by pre-processors - before gcc properly supported Unicode identifiers, it was possible to write your C with identifiers like "héllo" and pass it through a filter to generate \u characters that the compiler accepted. And they might be useful for referring to external symbols from other tools. But as you say, they are hardly human friendly. > > C23 changed the description of "identifier" again. UCNs are still > required, but it also mandates support for XID_Start characters at the > beginning of an identifier and XID_Continue characters anywhere. The > syntax restricts UCNs to those that correspond to XID_Start and > XID_Continue characters. > > An XID_Start character is an implementation-defined character > whose corresponding code point in ISO/IEC 10646 has the XID_Start > property. An XID_Continue character is an implementation- defined > character whose corresponding code point in ISO/IEC 10646 has > the XID_Continue property. An identifier is a sequence of one > identifier start character followed by 0 or more identifier > continue characters, which designates one or more entities > as described in 6.2.1. It is implementation-defined if a $ > (U+0024, DOLLAR SIGN) may be used as a nondigit character. > > I'm not quite sure what "an implementation-defined character" means > here. Certain Unicode code points have the XID_Start property. > Does this mean that an implementation can choose a subset of > those code points to allow in identifiers? I'd need a much deeper > understanding of ISO/IEC 10646 (Unicode) to know how this all works. > > As far as I can tell, in all editions of the C standard from C90 > to C23, it is implementation-defined whether foo$bar is a valid > identifier. In C90, support for '$' in identifiers is an extension. > In C99 through C17, it's permitted by "other implementation-defined > characters" in the grammar. In C23, it's implementation-defined > whether '$' in particular may be used as a non-digit character. > > [...] > >>> (I use '$' extensively within generated code, especially for >>> qualified names which support namespaces.) >> >> And now you can be happy that it is standardised, though >> implementation-defined. > > I don't think it makes much difference. In all editions of > the C standard, compilers may or may not choose to permit '$' in > identifiers. All that's changed is the rules by which they can make > that choice (and some changes in the rules for other characters). > Thanks for the details and corrections here. I do agree that it makes no practical difference, but I guess someone feels the exact wording details matter, or the standards committee would not have bothered changing the text.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-29 02:49 -0700 |
| Message-ID | <10ssk6g$3pvt1$1@kst.eternal-september.org> |
| In reply to | #398087 |
David Brown <david.brown@hesbynett.no> writes:
> On 28/04/2026 23:02, Keith Thompson wrote:
[...]
>> I'm not sure I see the point of UCNs other than in machine-generated
>> code. Something like h\u00e9llo (where character 0xe9 is 'é') certainly
>> isn't meant to be human-friendly.
>>
>> An implementation may allow multibyte characters that are not
>> part of the basic source character set to appear in identifiers;
>> which characters and their correspondence to universal character
>> names is implementation-defined.
>>
>> This, I think, is the wording in C99 through C17 that allows
>> implementations to permit '$' in identifiers. It's indepedent of the
>> requirement to support UCNs. And as far as I can tell, h\u00e9llo
>> and héllo may or may not be treated as the same identifier.
>
> I think (and I admit I am on very shaky grounds here) that they can be
> different, since the UCN version gives a specific character code while
> the letter é can have different encodings (like in UTF-8 or Latin-9).
> I think such details would have to be implementation dependent.
>
> As for the point of UCN's, which are - as you say - not very human
> friendly, I can see several uses. Machine-generated code is one thing
> you mentioned. They could also be generated by pre-processors -
> before gcc properly supported Unicode identifiers, it was possible to
> write your C with identifiers like "héllo" and pass it through a
> filter to generate \u characters that the compiler accepted. And they
> might be useful for referring to external symbols from other tools.
> But as you say, they are hardly human friendly.
Now that I think about it, I don't think I've ever seen UCNs used in
C code, apart from a handful of tiny test programs I've written while
trying to understand UCNs. I've never paid much attention to them.
My experience is of course limited.
Does anyone actually use UCNs? If so, what for?
The C99 Rationale has this to say:
6.4.3 Universal character names
A new feature of C99: Note that, to allow for Universal Character
Names (UCNs), a new production has been added to the grammar
that encompasses all forms of identifier elements (basic letter,
UCN, or extended character). There was some discussion about
the need to require an implementation to handle all digits,
Arabic or otherwise, in a similar way. The general feeling
was that detecting the “extended digits” might be an
undesirable burden for many implementations and should be
avoided if possible.
Note that a strictly conforming program may use in identifiers
only the extended characters listed in Annex I, and may not
begin an identifier with an extended digit.
(It's Annex D, not Annex I. That annex changed considerably in C23.)
Is it possible that UCNs are the new trigraphs (a feature added in
ANSI C, perhaps for political reasons, that were so ugly they were
finally removed)?
--
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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web