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

Groups > comp.lang.c > #108471

Re: Variable naming issue

Show all headers | View raw

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

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web