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

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

Cake - C23 to C99 transpiler

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

Contents

  Cake -  C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-08-18 18:44 -0700
    Re: Cake - C23 to C99 transpiler Blue-Maned_Hawk <bluemanedhawk@example.invalid> - 2022-09-06 02:48 -0400
      Re: Cake - C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-09-06 10:08 -0700
        Re: Cake - C23 to C99 transpiler Vir Campestris <vir.campestris@invalid.invalid> - 2022-09-07 12:27 +0100
          Re: Cake - C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-09-07 05:45 -0700
            Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-07 15:35 +0100
              Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 16:38 +0100
                Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-07 17:04 +0100
                  Re: Cake - C23 to C99 transpiler Anton Shepelev <anton.txt@g{oogle}mail.com> - 2022-09-07 19:14 +0300
                  Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 17:31 +0100
                    Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-07 17:40 +0100
                      Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 17:49 +0100
                        Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-07 19:27 +0100
                          Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 20:02 +0100
                            Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-07 21:03 +0100
                              Re: Cake - C23 to C99 transpiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-07 13:52 -0700
                                Re: Cake - C23 to C99 transpiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 07:14 -0700
                                  Re: Cake - C23 to C99 transpiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-14 10:59 -0700
                                    Re: Cake - C23 to C99 transpiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-15 23:46 -0700
                      Re: Cake - C23 to C99 transpiler David Brown <david.brown@hesbynett.no> - 2022-09-07 20:17 +0200
                        Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 19:58 +0100
                          Re: Cake - C23 to C99 transpiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-07 13:26 -0700
                            Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 23:42 +0100
                            Re: Cake - C23 to C99 transpiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 06:45 -0700
                          Re: Cake - C23 to C99 transpiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 06:40 -0700
                  Re: Cake - C23 to C99 transpiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-07 10:28 -0700
                  Re: Cake - C23 to C99 transpiler David Brown <david.brown@hesbynett.no> - 2022-09-07 20:05 +0200
              Re: Cake - C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-09-07 15:28 -0700
                Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-08 00:51 +0100
                  Re: Cake - C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-09-08 05:20 -0700
                    Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-08 16:41 +0100
                      Re: Cake - C23 to C99 transpiler scott@slp53.sl.home (Scott Lurndal) - 2022-09-08 16:43 +0000
                        Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-08 19:23 +0100
                      Re: Cake - C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-09-08 09:59 -0700

Page 1 of 2  [1] 2  Next page →

#167060 — Cake - C23 to C99 transpiler

With C23 approaching and having a lot of small changes I decided
to focus my C front end to compile C11/C23 to C99.
 
Here is the online version
http://thradams.com/web3/playground.html

The project is here.
https://github.com/thradams/cake

It is not complete but it can:
* Convert C11 _Generics
* C11 u8 literals
* C23 digit separators
* c23 binary literals
* c23 nullptr bool static assert true false..
* c23 {} empty initializer
* c23 typeof
* c23 embed
* c23 warning
*  elifdef elifndef

missing
*  c11 atomic
* enum with types..
* BitInt Decimal and more..
* Decimal
* attributes are very incomplete
* vaopt

extensions

* defer
* lambdas without capture
* try catch blocks
* c++ 17 if with initializer
* repeat for (;;)
* typeid

The idea is not create a new language but implement and
try ideas that fits into C. 

[toc] | [next] | [standalone]

#167508 — Re: Cake - C23 to C99 transpiler

Why?
​
-- 
/blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
I think my Usenet provider stores their passwords in plain text.  If i'm 
acting suspiciously, chances are that that backfired on them.

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

#167517 — Re: Cake - C23 to C99 transpiler

On Tuesday, September 6, 2022 at 3:48:40 AM UTC-3, Blue-Maned_Hawk wrote:
> Why? 

The initial idea was to experiment new ideas for C compiling to standard C.

Transpiring C23 to C99 is a similar task the difference is that one day C compiler
will have the feature. 

Some people may have this need to compile from C23 to C99 because they
have C23 in many platforms but there is one platform missing C23
but C99 is available. (But this was not my personal motivation)

The end of road map is to have a normal C compiler (like tcc) with some extensions.
I need to choose a backend now.

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

#167520 — Re: Cake - C23 to C99 transpiler

On 06/09/2022 18:08, Thiago Adams wrote:
> I need to choose a backend now.

