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

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

Variable naming issue

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

Contents

  Variable naming issue maximus fl <ajones2600@gmail.com> - 2017-04-24 16:17 -0700
    Re: Variable naming issue David Kleinecke <dkleinecke@gmail.com> - 2017-04-24 16:28 -0700
    Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-25 01:09 +0100
      Re: Variable naming issue Noob <root@127.0.0.1> - 2017-04-25 09:37 +0200
        Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-25 10:40 +0100
          Re: Variable naming issue David Brown <david.brown@hesbynett.no> - 2017-04-25 13:07 +0200
            Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-25 13:24 +0100
              Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-25 13:27 +0100
              Re: Variable naming issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-25 13:59 +0100
                Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-25 14:20 +0100
                  Re: Variable naming issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-25 14:27 +0100
                    Re: Variable naming issue Keith Thompson <kst-u@mib.org> - 2017-04-25 11:52 -0700
                      Re: Variable naming issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-25 13:40 -0700
                      Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-25 22:14 +0100
                        Re: Variable naming issue David Brown <david.brown@hesbynett.no> - 2017-04-26 00:16 +0200
                          Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-26 00:13 +0100
                            Re: Variable naming issue David Brown <david.brown@hesbynett.no> - 2017-04-26 10:10 +0200
                      Re: Variable naming issue supercat@casperkitty.com - 2017-04-25 14:33 -0700
                  Re: Variable naming issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-25 06:39 -0700
                  Re: Variable naming issue Robert Wessel <robertwessel2@yahoo.com> - 2017-04-25 09:35 -0500
                Re: Variable naming issue Gareth Owen <gwowen@gmail.com> - 2017-04-25 18:39 +0100
                  Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-25 18:49 +0100
                    Re: Variable naming issue David Kleinecke <dkleinecke@gmail.com> - 2017-04-25 11:19 -0700
                      Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-25 19:31 +0100
                      Re: Variable naming issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-25 23:36 +0100
                        Re: Variable naming issue David Kleinecke <dkleinecke@gmail.com> - 2017-04-25 17:04 -0700
                          Re: Variable naming issue Robert Wessel <robertwessel2@yahoo.com> - 2017-04-26 00:32 -0500
              Re: Variable naming issue David Brown <david.brown@hesbynett.no> - 2017-04-25 16:02 +0200
              Re: Variable naming issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 05:25 -0700
                Re: Variable naming issue supercat@casperkitty.com - 2017-05-02 10:04 -0700
                  Re: Variable naming issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 03:06 -0700
            Re: Variable naming issue supercat@casperkitty.com - 2017-04-25 07:12 -0700
            Re: Variable naming issue Robert Wessel <robertwessel2@yahoo.com> - 2017-04-25 09:48 -0500
              Re: Variable naming issue Robert Wessel <robertwessel2@yahoo.com> - 2017-04-25 09:52 -0500
          Re: Variable naming issue Noob <root@127.0.0.1> - 2017-04-26 08:46 +0200
            Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-26 11:46 +0100
            Re: Variable naming issue bartc <bc@freeuk.com> - 2017-04-26 12:00 +0100
          Re: Variable naming issue gordonb.o1c18@burditt.org (Gordon Burditt) - 2017-05-07 22:25 -0500
            Re: Variable naming issue bartc <bc@freeuk.com> - 2017-05-08 10:35 +0100
              Re: Variable naming issue bartc <bc@freeuk.com> - 2017-05-08 10:53 +0100
                Re: Variable naming issue David Kleinecke <dkleinecke@gmail.com> - 2017-05-08 11:47 -0700
                  Re: Variable naming issue bartc <bc@freeuk.com> - 2017-05-08 19:59 +0100
        Re: Variable naming issue gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-25 10:43 +0000
      Re: Variable naming issue Robert Wessel <robertwessel2@yahoo.com> - 2017-04-25 09:33 -0500
    Re: Variable naming issue Keith Thompson <kst-u@mib.org> - 2017-04-24 17:26 -0700
      Re: Variable naming issue maximus fl <ajones2600@gmail.com> - 2017-04-24 18:18 -0700
    Re: Variable naming issue scott@slp53.sl.home (Scott Lurndal) - 2017-04-25 14:48 +0000

Page 1 of 3  [1] 2 3  Next page →

#108440 — Variable naming issue

