🚀 go-pugleaf

Guy Harris gave good points, below.  So good, in fact, that we'll do it.
We'll implement '$' in identifiers, with the one proviso that they
are not the first character in the identifier.  There are releases in
the works now that won't have the feature yet, but eventually it will
be available on all Sequent C compilers and language tools.

We *do* want to make it easy to port to Sequent systems. That's why
I was concerned about keeping to AT&T's implementation:  One man's
extension is another man's bane.  But ANSI explicitly calling it out
as a common extension that does not break conformity convinced us.

Guy: Thanks for speaking up!

- Dorsey Drane


In article <2456@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>It's not a bug - it's due to Sequent's C compiler being derived from
>>AT&T's C compiler, which does not accept '$' as a valid character in an
>>identifier.  Sequent is trying to be compatible with AT&T, so we have
>>no plans to change this in the near future.
>
>Berkeley's compiler is derived from AT&T's C compiler, but it accepts
>"$" as a valid character in an identifier.  I don't see the harm in
>extending Sequent's compiler; Sequent's C library presumably contains
>"lstat()", but AT&T's doesn't (yet, anyway - S5R4 will).
>
>>(It's invalid in ANSI C too.)
>
>But specifically called out in A6.5.2 as a "common extension"; you may
>have to provide a flag to disable it in order to have your compiler be a
>legal ANSI C one, but you don't have to leave it out of your compiler
>entirely.
>
>Nevertheless, it's wise to avoid "$" in identifiers when writing code
>for UNIX systems, since not all compilers support it.