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

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

dollar sign in variable name

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

Contents

  dollar sign in variable name Jay Braun <lyngwyst@gmail.com> - 2015-11-19 16:18 -0800
    Re: dollar sign in variable name BartC <bc@freeuk.com> - 2015-11-20 00:27 +0000
      Re: dollar sign in variable name Jay Braun <lyngwyst@gmail.com> - 2015-11-19 16:29 -0800
        Re: dollar sign in variable name Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-11-19 20:05 -0700
    Re: dollar sign in variable name Richard Heathfield <rjh@cpax.org.uk> - 2015-11-20 00:30 +0000
      Re: dollar sign in variable name Jay Braun <lyngwyst@gmail.com> - 2015-11-19 16:37 -0800
        Re: dollar sign in variable name Ian Collins <ian-news@hotmail.com> - 2015-11-20 13:42 +1300
          Re: dollar sign in variable name BartC <bc@freeuk.com> - 2015-11-20 00:47 +0000
            Re: dollar sign in variable name Philipp Klaus Krause <pkk@spth.de> - 2015-11-21 17:24 +0100
              Re: dollar sign in variable name Philip Lantz <prl@canterey.us> - 2015-11-22 15:37 -0800
        Re: dollar sign in variable name Robert Wessel <robertwessel2@yahoo.com> - 2015-11-19 23:22 -0600
          Re: dollar sign in variable name glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-20 06:51 +0000
      Re: dollar sign in variable name Keith Thompson <kst-u@mib.org> - 2015-11-20 03:32 -0800
      Re: dollar sign in variable name Ken Brody <kenbrody@spamcop.net> - 2015-11-23 13:27 -0500
    Re: dollar sign in variable name Barry Schwarz <schwarzb@dqel.com> - 2015-11-19 16:41 -0800
    Re: dollar sign in variable name glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-20 00:53 +0000
    Re: dollar sign in variable name Geoff <geoff@invalid.invalid> - 2015-11-19 21:40 -0800
    Re: dollar sign in variable name David Brown <david.brown@hesbynett.no> - 2015-11-20 11:04 +0100
    Re: dollar sign in variable name Jay Braun <lyngwyst@gmail.com> - 2015-11-20 06:35 -0800

#76576 — dollar sign in variable name

I was just playing around in gcc, and named a variable game$time, and a function set_game$time, and the compiler accepted it.  The small program linked and ran fine as well.  This required no special options.

Would I be playing with fire if I used dollar signs in identifiers?

As to my rationale:  I am writing some C code to access variables in a legacy FORTRAN application, and thought it would be "nice" to use the same variable names, e.g.:

FORTRAN variable:  GAME$TIME
C functions: 
   get_game$time 
   set_game$time
(with appropriate provisions for FORTRAN's pass-by-reference).

Jay

[toc] | [next] | [standalone]

#76579

On 20/11/2015 00:18, Jay Braun wrote:
> I was just playing around in gcc, and named a variable game$time, and a function set_game$time, and the compiler accepted it.  The small program linked and ran fine as well.  This required no special options.
>
> Would I be playing with fire if I used dollar signs in identifiers?
>
> As to my rationale:  I am writing some C code to access variables in a legacy FORTRAN application, and thought it would be "nice" to use the same variable names, e.g.:
>
> FORTRAN variable:  GAME$TIME
> C functions:
>     get_game$time
>     set_game$time
> (with appropriate provisions for FORTRAN's pass-by-reference).

Some compilers won't like it. (lccwin32 and Tiny C are two examples.)

-- 
Bartc

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

#76580

I had been thinking of using a capital S, like gameStime -- but it looks like Java ("camel case")!

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

#76595

Jay Braun <lyngwyst@gmail.com> writes:

> I had been thinking of using a capital S, like gameStime -- but it
> looks like Java ("camel case")!

I don't see that as a problem.  I like studly-caps (as I refer to it) in
C.

This is no doubt simply a personal conditioning, but whenever I see a $
in a variable name I have horrible flashbacks to early VMS....

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

#76581

On 20/11/15 00:18, Jay Braun wrote:
> I was just playing around in gcc, and named a variable game$time, and a function set_game$time, and the compiler accepted it.  The small program linked and ran fine as well.  This required no special options.
>
> Would I be playing with fire if I used dollar signs in identifiers?

Not if you're happy for your code only to be compilable with gcc, no.

Such things are called "extensions". Any compiler writer can offer 
extensions as long as they don't interfere with what is often called 
"legal" C code. Dollar signs don't interfere (because they're 
"illegal"), so no "legal" C program can include them, and so allowing 
them cannot break any "legal" C program, so it's fine. But don't expect 
it to work when compiled by implementations other than gcc.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#76582

> But don't expect  it to work when compiled by implementations other than gcc.

Maybe I'll use two capital S's:  gameSStime  :--)

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

#76584

Jay Braun wrote:

Please don't snip attributions!

>> But don't expect  it to work when compiled by implementations other than gcc.
>
> Maybe I'll use two capital S's:  gameSStime  :--)