If your intent is to produce C99 shouldn't you be testing against every 
compiler you can get your hands on, rather than picking one?

Andy

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

#167521 — Re: Cake - C23 to C99 transpiler

On Wednesday, September 7, 2022 at 8:27:30 AM UTC-3, Vir Campestris wrote:
> On 06/09/2022 18:08, Thiago Adams wrote: 
> > I need to choose a backend now.
> If your intent is to produce C99 shouldn't you be testing against every 
> compiler you can get your hands on, rather than picking one? 

Here "I need to choose a backend now." I was talking about
a x86 or intermediate backend or create a interpreter.

But choosing a compiler target for C.. yes it also is possible.
Some features may exist (like thread storage) and be different
depending on the compiler . So choosing the target compiler the
generator could generate code for that specific feature.

Also some auxiliary header could be added. For instance static_assert is
not part of c99 and I am removing it. But it could be a macro in this
auxiliary header.





 

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

#167522 — Re: Cake - C23 to C99 transpiler

On 07/09/2022 13:45, Thiago Adams wrote:
> On Wednesday, September 7, 2022 at 8:27:30 AM UTC-3, Vir Campestris wrote:
>> On 06/09/2022 18:08, Thiago Adams wrote:
>>> I need to choose a backend now.
>> If your intent is to produce C99 shouldn't you be testing against every
>> compiler you can get your hands on, rather than picking one?
> 
> Here "I need to choose a backend now." I was talking about
> a x86 or intermediate backend or create a interpreter.
> 
> But choosing a compiler target for C.. yes it also is possible.
> Some features may exist (like thread storage) and be different
> depending on the compiler . So choosing the target compiler the
> generator could generate code for that specific feature.

The Seed7 language, if you were to build it from C sources, comes with 
nearly 20 different makefiles for different compilers and platforms.

There's also a configure program which creates and runs some 100 
different test programs to collate information about the C 
implementation, resulting in a configuration header file describing the 
environment.

Since Seed7 also uses C as a target language, I can't remember if that 
config file was for the compiler, or compiling the generated C 
intermediates, or both.

Use C as a target is not that simple!

When I used to target C, I produced a single C source for the entire 
program, but there were three versions, since it didn't have conditional 
elements:

    * For Windows
    * For Linux
    * For a Neutral OS (runs on either but with limitations)

I think also the code assumed a 64-bit implementation; a 32-bit target, 
if I was to still bother with it, would need separate versions.

I used to try and support half a dozen C compilers, which was hard as 
they all had different limitations. Now I support only tcc and gcc.

No special options are required (other than ones like -O2 and -o for 
gcc), and no special extensions (a few things expected to be in C99 like 
anonymous structs and unions).

The main limitation of tcc (a significant one for me) is that it doesn't 
support '$' in identifiers; most C compilers do. Which means taking 
account of that in code generators.

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

#167523 — Re: Cake - C23 to C99 transpiler

Bart <bc@freeuk.com> writes:

> The main limitation of tcc (a significant one for me) is that it
> doesn't support '$' in identifiers; most C compilers do. Which means
> taking account of that in code generators.

-fdollars-in-identifiers works for me.

-- 
Ben.

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

#167524 — Re: Cake - C23 to C99 transpiler

On 07/09/2022 16:38, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> The main limitation of tcc (a significant one for me) is that it
>> doesn't support '$' in identifiers; most C compilers do. Which means
>> taking account of that in code generators.
> 
> -fdollars-in-identifiers works for me.
> 

What a strange thing to have as an option (and an odd thing to have as 
an essential requirement in the build instructions for your app).

Just supporting '$' anyway would be a one-line change in the tcc source 
code (although that only fixed my copy of it when I tried it).

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

#167525 — Re: Cake - C23 to C99 transpiler

Bart:

> Just supporting '$' anyway would be a one-line change in
> the tcc source code (although that only fixed my copy of
> it when I tried it).

The currect solution allows to run the compiler with the
more conservative settings, enforcing a more standard and
portable code.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#167526 — Re: Cake - C23 to C99 transpiler

Bart <bc@freeuk.com> writes:

> On 07/09/2022 16:38, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> 
>>> The main limitation of tcc (a significant one for me) is that it
>>> doesn't support '$' in identifiers; most C compilers do. Which means
>>> taking account of that in code generators.
>> -fdollars-in-identifiers works for me.
>
> What a strange thing to have as an option (and an odd thing to have as
> an essential requirement in the build instructions for your app).

