Whats the legal state of @ character in identifiers?

[scholz.lothar]

I know that some compilers accept it.

But was it ever part in some C (88/90/99) standard?

Can somebody tell me which compilers do support this character?

 

[Keith Thompson]

Please put the question in the body of the message, not just in the
subject header.

The question was:

Whats the legal state of @ character in identifiers?

I know that some compilers accept it.

Really? I know some compilers accept $ in identifiers, but I've never
heard of one that accepts @.

But was it ever part in some C (88/90/99) standard?

The @ character is not part of the basic character set, so
a compiler isn't even required to accept it in a source file.

In C89/C90, the syntax for identifiers permits only letters, digits
and underscores. An implementation could permit additional characters
as an extension, but it would still have to emit a diagnostic if you
use anything other than the standard characters.

In C99, the syntax was extended to allow "other implementation-defined
characters", so a C99 compiler may, but need not, permit @ in
identifiers.

Can somebody tell me which compilers do support this character?

None that I know of. Why do you ask? Do you have a need to use @
characters in identifiers?

 

[luserXtrog]

Please put the question in the body of the message, not just in the
subject header.

I second that. It makes jocular responses more difficult.

The question was:

Whats the legal state of @ character in identifiers?

Probation, with court-ordered reform classes.

 

[scholz.lothar]

Please put the question in the body of the message, not just in the
subject header.

The question was:

Whats the legal state of @ character in identifiers?

Sorry had a very very long day hacking PHP so I made a mistake.
The question is:
Whats the legal state of $ character in identifiers?

 

[bert]

Sorry had a very very long day hacking PHP so  I made a mistake.
The question is:
Whats the legal state of $ character in identifiers?

But it's interesting that around 1970, identifiers in
IBM 360 Assembler were allowed to include @ # and $
(that's commercial-at, hash, and dollar) along with
letters and non-leading digits. So the original
question was actually quite a reasonable one.
--

 

[Bartc]

(e-mail address removed) said:


The same as for @

That's a shame. $ could have replaced _ for prefixes and suffixes, and
wouldn't have been practically invisible.

 

[CBFalconer]

(e-mail address removed) wrote:

... snip ...


But it's interesting that around 1970, identifiers in IBM 360
Assembler were allowed to include @ # and $ (that's commercial-
at, hash, and dollar) along with letters and non-leading digits.
So the original question was actually quite a reasonable one.

Assembly code is another language (or one of many). C is written
according to the C standard (or should be).

Some useful references about the C standard:
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> (C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2> (pre-C99)
<http://www.dinkumware.com/c99.aspx> (C-library}

 

[luserXtrog]

You don't think he knew that you self opinionated fool? And yet you harp
on about Pascal? You find it unreasonable that someones knowledge of
another language might influence their thoughts on C?

Sigh.
It'd be nice if you could wrap identifiers in a cartouche. Then you
could use any characters you like.

 

[Kenny McCormack]

Assembly code is another language (or one of many). C is written
according to the C standard (or should be).

It's times like this that make me wonder where modern life would be - without
CBF.

And, given CBF's age, this is something we, as a society, really should
be concerned about. Plans need to be made.

 

[lawrence.jones]

But it's interesting that around 1970, identifiers in
IBM 360 Assembler were allowed to include @ # and $
(that's commercial-at, hash, and dollar) along with
letters and non-leading digits.

And I seem to remember that some mainframe C compilers allowed them as
well (as an extension) for interlanguage compatibility.