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

#108481

Ben Bacarisse <ben.usenet@bsb.me.uk> 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.

Trolls gotta troll.

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

#108482

On 25/04/2017 18:39, Gareth Owen wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> 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.
>
> Trolls gotta troll.

****

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

#108483

On Tuesday, April 25, 2017 at 10:49:51 AM UTC-7, Bart wrote:
> On 25/04/2017 18:39, Gareth Owen wrote:
> > Ben Bacarisse <ben.usenet@bsb.me.uk> 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.
> >
> > Trolls gotta troll.
> 
> ****

The standard says the compiler tokenizes in translation phase 3 of
the pre-processor. After that it doesn't matter what the source 
presentation looked like. Phases 1 and 2 are relatively trivial so
it would be fair to say that a compiler looses all dependence on the
appearance of the source immediately.   

The standard also describes what might be called one possible source
shape discipline. For any other isomorphic source (there is a one-to-
one mapping of external symbols) all one needs to do is to add a pre-
pre-processor that changes one's favorite source shape into the 
standard's shape.

For example one might write " AND "instead of "&&" and the pre-pre-
processor would change that to "&&". 

But I would prefer to roll phases 1 and 2 into 3 and simply modify the
tokenizer to accept my set of source "tokens".

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

#108484

On 25/04/2017 19:19, David Kleinecke wrote:

> The standard says the compiler tokenizes in translation phase 3 of
> the pre-processor. After that it doesn't matter what the source
> presentation looked like. Phases 1 and 2 are relatively trivial so
> it would be fair to say that a compiler looses all dependence on the
> appearance of the source immediately.
>
> The standard also describes what might be called one possible source
> shape discipline. For any other isomorphic source (there is a one-to-
> one mapping of external symbols) all one needs to do is to add a pre-
> pre-processor that changes one's favorite source shape into the
> standard's shape.
>
> For example one might write " AND "instead of "&&" and the pre-pre-
> processor would change that to "&&".

Yes, you can create a different syntax for the language /but you are 
still writing C/.

> But I would prefer to roll phases 1 and 2 into 3 and simply modify the
> tokenizer to accept my set of source "tokens".

But there is a problem: suppose A writes a program using this new 
'source shape', and wants to share it with B. What does A have to give B?

If A was writing plain C, then just C source suffices. But now A has to 
provide extra tools to do this extra pre-processing. If B wants to read 
and maintain the program, then there is also the question of B having to 
understand this new syntax.

(But maybe, when source already seems to rely on so much scripting 
anyway, that is outside of the language, this might not be that big a deal.)

-- 
bartc

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

#108500

David Kleinecke <dkleinecke@gmail.com> writes:
<snip>
> The standard says the compiler tokenizes in translation phase 3 of
> the pre-processor. After that it doesn't matter what the source 
> presentation looked like.

That not absolutely correct.  In translation phase 4 the source
presentation can become relevant again due to the # macro operator.

<snip>
> For example one might write " AND "instead of "&&" and the pre-pre-
> processor would change that to "&&". 
>
> But I would prefer to roll phases 1 and 2 into 3 and simply modify the
> tokenizer to accept my set of source "tokens".

Since this is your design, you can do what you like with something like

  #define s(t) #t
  s(AND)

but converting AND to && is out of step with existing practice.  Where C
currently has alternate spellings for tokens, these much be recovered
when a token is "stringized".

-- 
Ben.

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

#108509

On Tuesday, April 25, 2017 at 3:36:55 PM UTC-7, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> <snip>
> > The standard says the compiler tokenizes in translation phase 3 of
> > the pre-processor. After that it doesn't matter what the source 
> > presentation looked like.
> 
> That not absolutely correct.  In translation phase 4 the source
> presentation can become relevant again due to the # macro operator.
> 
> <snip>
> > For example one might write " AND "instead of "&&" and the pre-pre-
> > processor would change that to "&&". 
> >
> > But I would prefer to roll phases 1 and 2 into 3 and simply modify the
> > tokenizer to accept my set of source "tokens".
> 
> Since this is your design, you can do what you like with something like
> 
>   #define s(t) #t
>   s(AND)
> 
> but converting AND to && is out of step with existing practice.  Where C
> currently has alternate spellings for tokens, these much be recovered
> when a token is "stringized".

Of course, using AND for && would be perverse - but you know
people. 

