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

#109526

On Monday, May 8, 2017 at 2:53:34 AM UTC-7, Bart wrote:
> 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.

Standard way to handle 
    when 'A'..'Z','a'..'z','$','_' then
is to map the characters through a character array to two
characters and do an "if" on the result
    if (map[x] == 'a') ....

Obviously generalizable to more cases.

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

#109529

On 08/05/2017 19:47, David Kleinecke wrote:
> On Monday, May 8, 2017 at 2:53:34 AM UTC-7, Bart wrote:
>> 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.
>
> Standard way to handle
>     when 'A'..'Z','a'..'z','$','_' then
> is to map the characters through a character array to two
> characters and do an "if" on the result
>     if (map[x] == 'a') ....
>
> Obviously generalizable to more cases.
>

Not sure what you mean here.

But that second sequence is actually used to initialise a character map 
(char[256]), where each element is 1 if the corresponding character 
belongs in the set, 0 otherwise).

Testing such a map was a fast way, after a particular kind of token was 
identified, to probe for the end of the token:

   while (alphamap[*lxsptr++]);

If you mean using a map to classify sets of characters as alpha etc, 
then that's a technique I used in the 80s; I like a change...

-- 
bartc

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

#108460

In article <odmu6j$mg$1@dont-email.me>, Noob  <root@127.0.0.1> 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?
>
>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.)

Or maybe you should see a doctor.  (They have drugs for that now)

-- 
The plural of "anecdote" is _not_ "data".

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

#108474

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

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


Back then, you'd often not have a $ on many nominally "ASCII" systems,
since it was often replaced with a local symbol.  For example, many
British systems would have displayed that codepoint as a pounds
sterling sign.

One of the motivations for trigraphs was that some ("ASCII") systems
replaced brace and bracket characters with things like accented
characters.  At least the latter was not that common when doing
programming on such systems (and that particular application of
trigraphs was mostly used on EBCDIC systems).

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

#108448

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> maximus fl <ajones2600@gmail.com> writes:
>>int A$ = 10;
>
> 6.4.2 Identifiers
>
> 6.4.2.1 General
>
> Syntax
>
> 1 
>
> identifier:
> identifier-nondigit
> identifier identifier-nondigit
> identifier digit
>
> identifier-nondigit:
> nondigit
> universal-character-name
> other implementation-defined characters
> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

https://gcc.gnu.org/onlinedocs/gcc-6.3.0/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.

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

#108449

On Monday, April 24, 2017 at 8:26:45 PM UTC-4, Keith Thompson wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> > maximus fl <ajones2600@gmail.com> writes:
> >>int A$ = 10;
> >
> > 6.4.2 Identifiers
> >
> > 6.4.2.1 General
> >
> > Syntax
> >
> > 1 
> >
> > identifier:
> > identifier-nondigit
> > identifier identifier-nondigit
> > identifier digit
> >
> > identifier-nondigit:
> > nondigit
> > universal-character-name
> > other implementation-defined characters
> > ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> 
> https://gcc.gnu.org/onlinedocs/gcc-6.3.0/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.
> 
> -- 
> 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"

Thanks! This answers my question. Thanks for the GNU C reference.

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

#108478

maximus fl <ajones2600@gmail.com> writes:
>This is odd. gcc and clang before compile this program with no problems, an=
>d the prpgram runs just fine. I can't find a reason why.
>
>#include <stdio.h>
>
>int main(void) {
>
>   int A$ =3D 10;
>   int $B =3D 25;
>   int z =3D $B;=20
>   int c =3D 0;
>
>   $B =3D A$ + $B;
>   printf("A$ is: %i and $B is: %i and the sum is %i\n", A$, z, $B);
>   c =3D A$ +$B;
>   printf("c :=3D> %i\n", c);
>
>   return 0;
>}
>
>This works, but the c standard says this variable name should not be valid

Most C compilers accept $ in variable names.   All the VMS
system calls have $ in the names, for example (e.g. SYS$QIOW)
which may be part of the reason that so many compilers support it.

[toc] | [prev] | [standalone]

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

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

csiph-web