Why not use an underscore?

-- 
Ian Collins

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

#76586

On 20/11/2015 00:42, Ian Collins wrote:
> Jay Braun wrote:
>
> Please don't snip attributions!
>
>>> But don't expect  it to work when compiled by implementations other
>>> than gcc.
>>
>> Maybe I'll use two capital S's:  gameSStime  :--)
>
> Why not use an underscore?

It's a poor substitute. Underscores are almost invisible as they are, 
but it's difficult tell how many consecutive ones you have as they run 
together.

(And just converting ABC$DEF to use an underscore risks clashing with an 
existing ABC_DEF. Aren't leading underscores also reserved?)

-- 
Bartc

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

#76778

On 20.11.2015 01:47, BartC wrote:
> (And just converting ABC$DEF to use an underscore risks clashing with an
> existing ABC_DEF. Aren't leading underscores also reserved?)
> 

Only if followed by another underscore or an uppercase letter.

Philipp

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

#76946

Philipp Klaus Krause wrote:
> BartC wrote:
> > (And just converting ABC$DEF to use an underscore risks clashing with an
> > existing ABC_DEF. Aren't leading underscores also reserved?)
> 
> Only if followed by another underscore or an uppercase letter.

Or if used in an identifier with file scope in either the ordinary or tag
name space. [7.1.3p1, second bullet]

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

#76601

On Thu, 19 Nov 2015 16:37:50 -0800 (PST), Jay Braun
<lyngwyst@gmail.com> wrote:

>> But don't expect  it to work when compiled by implementations other than gcc.
>
>Maybe I'll use two capital S's:  gameSStime  :--)


I assume this is for some kind of mechanical translation process?

Unless Fortran has suddenly started being case sensitive, I'd
implement some sort of escape scheme.  Name all the Fortran variables
something like F_, and then use the underscore character as a
character escape in the name.

So a-z and 0-9 translate directly (as lower case letters), and _A, _B,
_C... are for dollar sign, underscore, etc.  It's not super pretty,
but it would be portable, and fairly obvious when being looked at.  Or
just use the upper case letters as substitutes for the specials.

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

#76606

Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip on $ in names)

> I assume this is for some kind of mechanical translation process?
 
> Unless Fortran has suddenly started being case sensitive, I'd
> implement some sort of escape scheme.  Name all the Fortran variables
> something like F_, and then use the underscore character as a
> character escape in the name.

No, Fortran still isn't case sensitive but can still call C routines
that are. 

It is part of the C interoperability feature, I believe from 
Fortran 2003. 
 
> So a-z and 0-9 translate directly (as lower case letters), and _A, _B,
> _C... are for dollar sign, underscore, etc.  It's not super pretty,
> but it would be portable, and fairly obvious when being looked at.  Or
> just use the upper case letters as substitutes for the specials.

-- glen

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

#76624

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 20/11/15 00:18, Jay Braun wrote:
>> I was just playing around in gcc, and named a variable game$time, and
>> a function set_game$time, and the compiler accepted it.  The small
>> program linked and ran fine as well.  This required no special
>> options.
>>
>> Would I be playing with fire if I used dollar signs in identifiers?
>
> Not if you're happy for your code only to be compilable with gcc, no.
>
> Such things are called "extensions". Any compiler writer can offer 
> extensions as long as they don't interfere with what is often called 
> "legal" C code. Dollar signs don't interfere (because they're 
> "illegal"), so no "legal" C program can include them, and so allowing 
> them cannot break any "legal" C program, so it's fine. But don't expect 
> it to work when compiled by implementations other than gcc.

Strictly speaking, it's not an extension in the sense used in N1570 4p6.
If it were, a diagnostic would still be required when the compiler is
invoked in conforming mode.

6.4.2.1, which defines the syntax of identifiers, permits "other
implementation-defined characters".  That wasn't the case in C90.
(Which is why "gcc -std=c90 -pedantic" warns about it, but
"gcc -std=c99 -pedantic" doesn't.)



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

#77019

On 11/19/2015 7:30 PM, Richard Heathfield wrote:
> On 20/11/15 00:18, Jay Braun wrote:
>> I was just playing around in gcc, and named a variable game$time, and a
>> function set_game$time, and the compiler accepted it.  The small program
>> linked and ran fine as well.  This required no special options.
>>
>> Would I be playing with fire if I used dollar signs in identifiers?
>
> Not if you're happy for your code only to be compilable with gcc, no.
>
> Such things are called "extensions". Any compiler writer can offer
> extensions as long as they don't interfere with what is often called "legal"
> C code. Dollar signs don't interfere (because they're "illegal"), so no
> "legal" C program can include them, and so allowing them cannot break any
> "legal" C program, so it's fine. But don't expect it to work when compiled
> by implementations other than gcc.

<nit>
     Or on VMS, which has things such as "vaxc$errno" and "sys$getdviw()".
</nit>

But your point still stands -- non-standard extension.