You are right about phase 4. A macro can create a new token and
that must be passed through phases 1, 2 and 3. This is pain in the
neck but not actually very difficult.

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

#108513

On Tue, 25 Apr 2017 17:04:21 -0700 (PDT), David Kleinecke
<dkleinecke@gmail.com> wrote:

>On Tuesday, April 25, 2017 at 3:36:55 PM UTC-7, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> <snip>
>> > The standard says the compiler tokenizes in translation phase 3 of
>> > the pre-processor. After that it doesn't matter what the source 
>> > presentation looked like.
>> 
>> That not absolutely correct.  In translation phase 4 the source
>> presentation can become relevant again due to the # macro operator.
>> 
>> <snip>
>> > For example one might write " AND "instead of "&&" and the pre-pre-
>> > processor would change that to "&&". 
>> >
>> > But I would prefer to roll phases 1 and 2 into 3 and simply modify the
>> > tokenizer to accept my set of source "tokens".
>> 
>> Since this is your design, you can do what you like with something like
>> 
>>   #define s(t) #t
>>   s(AND)
>> 
>> but converting AND to && is out of step with existing practice.  Where C
>> currently has alternate spellings for tokens, these much be recovered
>> when a token is "stringized".
>
>Of course, using AND for && would be perverse - but you know
>people. 


OTOH, using "and" for && only requires including iso646.h.  The exact
level of perversity that entails I'll leave for others to judge.

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

#108471

On 25/04/17 14:24, bartc wrote:
> 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.
> 

I am saying that there are lots of assemblers, many of which use
characters such as $ for a variety of purposes, making it hard to use
them in identifiers as "letters".

Standard C lets you use a-z, A-Z and _ as "letters", along with the
digits 0-9, in identifiers.  Any assembler that can be used as a backend
for a C compiler will support these (in a case-sensitive manner).

A compiler /may/ support additional "letters" such as $.  But this will
only work if the compiler supports it, /and/ the assembler supports it -
this support is implementation dependent.

How can this be so difficult to understand?

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

You might choose to do something like that - it is certainly possible.
But for a variety of reasons, people (compiler writers and compiler
users) prefer that there is a very close match between compiler
identifiers and assembly identifiers - it makes it far easier to read
the generated assembly and other listing and map files, and makes it
easier to link the file with other files.  (For example, identifiers are
preceded by "_" to avoid conflicts with register names.)  You can read
about the unpleasantness of C++ mangled function names to see the
disadvantages of such mangling.  (For C++, it was an unavoidable cost.)
 I cannot imagine anyone wanting to go through this simply to allow $
symbols in identifier names.

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

I would imagine that writing an assembler is a good deal easier than
writing a compiler.  It is still much more effort than /not/ writing an
assembler and simply using existing ones.  Would you write a new
assembler just to allow $ symbols in C identifiers?

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

That's fine - for those assembly languages that traditionally do not use
$ for other purposes.

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

No, I have not bothered checking such tools - because $ is not something
that I or many other people use in identifiers, even when it is
supported by a compiler and assembler.

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

That's a very relevant question.  I can't see many good uses of $ in
identifier names.  They /might/ be of interest for some libraries as
"internal" symbols, simply because they have a very low risk of crashing
with any normal user symbols because people rarely use $.

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

I can see that as being a possible good use of $.  You either have to
limit the choice of backend C compilers you support, or you find an
alternative decoration.

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

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

#109023

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?

The principal point of having a standardized language is to be
able to write programs that will run in all target environments.
That essentially requires making use of only those elements that
are in the common subset (ie, the largest common subset, not the
smallest common subset - the phrase "lowest common denominator"
is a misnomer).

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

#109032

On Tuesday, May 2, 2017 at 7:25:11 AM UTC-5, Tim Rentsch wrote:
> The principal point of having a standardized language is to be
> able to write programs that will run in all target environments.

That will run in all target environments *of interest*.

> That essentially requires making use of only those elements that
> are in the common subset (ie, the largest common subset, not the
> smallest common subset - the phrase "lowest common denominator"
> is a misnomer).

The phrase "to cater to the lowest common denominator" is a common idiom
in American English; the phrase "greatest common factor" would probably be
more appropriate mathematically, but doesn't match the idiomatic usage.

It makes sense to limit code to those elements that will be common to all
platforms of interest.  Is there any reason code should need to avoid using
features that would be unsupportable on 1% of platforms, if those platforms
would be incapable of running the code for other reasons anyway?