Why?  Because you want it as the default, tcc should make me write
-fno-dollars-in-identifiers get this non-portable feature diagnosed?

> Just supporting '$' anyway would be a one-line change in the tcc
> source code (although that only fixed my copy of it when I tried it).

Or a zero line change if you use that option.

-- 
Ben.

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

#167527 — Re: Cake - C23 to C99 transpiler

On 07/09/2022 17:31, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 07/09/2022 16:38, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> The main limitation of tcc (a significant one for me) is that it
>>>> doesn't support '$' in identifiers; most C compilers do. Which means
>>>> taking account of that in code generators.
>>> -fdollars-in-identifiers works for me.
>>
>> What a strange thing to have as an option (and an odd thing to have as
>> an essential requirement in the build instructions for your app).
> 
> Why?  Because you want it as the default, tcc should make me write
> -fno-dollars-in-identifiers get this non-portable feature diagnosed?

Because '$' was supported on nearly every other compiler I tried, run 
with default options.

(The exception was lccwin32 which only allowed it either as a starter or 
inside the identifier; I don't recall.)

Also, generally there is no downside to allowing it. '$' doesn't have 
any other use in C source code, does it?

>> Just supporting '$' anyway would be a one-line change in the tcc
>> source code (although that only fixed my copy of it when I tried it).
> 
> Or a zero line change if you use that option.

But all build instructions for every user for every project that depends 
on '$' would forever more need to include '-fdollars-in-identifiers'. 
IMV that was the wrong choice.

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

#167528 — Re: Cake - C23 to C99 transpiler

Bart <bc@freeuk.com> writes:

> On 07/09/2022 17:31, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:

>>> Just supporting '$' anyway would be a one-line change in the tcc
>>> source code (although that only fixed my copy of it when I tried it).
>>
>> Or a zero line change if you use that option.
>
> But all build instructions for every user for every project that
> depends on '$' would forever more need to include
> '-fdollars-in-identifiers'.  IMV that was the wrong choice.

But you don't think using IDs with non-standard characters might also
have been a poor choice?

-- 
Ben.

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

#167533 — Re: Cake - C23 to C99 transpiler

On 07/09/2022 17:49, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 07/09/2022 17:31, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
> 
>>>> Just supporting '$' anyway would be a one-line change in the tcc
>>>> source code (although that only fixed my copy of it when I tried it).
>>>
>>> Or a zero line change if you use that option.
>>
>> But all build instructions for every user for every project that
>> depends on '$' would forever more need to include
>> '-fdollars-in-identifiers'.  IMV that was the wrong choice.
> 
> But you don't think using IDs with non-standard characters might also
> have been a poor choice?
> 

The dollar symbols come up when transpiling to C code from syntax that 
uses $, for example, to represent fully names since C lacks namespaces, 
or for special identifiers.

There, $ was considered a better and more visible and obvious indicator 
of a special identifier than underscore.

Underscores suffer from poor visibility; consecutive underscore can 
appear to run together depending on font; and they are also popular as 
separators in user-identifiers, creating a bit more confusion.

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

#167536 — Re: Cake - C23 to C99 transpiler

Bart <bc@freeuk.com> writes:

> On 07/09/2022 17:49, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> 
>>> On 07/09/2022 17:31, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>> 
>>>>> Just supporting '$' anyway would be a one-line change in the tcc
>>>>> source code (although that only fixed my copy of it when I tried it).
>>>>
>>>> Or a zero line change if you use that option.
>>>
>>> But all build instructions for every user for every project that
>>> depends on '$' would forever more need to include
>>> '-fdollars-in-identifiers'.  IMV that was the wrong choice.
>> But you don't think using IDs with non-standard characters might also
>> have been a poor choice?
>
> The dollar symbols come up when transpiling to C code from syntax that
> uses $, for example, to represent fully names since C lacks
> namespaces, or for special identifiers.
>
> There, $ was considered a better and more visible and obvious
> indicator of a special identifier than underscore.
>
> Underscores suffer from poor visibility; consecutive underscore can
> appear to run together depending on font; and they are also popular as
> separators in user-identifiers, creating a bit more confusion.

So no, you consider it a good choose.  So good, in fact, that you are
happy to exclude tcc from being used as the C compiler.  But adding a
line to the documentation to say "add -fdollars-in-identifiers when
using tcc" is too much.

-- 
Ben.

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

#167539 — Re: Cake - C23 to C99 transpiler

On 07/09/2022 20:02, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 07/09/2022 17:49, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 07/09/2022 17:31, Ben Bacarisse wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>>> Just supporting '$' anyway would be a one-line change in the tcc
>>>>>> source code (although that only fixed my copy of it when I tried it).
>>>>>
>>>>> Or a zero line change if you use that option.
>>>>
>>>> But all build instructions for every user for every project that
>>>> depends on '$' would forever more need to include
>>>> '-fdollars-in-identifiers'.  IMV that was the wrong choice.
>>> But you don't think using IDs with non-standard characters might also
>>> have been a poor choice?
>>
>> The dollar symbols come up when transpiling to C code from syntax that
>> uses $, for example, to represent fully names since C lacks
>> namespaces, or for special identifiers.
>>
>> There, $ was considered a better and more visible and obvious
>> indicator of a special identifier than underscore.
>>
>> Underscores suffer from poor visibility; consecutive underscore can
>> appear to run together depending on font; and they are also popular as
>> separators in user-identifiers, creating a bit more confusion.
> 
> So no, you consider it a good choose.  So good, in fact, that you are
> happy to exclude tcc from being used as the C compiler.  But adding a
> line to the documentation to say "add -fdollars-in-identifiers when
> using tcc" is too much.
> 

I supported Tcc but I needed to translate names using $ into something 
that is acceptable. That sort of worked, but gave less readable, longer, 
more unsatisfactory output.

The advantage is that it doesn't need to be mentioned in build docs:

  gcc linux:    gcc prog.c -oprog -lm -ldl
  tcc linux:    tcc prog.c -oprog -lm -ldl -fdollars-in-identifiers
  gcc windows:  gcc prog.c -oprog.exe
  tcc windows:  tcc prog.c -luser32 -fdollars-in-identifiers
  bcc windows:  bcc prog

It sort of sticks out doesn't it.

Also, gcc gets away with allowing $ by default; tcc generally copies gcc 
in terms of how a compiler is invoked, so this surprisingly goes against 
that.

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

#167541 — Re: Cake - C23 to C99 transpiler

Bart <bc@freeuk.com> writes:
[...]
> Also, gcc gets away with allowing $ by default; tcc generally copies
> gcc in terms of how a compiler is invoked, so this surprisingly goes
> against that.

gcc allowing $ in identifiers is a documented extension for most
targets, so it doesn't warn about them even with "-pedantic".  One could
argue that this isn't necessarily an "extension", since "other
implementation-defined characters" are explicitly permitted by C11
6.4.2.1.

Interestingly, the C23 draft doesn't have that wording.  Instead, it
allows XID_Start and XID_Continue characters, so it expands the set of
characters that *all* implementations must support, but doesn't permit
'$' (assuming '$' isn't in XID_Start or XID_Continue).

A conforming C23 implementation can still accept '$' in identifiers
as an extension, but my understanding is that it must issue a
warning.  (Of course no warning is required in non-conforming mode.)

In any case, as of C11 a conforming C compiler is not required to accept
'$' in identifiers *at all*, even with a command-line option, and may
reject any program that uses it.  You can of course choose to rely on
the behavior of specific compilers, but if you use '$' in identifiers
then your code is not 100% portable.  (REMINDER: "not 100% portable" is
not necessarily a criticism.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#167712 — Re: Cake - C23 to C99 transpiler

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

> Bart <bc@freeuk.com> writes:
> [...]
>
>> Also, gcc gets away with allowing $ by default;  tcc generally copies
>> gcc in terms of how a compiler is invoked, so this surprisingly goes
>> against that.
>
> gcc allowing $ in identifiers is a documented extension for most
> targets, so it doesn't warn about them even with "-pedantic".  One could
> argue that this isn't necessarily an "extension", since "other
> implementation-defined characters" are explicitly permitted by C11
> 6.4.2.1.
>
> Interestingly, the C23 draft doesn't have that wording.  Instead, it
> allows XID_Start and XID_Continue characters, so it expands the set of
> characters that *all* implementations must support,

I believe that conclusion is not correct.  The C23 draft n3047 says
this:

    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.

The presence of the modifying adjective "implementation-defined" in
both cases surely means, at the very least, that implementations
are allowed to subset the Unicode-specified XID_Start/XID_Continue
sets with regard to what characters are allowed in identifiers.


> but doesn't permit '$' (assuming '$' isn't in XID_Start or
> XID_Continue).

I'm not sure this statement is right either (and agreeing with the
assumption that '$' is not in XID_Start or XID_Continue).  The
Unicode reference documentation is so bad that I can't make out
with any degree of certainty whether it allows various domains to
extend the XID_Start/XID_Continue sets for the application in
question.  The presence of "implementation-defined" further muddies
the waters.  To be clear, neither am I saying that I think the
statement is wrong;  only that at present there is not enough
information to be confident of either conclusion.


> A conforming C23 implementation can still accept '$' in identifiers
> as an extension, but my understanding is that it must issue a
> warning.

If accepting '$' is only an extension, and not a consequence of
some implementation-defined behavior, then using '$' in an
identifier results in a syntax error, which requires a diagnostic.
Where is the uncertainty?


> In any case, as of C11 a conforming C compiler is not required to accept
> '$' in identifiers *at all*, even with a command-line option, and may
> reject any program that uses it.  You can of course choose to rely on
> the behavior of specific compilers, but if you use '$' in identifiers
> then your code is not 100% portable.  (REMINDER:  "not 100% portable" is
> not necessarily a criticism.)

Yes.

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

#167723 — Re: Cake - C23 to C99 transpiler

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>
>>> Also, gcc gets away with allowing $ by default;  tcc generally copies
>>> gcc in terms of how a compiler is invoked, so this surprisingly goes
>>> against that.
>>
>> gcc allowing $ in identifiers is a documented extension for most
>> targets, so it doesn't warn about them even with "-pedantic".  One could
>> argue that this isn't necessarily an "extension", since "other
>> implementation-defined characters" are explicitly permitted by C11
>> 6.4.2.1.
>>
>> Interestingly, the C23 draft doesn't have that wording.  Instead, it
>> allows XID_Start and XID_Continue characters, so it expands the set of
>> characters that *all* implementations must support,
>
> I believe that conclusion is not correct.  The C23 draft n3047 says
> this:
>
>     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.
>
> The presence of the modifying adjective "implementation-defined" in
> both cases surely means, at the very least, that implementations
> are allowed to subset the Unicode-specified XID_Start/XID_Continue
> sets with regard to what characters are allowed in identifiers.

You're right.  I managed to miss the phrase "implementation-defined".

So ISO/IEC 10646 defines which characters have the "XID_Start" property,
but an "XID_Start" character is a member of a C implementation-defined
subset of those characters.  The terminology is a bit confusing, but I'm
not sure how I'd improve it.

>> but doesn't permit '$' (assuming '$' isn't in XID_Start or
>> XID_Continue).
>
> I'm not sure this statement is right either (and agreeing with the
> assumption that '$' is not in XID_Start or XID_Continue).  The
> Unicode reference documentation is so bad that I can't make out
> with any degree of certainty whether it allows various domains to
> extend the XID_Start/XID_Continue sets for the application in
> question.  The presence of "implementation-defined" further muddies
> the waters.  To be clear, neither am I saying that I think the
> statement is wrong;  only that at present there is not enough
> information to be confident of either conclusion.