This is odd. gcc and clang before compile this program with no problems, and the prpgram runs just fine. I can't find a reason why.

#include <stdio.h>

int main(void) {

   int A$ = 10;
   int $B = 25;
   int z = $B; 
   int c = 0;

   $B = A$ + $B;
   printf("A$ is: %i and $B is: %i and the sum is %i\n", A$, z, $B);
   c = A$ +$B;
   printf("c :=> %i\n", c);

   return 0;
}

This works, but the c standard says this variable name should not be valid. Other symbols I have tried cause a compiler error, but this does not. Does anyone know why? Is there something special about the $. the $ is a special character in C, but I can't located anything about it. Does any one have any thoughts on this? Thanks in advance.

[toc] | [next] | [standalone]

#108443

On Monday, April 24, 2017 at 4:17:33 PM UTC-7, maximus fl wrote:
> This is odd. gcc and clang before compile this program with no problems, and the prpgram runs just fine. I can't find a reason why.
> 
> #include <stdio.h>
> 
> int main(void) {
> 
>    int A$ = 10;
>    int $B = 25;
>    int z = $B; 
>    int c = 0;
> 
>    $B = A$ + $B;
>    printf("A$ is: %i and $B is: %i and the sum is %i\n", A$, z, $B);
>    c = A$ +$B;
>    printf("c :=> %i\n", c);
> 
>    return 0;
> }
> 
> This works, but the c standard says this variable name should not be valid. Other symbols I have tried cause a compiler error, but this does not. Does anyone know why? Is there something special about the $. the $ is a special character in C, but I can't located anything about it. Does any one have any thoughts on this? Thanks in advance.

It wouldn't pass my compiler. "int $B = 25;" would generate the
token sequence
    INT
    DOLLAR
    token named B
    EQUAL
    token whose address contains 25
    SEMICOLON
then after seeing INT the compiler expects one of
    another specifier
    an identifier
    OPEN
    STAR
anything else causes a fatal error. (I wrote that from memory,
sorry about any errors.) 

Other compilers may not go about things so directly.

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

#108446

On 25/04/2017 00:17, maximus fl wrote:
> This is odd. gcc and clang before compile this program with no problems, and the prpgram runs just fine. I can't find a reason why.
>
> #include <stdio.h>
>
> int main(void) {
>
>    int A$ = 10;
>    int $B = 25;
>    int z = $B;
>    int c = 0;
>
>    $B = A$ + $B;
>    printf("A$ is: %i and $B is: %i and the sum is %i\n", A$, z, $B);
>    c = A$ +$B;
>    printf("c :=> %i\n", c);
>
>    return 0;
> }
>
> This works, but the c standard says this variable name should not be valid. Other symbols I have tried cause a compiler error, but this does not. Does anyone know why? Is there something special about the $. the $ is a special character in C, but I can't located anything about it. Does any one have any thoughts on this? Thanks in advance.

Most compilers I've tried accept $ in names. Some don't (eg. Tiny C), so 
it is necessary to avoid them in order to have code that compiles on 
anything.

It's silly really because it can be literally a one-line change in a 
compiler to allow $.

-- 
bartc

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

#108455

On 25/04/2017 02:09, bartc wrote:

> It's silly really because it can be literally a one-line change in a 
> compiler to allow $.

Are you generating machine code or assembly?

If the latter, did you write the assembler, or do you rely
on the system's assembler?

Maybe you shouldn't assume you're smarter than everyone else.
(Or maybe I should drop you back in my KF, most of your posts
just raise my blood pressure.)

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

#108458

On 25/04/2017 08:37, Noob wrote:
> On 25/04/2017 02:09, bartc wrote:
>
>> It's silly really because it can be literally a one-line change in a
>> compiler to allow $.
>
> Are you generating machine code or assembly?

Huh? We're talking about input source not output.

We're in the 21st century not back in the 70s where names were limited 
to 6 upper case characters (because of 'radix-50' or 'sixbit' or whatever).

> If the latter, did you write the assembler, or do you rely
> on the system's assembler?

Let me reiterate, in either a compiler /or/ assembler, support for $ can 
be a one-line change from:

   ....
   case 'y':
   case 'z':

to:

   ....
   case 'y':
   case 'z':
   case '$':

In the rare case of a compiler working with an existing assembler that 
doesn't support '$' (or any other character, eg. Unicode), then it will 
need to devise some escape mechanism. Not take it out on the user by 
saying you can't do this because there might be the odd assembler out 
there that can't handle it.