If implementation writers can be expected to support features and guarantees
beyond those mandated by the Standard in cases where it makes sense to do so,
then there would be no need for the Standard to mandate all useful behaviors.
The failure of the Standard to mandate behavioral guarantees which would make
sense on the vast majority of platforms is consistent with such expectation,
and is not consistent with an expectation that compiler writers will interpret
permission to do anything as a judgment that anything they might do should be
viewed as sensible merely because it is permitted.

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

#109315

supercat@casperkitty.com writes:

> On Tuesday, May 2, 2017 at 7:25:11 AM UTC-5, Tim Rentsch wrote:
>> The principal point of having a standardized language is to be
>> able to write programs that will run in all target environments.
>
> That will run in all target environments *of interest*.

That's already included in the "target environment" phrase.  What
makes an environment be a target is that it is of interest.

>> That essentially requires making use of only those elements that
>> are in the common subset (ie, the largest common subset, not the
>> smallest common subset - the phrase "lowest common denominator"
>> is a misnomer).
>
> The phrase "to cater to the lowest common denominator" is a common idiom
> in American English;  the phrase "greatest common factor" would probably be
> more appropriate mathematically, but doesn't match the idiomatic usage.

You really just enjoy being an annoying prick don't you.

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

#108472

On Tuesday, April 25, 2017 at 6:07:27 AM UTC-5, David Brown wrote:
> 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.

Nothing would preclude a compiler from allowing the use of dollar signs in
macros or in symbols that are neither imported nor exported, no matter what
an assembler chose to do.  As for imported/exported names, I think C would
have benefited from a qualifier or directive which would set the import/export
name for any symbol using a string literal, thus making it possible to e.g.
call an outside function named "restrict", and from a directive allowing any
character or characters which have no other meaning to be included within
the set that C will regard as identifier characters.  Even if the latter
ability didn't apply to exported names, code could still say, e.g.

    // Assuming a directive has indicated that $ should be allowed in macros
    #define $foo DOLLAR_FOO

and then use $foo everywhere else.

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

#108477

On Tue, 25 Apr 2017 13:07:15 +0200, David Brown
<david.brown@hesbynett.no> wrote:

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


While I rarely agree with bartc, I have zero sympathy with the notion
that the limitations of some unrelated bit of software used internally
in a compiler implementation should dictate limitations on the
language implemented.

That being said, it's clear that some accommodations have been made
(the limits on required significance on external names in C89, for
example).  OTOH, there is nothing in the current scheme that makes
name conflicts impossible either.

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

#108479

On Tue, 25 Apr 2017 09:48:05 -0500, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Tue, 25 Apr 2017 13:07:15 +0200, David Brown
><david.brown@hesbynett.no> wrote:
>
>>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.
>
>
>While I rarely agree with bartc, I have zero sympathy with the notion
>that the limitations of some unrelated bit of software used internally
>in a compiler implementation should dictate limitations on the
>language implemented.
>
>That being said, it's clear that some accommodations have been made
>(the limits on required significance on external names in C89, for
>example).  OTOH, there is nothing in the current scheme that makes
>name conflicts impossible either.


Which is not to say that I find the absence of dollar signs in
identifiers to be much of an issue.

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

#108515

On 25/04/2017 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.

OK, Mr Smarty Pants. How do you deal with identifiers with
external linkage? (C99 6.2.2)


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

New features have cost-benefit trade-offs.
It's impossible to perform a useful analysis when one's
experience is limited to Windows/x86.


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

Do you believe I didn't understand the first time?


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

I checked for gas, the assembler overwhelmingly used on
Linux and *BSD systems.