If '$' can't be an XID_Start or XID_Continue character, then an attempt
to use '$' in an identifier is a syntax error.  I don't see any wiggle
room there.  The open question is whether '$' is, or can be, an
XID_Start or XID_Continue character.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#167737 — Re: Cake - C23 to C99 transpiler

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>
>>>> Also, gcc gets away with allowing $ by default;  tcc generally copies
>>>> gcc in terms of how a compiler is invoked, so this surprisingly goes
>>>> against that.
>>>
>>> gcc allowing $ in identifiers is a documented extension for most
>>> targets, so it doesn't warn about them even with "-pedantic".  One could
>>> argue that this isn't necessarily an "extension", since "other
>>> implementation-defined characters" are explicitly permitted by C11
>>> 6.4.2.1.
>>>
>>> Interestingly, the C23 draft doesn't have that wording.  Instead, it
>>> allows XID_Start and XID_Continue characters, so it expands the set of
>>> characters that *all* implementations must support,
>>
>> I believe that conclusion is not correct.  The C23 draft n3047 says
>> this:
>>
>>     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.
>>
>> The presence of the modifying adjective "implementation-defined" in
>> both cases surely means, at the very least, that implementations
>> are allowed to subset the Unicode-specified XID_Start/XID_Continue
>> sets with regard to what characters are allowed in identifiers.
>
> You're right.  I managed to miss the phrase "implementation-defined".
>
> So ISO/IEC 10646 defines which characters have the "XID_Start" property,
> but an "XID_Start" character is a member of a C implementation-defined
> subset of those characters.  The terminology is a bit confusing, but I'm
> not sure how I'd improve it.