> Maybe you shouldn't assume you're smarter than everyone else.
> (Or maybe I should drop you back in my KF, most of your posts
> just raise my blood pressure.)

Some posts raise /mine/ notably ones from G Owen. But those are 
sustained personal insults.


-- 
Bartc

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

#108462

On 25/04/17 11:40, bartc wrote:
> On 25/04/2017 08:37, Noob wrote:
>> On 25/04/2017 02:09, bartc wrote:
>>
>>> It's silly really because it can be literally a one-line change in a
>>> compiler to allow $.
>>
>> Are you generating machine code or assembly?
> 
> Huh? We're talking about input source not output.
> 
> We're in the 21st century not back in the 70s where names were limited
> to 6 upper case characters (because of 'radix-50' or 'sixbit' or whatever).
> 
>> If the latter, did you write the assembler, or do you rely
>> on the system's assembler?
> 
> Let me reiterate, in either a compiler /or/ assembler, support for $ can
> be a one-line change from:
> 
>   ....
>   case 'y':
>   case 'z':
> 
> to:
> 
>   ....
>   case 'y':
>   case 'z':
>   case '$':
> 
> In the rare case of a compiler working with an existing assembler that
> doesn't support '$' (or any other character, eg. Unicode), 

What is it that you think is rare?  That compilers work with existing
assemblers?  Most compilers generate assembly outputs, and most make use
of existing assemblers.

Or do you think that it is rare for an assembler to use a dollar sign in
some special way that is incompatible (or at least inconvenient) with
using dollars in identifiers?