https://sourceware.org/binutils/docs/as/Symbol-Intro.html
https://sourceware.org/binutils/docs/as/Symbol-Names.html

    Symbol names begin with a letter or with one of `._'. On most
    machines, you can also use $ in symbol names; exceptions are noted in
    Machine Dependencies. That character may be followed by any string of
    digits, letters, dollar signs (unless otherwise noted for a
    particular target machine), and underscores.
Are you suggesting gcc, clang, icc, and every other compiler ever
made should implement the same "escape mechanism"? Then this would
have to be part of some standard, presumably ISO/IEC 9899?

EOT

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

#108521

On 26/04/2017 07:46, Noob wrote:
> On 25/04/2017 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.
>
> OK, Mr Smarty Pants. How do you deal with identifiers with
> external linkage? (C99 6.2.2)
>
>
>> 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).
>
> New features have cost-benefit trade-offs.
> It's impossible to perform a useful analysis when one's
> experience is limited to Windows/x86.

What's your vast experience then?

I wrote my first compiler (of sorts) on a DECSystem-10. In assembly 
code. And the assembler supported "$" in names (whether or not I made 
use of that feature, I can't remember). And the first interpreter (of 
sorts) I played with was on a PDP11. No Windows or x86 in sight.

> Are you suggesting gcc, clang, icc,

Um, gcc, clang and icc appear to support "$" in identifiers.

In fact most C compilers seem to do so. So I'm not sure what we're 
arguing about.

The problem for me is that one or two that I use don't support it. And 
they both use their own assemblers and linkers so compatibility with 
other tools isn't the reason.

-- 
bartc

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

#108523

On 26/04/2017 07:46, Noob wrote:
> On 25/04/2017 11:40, bartc wrote:

>> 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).
>
> New features have cost-benefit trade-offs.

BTW 'sixbit', which only allows 64 characters, includes '$'

Radix-50, which only allows /50/ characters, also includes '$'.

So you couldn't have a-z, but you could have dollar symbols. That 
suggests '$' was considered important (by DEC at least).


-- 
bartc

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

#109460

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

What platform are you using that needs this?

I've seen plenty of assemblers that use $ as a name for the current
location counter.  Most of these parse $ as a single-character
token, so anything like aaa$bbb will be a syntax error, for the
same reason that three consecutive identifiers like aaa bbb ccc
would be a syntax error.  It is possible to allow symbols containing
$ in these assemblers without parsing ambiguity.  This may require
substantial code changes.

There are also plenty of assemblers that use $ as a prefix for a
machine instruction operand, sometimes to indicate that it is an
immediate operand (rather than a memory reference).  Others use $
as a prefix for a constant to indicate that it is in hexadecimal.
This can be compatible with the use of $ in identifiers if an
indentifier is prohibited from *BEGINNING* with a $.  Is that
acceptable for the OP's intended usage?


> 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 '$':

That's unlikely.  For one thing, a C compiler needs two different
character classes, one for the characters that can *BEGIN* an
identifier, and one for the characters after the first in an
identifier (digits are part of the second class but not the first).
It is probably more efficient for a compiler to use the C locale
and <ctype.h> functions.  Or, if they're allowing all the characters
in Unicode (Unicode has properties "ID_Start" and "ID_Continue" for
this, and they seem to apply to all of a random sampling of Egyptian
Hieroglyphics), that would probably involve a switch with over 10,000
cases.  

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


Definition:  system linker - the linker for a platform that is the first
one in this list, if there is one at all:
	(a) The linker that ships with the system.
	(b) The linker from an add-on development package that is distributed by
	the same vendor as the system.
	(c) The most-used linker for the platform if neither (a) nor (b) are available.
	(d) There may not even BE a system linker.

If there is a system linker, it's generally very desirable that you be
compatible with it.  If there is no system linker, then chances are your
implementation will become one, and you don't have to worry about backward
compatability with anything but older versions of your code.

IMHO, a compiler for a platform should not accept $ in identifiers
by default if the system linker won't accept them and it doesn't
ship with a linker that accepts those identifiers.  In other words,
don't confuse the user with vague linker errors when the compiler
should have caught the error earlier and there *ISN'T* a linker (or
escape mechanism) that will work.

Devising an escape mechanism that is an extension, not an incompatible
change, may not be easy (or even possible, given compatability
requirements).  If there's an existing escape mechanism, great,
extend it.  URL-encoding may come to mind if the system linker
accepts symbols with a % in it, but it may be impossible to stay
compatible with the system linker and your linker with arbitrary
use of % permitted and pre-existing.  If the system linker generates
'foo%' and yours generates 'foo%25', they won't match up.  The
system linker's 'foo%25' may incorrectly match your 'foo%' (which
escaped is 'foo%25') and mess up with a bogus duplicate symbol
error.


Assemblers are also likely to have all sorts of other reserved
identifiers, such as opcode names, register names, pseudo-op names,
etc.  In the past this was dealt with by prefixing all C identifiers
with "_".

Incidentally, in C, the backquote is already taken for BCD constants,
although that usage was pretty obsolete even in 1978.
@ may be reserved in assembly language as a prefix for register names.

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

#109478

On 08/05/2017 04:25, Gordon Burditt wrote:
>>>> It's silly really because it can be literally a one-line change in a
>>>> compiler to allow $.
>
> What platform are you using that needs this?

The platform doesn't need it; /I/ do because I like using $ to ensure a 
special identifier won't clash with a normal one. "_" is not as good for 
that purpose because user identifiers are full of "_", and it doesn't 
stand out as well.

>> 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 '$':
>
> That's unlikely.  For one thing, a C compiler needs two different
> character classes, one for the characters that can *BEGIN* an
> identifier, and one for the characters after the first in an
> identifier (digits are part of the second class but not the first).

OK, two lines if the cases are each put on their own line. But here are 
the two relevant lines from my own C compiler (not C code):

     when 'A'..'Z','a'..'z','$','_' then
     when 'A'..'Z','a'..'z','$','_','0'..'9' then

So providing support for "$" doesn't require any more lines, it just 
needs a minor tweak on two lines. (And no, it won't work on EBCDIC, but 
I don't care!)

(Actually it could be reduced to a one-line tweak if necessary.)

> It is probably more efficient for a compiler to use the C locale
> and <ctype.h> functions.  Or, if they're allowing all the characters
> in Unicode (Unicode has properties "ID_Start" and "ID_Continue" for
> this, and they seem to apply to all of a random sampling of Egyptian
> Hieroglyphics), that would probably involve a switch with over 10,000
> cases.

We're not talking about allowing any Unicode character in an identifier. 
This is a small systems language and the $ is useful as a more solid 
partition between two classes of identifiers than _.

(Besides you wouldn't use a 10,000-way switch; if the character wasn't 
ASCII, you'd look at the identifier attribute directly. But they might 
need special treatment if there would be a problem when used with 
external assemblers or linkers.)

>> 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.
>
>
> Definition:  system linker - the linker for a platform that is the first
> one in this list, if there is one at all:
> 	(a) The linker that ships with the system.
> 	(b) The linker from an add-on development package that is distributed by
> 	the same vendor as the system.
> 	(c) The most-used linker for the platform if neither (a) nor (b) are available.
> 	(d) There may not even BE a system linker.
>
> If there is a system linker, it's generally very desirable that you be
> compatible with it.  If there is no system linker, then chances are your
> implementation will become one, and you don't have to worry about backward
> compatability with anything but older versions of your code.
>
> IMHO, a compiler for a platform should not accept $ in identifiers
> by default if the system linker won't accept them and it doesn't
> ship with a linker that accepts those identifiers.  In other words,
> don't confuse the user with vague linker errors when the compiler
> should have caught the error earlier and there *ISN'T* a linker (or
> escape mechanism) that will work.
>
> Devising an escape mechanism that is an extension, not an incompatible
> change, may not be easy (or even possible, given compatability
> requirements).  If there's an existing escape mechanism, great,
> extend it.  URL-encoding may come to mind if the system linker
> accepts symbols with a % in it, but it may be impossible to stay
> compatible with the system linker and your linker with arbitrary
> use of % permitted and pre-existing.  If the system linker generates
> 'foo%' and yours generates 'foo%25', they won't match up.  The
> system linker's 'foo%25' may incorrectly match your 'foo%' (which
> escaped is 'foo%25') and mess up with a bogus duplicate symbol
> error.
>
>
> Assemblers are also likely to have all sorts of other reserved
> identifiers, such as opcode names, register names, pseudo-op names,
> etc.  In the past this was dealt with by prefixing all C identifiers
> with "_".
>
> Incidentally, in C, the backquote is already taken for BCD constants,
> although that usage was pretty obsolete even in 1978.
> @ may be reserved in assembly language as a prefix for register names.
>

You're talking as though this problem hasn't already been solved decades 
ago, and probably dozens of times since.

-- 
bartc

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

#109481

On 08/05/2017 10:35, bartc wrote:

> (not C code):
>
>     when 'A'..'Z','a'..'z','$','_' then
>     when 'A'..'Z','a'..'z','$','_','0'..'9' then
>
> So providing support for "$" doesn't require any more lines, it just
> needs a minor tweak on two lines. (And no, it won't work on EBCDIC, but
> I don't care!)

Actually, if this was translated to C, as would be necessary to run on 
such a machine, then it might well do. Because C case values are all 
separate. Even more reason not to care.

-- 
bartc

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

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

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

csiph-web