I did not consider the question of how to improve the wording in
the ISO C standard.

>>> but doesn't permit '$' (assuming '$' isn't in XID_Start or
>>> XID_Continue).
>>
>> I'm not sure this statement is right either (and agreeing with the
>> assumption that '$' is not in XID_Start or XID_Continue).

To clarify my earlier statement, I am agreeing with (what I think
is your) assumption that '$'s ISO/IEC 10646 code point does not
have either the XID_Start property or the XID_Continue property.

>> The
>> Unicode reference documentation is so bad that I can't make out
>> with any degree of certainty whether it allows various domains to
>> extend the XID_Start/XID_Continue sets for the application in
>> question.  The presence of "implementation-defined" further muddies
>> the waters.  To be clear, neither am I saying that I think the
>> statement is wrong;  only that at present there is not enough
>> information to be confident of either conclusion.
>
> If '$' can't be an XID_Start or XID_Continue character, then an attempt
> to use '$' in an identifier is a syntax error.  I don't see any wiggle
> room there.  The open question is whether '$' is, or can be, an
> XID_Start or XID_Continue character.

Yes, I believe these statements are consistent with the most
natural reading of the current C23 draft (subject to a condition
that the consistency property can be objectively quantified).

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

#167532 — Re: Cake - C23 to C99 transpiler