I know of assemblers that use $ to indicate local variables, assemblers
that use it for hex literals (rather than C's 0x), assemblers that use
it for register names, assemblers that use it for "current position" -
and assemblers that simply reject it as a letter.

> then it will
> need to devise some escape mechanism. Not take it out on the user by
> saying you can't do this because there might be the odd assembler out
> there that can't handle it.

There are /many/ assemblers out there.  Your experience is with a couple
of x86 tools and maybe a brief look at something for ARM - your
extrapolations of your narrow (albeit in-depth) experiences as though
they were general rules, makes you look silly.

Yes, an escape mechanism of some sort /could/ be used - but there are no
forms of reserved identifiers that could sensibly be used, so there is
nothing to stop conflict with other valid identifiers.  You would have
to have a silly long escape sequence - and that could conflict with
length restrictions on assembly identifiers, and it would certainly look
strange to anyone examining listing files, linker map files, etc., or
using a debugger.  And of course everything would fail if you tried to
link these symbols with code generated with other tools.

You will probably also find that using a $ in identifiers causes
challenges or incompatibilities with all sorts of other tools, such as
IDE's with syntax highlighting, tag generators, automatic code
documenters, etc.

And thus today's situation - that some compilers reject $ altogether,
and that others accept it if the backend assembler is happy, is the best
that can be done.  This is for practical and sensible reasons - not
because compiler writers are lazy, stupid, stuck in the 70's, or did not
think of adding an extra "case" line to their software.

> 
>> Maybe you shouldn't assume you're smarter than everyone else.
>> (Or maybe I should drop you back in my KF, most of your posts
>> just raise my blood pressure.)
> 
> Some posts raise /mine/ notably ones from G Owen. But those are
> sustained personal insults.
> 
> 

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

#108463

On 25/04/2017 12:07, David Brown wrote:
> On 25/04/17 11:40, bartc wrote:

>> In the rare case of a compiler working with an existing assembler that
>> doesn't support '$' (or any other character, eg. Unicode),
>
> What is it that you think is rare?  That compilers work with existing
> assemblers?  Most compilers generate assembly outputs, and most make use
> of existing assemblers.
>
> Or do you think that it is rare for an assembler to use a dollar sign in
> some special way that is incompatible (or at least inconvenient) with
> using dollars in identifiers?
>
> I know of assemblers that use $ to indicate local variables, assemblers
> that use it for hex literals (rather than C's 0x), assemblers that use
> it for register names, assemblers that use it for "current position" -
> and assemblers that simply reject it as a letter.

So you're saying they're all different? In which case, the answer is to 
cripple the language to work to the lowest common denominator? If one 
assembler only works in upper case, the language should only allow upper 
case too.

There are sometimes external influences, for example linkers limiting 
the lengths of global names. But even there it is possible to around the 
restrictions (as MSDOS did with allowing longer, free-format filenames 
within the 8.3 filename format).

Anyway these are all very easy to fix. How long does it take to write an 
assembler? It must be a lot easier than writing a compiler!

> There are /many/ assemblers out there.  Your experience is with a couple
> of x86 tools and maybe a brief look at something for ARM - your
> extrapolations of your narrow (albeit in-depth) experiences as though
> they were general rules, makes you look silly.

In the 70s I used assemblers for 6800, some 16-bit machine, and for 
PDP10. I just checked the manual for the latter's assembler ('macro10'), 
and it allows dollars in symbol names.

In the 80s, I wrote assemblers for 8051, Z80 and 80186. In the 90s, I 
wrote inline assemblers for 80386. For a while I wrote my own linkers.

Very narrow? Maybe. But we're talking about allowing a $ as part of 
name; it's rocket science.

> Yes, an escape mechanism of some sort /could/ be used - but there are no
> forms of reserved identifiers that could sensibly be used, so there is
> nothing to stop conflict with other valid identifiers.  You would have
> to have a silly long escape sequence - and that could conflict with
> length restrictions on assembly identifiers, and it would certainly look
> strange to anyone examining listing files, linker map files, etc., or
> using a debugger.  And of course everything would fail if you tried to
> link these symbols with code generated with other tools.

Again, these should not be a consideration when designing a language (if 
it's successful, the tools will follow), otherwise nothing would ever 
progress.

(BTW have you checked whether those tools do in fact support $? The fact 
that gcc does so, suggests that they do.)

> And thus today's situation - that some compilers reject $ altogether,
> and that others accept it if the backend assembler is happy, is the best
> that can be done.

In that case why bother at all?

I'm in the annoying situation where I like to use $ rather than _ for 
special 'decoration', but one or two out of the six C compilers I test 
with don't support $. Even though they support the same targets.

The odd one out is Tiny C, which is too useful a compiler to decide not 
to support. There is also lccwin, which supports $ but not at the start 
of a name.

> This is for practical and sensible reasons - not
> because compiler writers are lazy, stupid, stuck in the 70's, or did not
> think of adding an extra "case" line to their software.

In the case of Tiny C, I think everything is done internally. So what's 
the excuse, saving a few bytes of code? It can't be that desperate to be 
stay tiny!

-- 
bartc

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

#108464

On 25/04/2017 13:24, bartc wrote:

> ... we're talking about allowing a $ as part of
> [a] name; it's rocket science.

And rocket science is child's play!

But you know what I meant ...

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

#108465

bartc <bc@freeuk.com> writes:

> On 25/04/2017 12:07, David Brown wrote:
>> On 25/04/17 11:40, bartc wrote:
>
>>> In the rare case of a compiler working with an existing assembler that
>>> doesn't support '$' (or any other character, eg. Unicode),
>>
>> What is it that you think is rare?  That compilers work with existing
>> assemblers?  Most compilers generate assembly outputs, and most make use
>> of existing assemblers.
>>
>> Or do you think that it is rare for an assembler to use a dollar sign in
>> some special way that is incompatible (or at least inconvenient) with
>> using dollars in identifiers?
>>
>> I know of assemblers that use $ to indicate local variables, assemblers
>> that use it for hex literals (rather than C's 0x), assemblers that use
>> it for register names, assemblers that use it for "current position" -
>> and assemblers that simply reject it as a letter.
>
> So you're saying they're all different? In which case, the answer is
> to cripple the language to work to the lowest common denominator?

Can I confirm that this is an accurate statement of your opinion -- that
a language (maybe only C) is literally *crippled* because you can't rely
on using $ in an identifier?  I ask because I think you sometimes just
say stuff to get a rise from people.

<snip>
> In the case of Tiny C, I think everything is done internally. So
> what's the excuse, saving a few bytes of code? It can't be that
> desperate to be stay tiny!

Excuse?  Is that also a genuine opinion -- any C compiler that does not
permit $ in an identifier should have an *excuse* for not doing so?

Whatever their "excuse" it's not code size since tcc /does/ use $, it's
juts they decided to use it differently.

-- 
Ben.

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

#108466

On 25/04/2017 13:59, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:

>> So you're saying they're all different? In which case, the answer is
>> to cripple the language to work to the lowest common denominator?
>
> Can I confirm that this is an accurate statement of your opinion -- that
> a language (maybe only C) is literally *crippled* because you can't rely
> on using $ in an identifier?  I ask because I think you sometimes just
> say stuff to get a rise from people.

No not literally. And not specifically that minor issue.

C would look very different though if $ had been used for system names 
rather than the hard-to-see _. (Both still ugly, but at least it's 
easier to spot $.)

It is rather strange: $ is one of the 96 printable ASCII characters, 
it's even one of the 64 you got on a teletype, yet it hardly figures in 
the language.

> <snip>
>> In the case of Tiny C, I think everything is done internally. So
>> what's the excuse, saving a few bytes of code? It can't be that
>> desperate to be stay tiny!
>
> Excuse?  Is that also a genuine opinion -- any C compiler that does not
> permit $ in an identifier should have an *excuse* for not doing so?

Yes, when most others do support it, then you might well ask why not. 
Especially if you have code that's been using $, and it doesn't compile 
because of it.

> Whatever their "excuse" it's not code size since tcc /does/ use $, it's
> juts they decided to use it differently.
>

In what way? I've seen it in the source code, but for something called 
an 'ldname'.

-- 
bartc

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

#108467

bartc <bc@freeuk.com> writes:

> On 25/04/2017 13:59, Ben Bacarisse wrote:
<snip>
>> Whatever their "excuse" it's not code size since tcc /does/ use $, it's
>> [just] they decided to use it differently.
>
> In what way? I've seen it in the source code, but for something called
> an 'ldname'.

I don't know, but it is pre-processed as a single-character token so
using it in names would require a change rather than an addition.

-- 
Ben.

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

#108485

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> bartc <bc@freeuk.com> writes:
>> On 25/04/2017 13:59, Ben Bacarisse wrote:
> <snip>
>>> Whatever their "excuse" it's not code size since tcc /does/ use $, it's
>>> [just] they decided to use it differently.
>>
>> In what way? I've seen it in the source code, but for something called
>> an 'ldname'.
>
> I don't know, but it is pre-processed as a single-character token so
> using it in names would require a change rather than an addition.

The $ character isn't part of the basic source or execution
character set, so it needn't be pre-processed at all.  A conforming
C implementation could easily exist on a system that doesn't support
the $ character at all.  Both ASCII and EBCDIC include it, so that's
not likely in practice -- but in the past there might have been
ASCII-based character sets that substitute some other character
for $ (I'm not sufficiently interested to verify that).

Sure, it might be a one-line compiler change to permit $ in
identifiers.  Actually more than that since it would need to
be diagnosed in conforming mode, unless you want to change the
language to allow it unconditionally -- and even then real-world C
compilers are going to have modes to enforce conformance to earlier
C standards.  And if C identifiers are mapped directly to assembly
language identifiers and/or linker symbols, there will have to be
additional code to generate valid identifiers if the assembler or
linker doesn't like $, or doesn't like it exactly the same way the
C compiler does (can it start an identifier?).

A similar level of work could allow @ and ` in identifiers.  But then
allowing ` would interfere with Markdown, which is commonly used
to quote snippets of C source code, and @ might cause other problems.

Even ignoring all that, the amount of work required to implement
a feature is only one of a number of considerations that should
affect the decision of whether to support that feature.

I've never thought that C's problem is that it doesn't use enough
punctuation characters.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#108489

On Tuesday, April 25, 2017 at 7:53:08 PM UTC+1, Keith Thompson wrote:
> 
> I've never thought that C's problem is that it doesn't use enough
> punctuation characters.
> 
Basic uses $ to tag string variables, and some versions used & for 
integers. Perl uses $ for scalars and @ for arrays, but it's notorious
for being hard to read.  

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

#108492

On 25/04/2017 19:52, Keith Thompson wrote:

> Even ignoring all that, the amount of work required to implement
> a feature is only one of a number of considerations that should
> affect the decision of whether to support that feature.

Yet, it's supported by DMC. By gcc. By MSVC. By Pelles C. By Clang. By 
nearly all the C compilers on Godbolt.

With a feature already so widespread, it becomes problematic /not/ 
having it.

> I've never thought that C's problem is that it doesn't use enough
> punctuation characters.

It wouldn't be a punctuation character. "$$$" would be a single 
identifier just like "___". Not three successive symbols.


-- 
bartc

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

#108497

On 25/04/17 23:14, bartc wrote:
> On 25/04/2017 19:52, Keith Thompson wrote:
>
>> Even ignoring all that, the amount of work required to implement
>> a feature is only one of a number of considerations that should
>> affect the decision of whether to support that feature.
>
> Yet, it's supported by DMC. By gcc. By MSVC. By Pelles C. By Clang. By
> nearly all the C compilers on Godbolt.
>
> With a feature already so widespread, it becomes problematic /not/
> having it.

It would only be a problem if the /use/ of $ in identifiers in C was 
widespread, rather than just the compiler support for it.  Further, the 
$ would need to be used in code that is not bound to particular 
compilers in other ways (such as requiring the modern C11 standard, or 
support for multiple target cpus, or other compiler extensions).

>
>> I've never thought that C's problem is that it doesn't use enough
>> punctuation characters.

C++ could perhaps do with support for more symbols/punctuation for new 
operators, but C has enough IMHO.

>
> It wouldn't be a punctuation character. "$$$" would be a single
> identifier just like "___". Not three successive symbols.
>

That's true, logically.  But visually, the $ reads like punctuation or a 
symbol, not unlike _ (except more disruptive to read).

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

#108503

On 25/04/2017 23:16, David Brown wrote:
> On 25/04/17 23:14, bartc wrote:
>> On 25/04/2017 19:52, Keith Thompson wrote:
>>
>>> Even ignoring all that, the amount of work required to implement
>>> a feature is only one of a number of considerations that should
>>> affect the decision of whether to support that feature.
>>
>> Yet, it's supported by DMC. By gcc. By MSVC. By Pelles C. By Clang. By
>> nearly all the C compilers on Godbolt.
>>
>> With a feature already so widespread, it becomes problematic /not/
>> having it.
>
> It would only be a problem if the /use/ of $ in identifiers in C was
> widespread, rather than just the compiler support for it.  Further, the
> $ would need to be used in code that is not bound to particular
> compilers in other ways (such as requiring the modern C11 standard, or
> support for multiple target cpus, or other compiler extensions).

It's Catch-22: I don't use $ in any of my C code that I want anyone else 
to compile. /Because/ support is not guaranteed.

(Which is a bit of a nuisance. If I need a series of temps, they end up 
being called _1, _2, _3, instead of $1, $2, $3.)

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

#108517

On 26/04/17 01:13, bartc wrote:
> On 25/04/2017 23:16, David Brown wrote:
>> On 25/04/17 23:14, bartc wrote:
>>> On 25/04/2017 19:52, Keith Thompson wrote:
>>>
>>>> Even ignoring all that, the amount of work required to implement
>>>> a feature is only one of a number of considerations that should
>>>> affect the decision of whether to support that feature.
>>>
>>> Yet, it's supported by DMC. By gcc. By MSVC. By Pelles C. By Clang. By
>>> nearly all the C compilers on Godbolt.
>>>
>>> With a feature already so widespread, it becomes problematic /not/
>>> having it.
>>
>> It would only be a problem if the /use/ of $ in identifiers in C was
>> widespread, rather than just the compiler support for it.  Further, the
>> $ would need to be used in code that is not bound to particular
>> compilers in other ways (such as requiring the modern C11 standard, or
>> support for multiple target cpus, or other compiler extensions).
> 
> It's Catch-22: I don't use $ in any of my C code that I want anyone else
> to compile. /Because/ support is not guaranteed.

In the C world, there are standards to say what is guaranteed for a wide
range of tools.  There are common extensions that are available on many
tools - the C standards even mentions some, including the use of $ in
identifiers (J.5.2 if you want to look it up).  And of course not all
tools support the standards as well as might be wished.  But the
standards are the nearest there is to giving the guaranteed behaviour
for a C compiler - and they don't include $ in identifiers.

> 
> (Which is a bit of a nuisance. If I need a series of temps, they end up
> being called _1, _2, _3, instead of $1, $2, $3.)

I can't see any problem with that.  You are talking about temporary
identifiers generated in intermediary code by a translator, which will
normally only be seen by the backend C compiler.  Pretty much the only
person who will ever see these identifiers will be /you/, as the creator
and debugger of the translator program.  _1, _2, _3 are fine names - as
are tXwZ_1, tXwZ_2, etc., and anything else unlikely to clash with a
user symbol.  (It is absolutely fine for you, in specifying your
language, to say that any identifiers starting with tXwZ are reserved
for the implemnentation.)

If you think the use of $ is better than alternatives, and it works with
the backends you want to support, then use $.  If you want to use
backends that don't work with $, then don't use it.  It is that simple.

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

#108494

On Tuesday, April 25, 2017 at 1:53:08 PM UTC-5, Keith Thompson wrote:
> The $ character isn't part of the basic source or execution
> character set, so it needn't be pre-processed at all.  A conforming
> C implementation could easily exist on a system that doesn't support
> the $ character at all.  Both ASCII and EBCDIC include it, so that's
> not likely in practice -- but in the past there might have been
> ASCII-based character sets that substitute some other character
> for $ (I'm not sufficiently interested to verify that).

Many machines don't have all characters of the C source character set,
but a simple way to handle that without having to get into wackiness
like trigraphs would be to require every implementation to identify, for
each member of the source character set, at least one character or
sequence thereof which may be used to represent it.  If an implementation's
source character set would depict code 0x5F as an back-arrow but some other
character code would appear as a line at the bottom of the character cell,
an implementation might accept either or both as being equivalent to an
underscore, provided that it documents such behavior.

Supplement that rule with one that allows implementations to define
additional "identifier" characters which may be used in user or
implementation-defined identifiers (but not in any Standard-defined ones)
and that should pretty well take care of things.  If one system allows
external names with @ signs, and if code might need to define or use such
identifiers to interact with other parts of the system, an implementation
for that system should allow @ within names.  If another system would not
allow such names, an implementation for that system should not allow the
character to appear in external labels, and most applications would have
relatively little need to use it for internal symbols either.

> Sure, it might be a one-line compiler change to permit $ in
> identifiers.  Actually more than that since it would need to
> be diagnosed in conforming mode, unless you want to change the
> language to allow it unconditionally -- and even then real-world C
> compilers are going to have modes to enforce conformance to earlier
> C standards.  And if C identifiers are mapped directly to assembly
> language identifiers and/or linker symbols, there will have to be
> additional code to generate valid identifiers if the assembler or
> linker doesn't like $, or doesn't like it exactly the same way the
> C compiler does (can it start an identifier?).

The primary purpose for using a $ within an exported variable name would
be to expose a name containing that character to outside code in cases
where it would be useful to do so.  Since the usefulness of such names
would likely depend upon factors outside the compiler's control, there's
no reason the compiler should need to worry about the particulars of
whether particular names are apt to be useful.  If a linker is going to
choke on a given name, that can be left to the linker rather than the
compiler.

> A similar level of work could allow @ and ` in identifiers.  But then
> allowing ` would interfere with Markdown, which is commonly used
> to quote snippets of C source code, and @ might cause other problems.

Simply recognize that an implementation may define as an extension
additional characters would--in the author's judgment--make it most
useful for its intended purpose, and recognize that code which uses such
characters will be incompatible with implementations that don't support
them.

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

#108468

On Tuesday, April 25, 2017 at 2:20:36 PM UTC+1, Bart wrote:
> O
> C would look very different though if $ had been used for system names 
> rather than the hard-to-see _. (Both still ugly, but at least it's 
> easier to spot $.)
> 
> It is rather strange: $ is one of the 96 printable ASCII characters, 
> it's even one of the 64 you got on a teletype, yet it hardly figures in 
> the language.
> 
This was the 1970s. The dollar sign was still intimately tied to the currency
and didn't appear on many non-American keyboards.

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

#108475

On Tue, 25 Apr 2017 14:20:35 +0100, bartc <bc@freeuk.com> wrote:

>On 25/04/2017 13:59, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> So you're saying they're all different? In which case, the answer is
>>> to cripple the language to work to the lowest common denominator?
>>
>> Can I confirm that this is an accurate statement of your opinion -- that
>> a language (maybe only C) is literally *crippled* because you can't rely
>> on using $ in an identifier?  I ask because I think you sometimes just
>> say stuff to get a rise from people.
>
>No not literally. And not specifically that minor issue.
>
>C would look very different though if $ had been used for system names 
>rather than the hard-to-see _. (Both still ugly, but at least it's 
>easier to spot $.)


VMS did that.  The names with the dollar signs are *much* uglier.  At
least, IMO.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web