-- 
Kenneth Brody

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

#76583

On Thu, 19 Nov 2015 16:18:41 -0800 (PST), Jay Braun
<lyngwyst@gmail.com> wrote:

>I was just playing around in gcc, and named a variable game$time, and a function set_game$time, and the compiler 
>accepted it.  The small program linked and ran fine as well.  This required no special options.
>
>Would I be playing with fire if I used dollar signs in identifiers?
>
>As to my rationale:  I am writing some C code to access variables in a legacy FORTRAN application, 
>and thought it would be "nice" to use the same variable names, e.g.:
>
>FORTRAN variable:  GAME$TIME
>C functions: 
>   get_game$time 
>   set_game$time
>(with appropriate provisions for FORTRAN's pass-by-reference).

n1570 section 6.4.2.1 describes the valid characters in an identifier.
The $ is not listed as one of the characters that must be allowed.  It
does fall into the category of "other implementation-defined
characters."

Thus a particular compiler is allowed to accept it and should document
that if it does so.  However, the $ cannot be the first character of
the identifier.

As for playing with fire, it depends on how important portability is
to your effort.

-- 
Remove del for email

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

#76587

Jay Braun <lyngwyst@gmail.com> wrote:

> I was just playing around in gcc, and named a variable game$time, 
> and a function set_game$time, and the compiler accepted it.  
> The small program linked and ran fine as well.  
> This required no special options.
 
(snip)

> As to my rationale:  I am writing some C code to access variables 
> in a legacy FORTRAN application, and thought it would be "nice" to 
> use the same variable names, e.g.:

The IBM OS/360 Fortran compilers allow $ as a letter. It comes after Z
such that one can

      IMPLICIT INTEGER (A-$)

I believe the VMS compilers do also, as many VMS routines callable
from Fortran have $ in their names.

Note that the OS/360 compilers don't use call by reference for
scalar variables, but call by value result.  That is, copy-in
and copy-out. 

VAX/VMS has %val, %ref, and %descr such that one can override
the default convention for each argument.

-- glen

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

#76603

On Thu, 19 Nov 2015 16:18:41 -0800 (PST), Jay Braun
<lyngwyst@gmail.com> wrote:

>I was just playing around in gcc, and named a variable game$time, and a function set_game$time, and the compiler accepted it.  The small program linked and ran fine as well.  This required no special options.
>
>Would I be playing with fire if I used dollar signs in identifiers?
>
>As to my rationale:  I am writing some C code to access variables in a legacy FORTRAN application, and thought it would be "nice" to use the same variable names, e.g.:
>
>FORTRAN variable:  GAME$TIME
>C functions: 
>   get_game$time 
>   set_game$time
>(with appropriate provisions for FORTRAN's pass-by-reference).
>
>Jay

It's accepted by Visual Studio's C compiler and by clang in
non-pedantic mode but I think I'd use underscores. After all, those
FORTRAN $'s are just $eparators after all.

get_game_time, set_game_time, meh....

GetGameTime, now you're onto something! :)

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

#76610

On 20/11/15 01:18, Jay Braun wrote:
> I was just playing around in gcc, and named a variable game$time, and a function set_game$time, and the compiler accepted it.  The small program linked and ran fine as well.  This required no special options.
> 
> Would I be playing with fire if I used dollar signs in identifiers?
> 
> As to my rationale:  I am writing some C code to access variables in a legacy FORTRAN application, and thought it would be "nice" to use the same variable names, e.g.:
> 
> FORTRAN variable:  GAME$TIME
> C functions: 
>    get_game$time 
>    set_game$time
> (with appropriate provisions for FORTRAN's pass-by-reference).
> 
> Jay
> 

From the gcc manual <https://gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html> :

 In GNU C, you may normally use dollar signs in identifier names. This
is because many traditional C implementations allow such identifiers.
However, dollar signs in identifiers are not supported on a few target
machines, typically because the target assembler does not allow them.

It is a gcc extension, and may or may not be accepted on other compilers
or gcc targets (or gcc with "pedantic" options).  It is entirely up to
you whether this is "playing with fire" or fine for your particular
application.

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

#76633

Thank you all for your input.

I have decided not to use the dollar signs.  Although it is unlikely that we will use a C compiler other than gcc, I cannot simply rule it out.  Also, at some point during development, compiling with -pedantic will be advisable (and some might justifiably say:  how about now and forever?), and I do not want to "clutter" the output with warnings about the $ character.

The FORTRAN code does, indeed, have a VMS heritage.  I am working with one of the original FORTRAN developers, and he is rather attached to those dollar signs because they are used specifically in variables that are part of shared memory (you might say they are "super" globals because several applications share them).   The variable names are otherwise case-insensitive.

I will not use underscores because I want the shared-memory variables to be immediately recognizable in the corresponding C code.  I am still leaning toward S or SS, with all other characters of these variable names being otherwise lower-case.

Best,
Jay

[toc] | [prev] | [standalone]

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

csiph-web