On 07/09/2022 18:40, Bart wrote:
> On 07/09/2022 17:31, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 07/09/2022 16:38, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> The main limitation of tcc (a significant one for me) is that it
>>>>> doesn't support '$' in identifiers; most C compilers do. Which means
>>>>> taking account of that in code generators.
>>>> -fdollars-in-identifiers works for me.
>>>
>>> What a strange thing to have as an option (and an odd thing to have as
>>> an essential requirement in the build instructions for your app).
>>
>> Why?  Because you want it as the default, tcc should make me write
>> -fno-dollars-in-identifiers get this non-portable feature diagnosed?
> 
> Because '$' was supported on nearly every other compiler I tried, run 
> with default options.
> 
> (The exception was lccwin32 which only allowed it either as a starter or 
> inside the identifier; I don't recall.)
> 
> Also, generally there is no downside to allowing it. '$' doesn't have 
> any other use in C source code, does it?
> 

I believe (but I might have this wrong) that the use of dollar signs in 
identifiers is undefined behaviour according to the standard.  This 
means that the compiler is free to accept it, without complaint.  But it 
also means that there is no guarantee that it will be accepted by a 
compliant compiler.  And while it might have worked on the compilers 
/you/ tried, there are hundreds of others of compilers that you have 
/not/ tried.

Maximum portability is, of course, not always particularly relevant. 
When your language targets Windows and Linux, you don't care if the 
generated C code compiles on a toolchain for a small microcontroller or 
for DOS.  That's fine, and you get to choose both the features of the 
generated source code and the requirements for compilers to handle that 
code.  But other people have other needs and preferences, and pick 
different defaults from the ones /you/ happen to want.

>>> Just supporting '$' anyway would be a one-line change in the tcc
>>> source code (although that only fixed my copy of it when I tried it).
>>
>> Or a zero line change if you use that option.
> 
> But all build instructions for every user for every project that depends 
> on '$' would forever more need to include '-fdollars-in-identifiers'. 
> IMV that was the wrong choice.
> 

I've only seen one other person ever using dollars in identifiers, and 
that was someone in comp.lang.c++ where doing so was a particularly 
questionable choice, given that there are serious proposals for using 
dollar signs for a different purpose in C++ (for metaclasses and 
reflection).  It would surprise me if future C versions used the dollar 
sign for some new purpose, but it is not impossible.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web