andrewn@syma.sussex.ac.uk (Andrew D Nimmo) (09/12/89)
On compiling a C program on our Symmetry, the compiler complained that '$' was an illegal character. Compilers on other machines have never given me this problem - is it a bug or do we have to live with it? -- Andrew D. Nimmo, VLSI and Graphics Research Group, EAPS II, University of Sussex, Falmer, BRIGHTON, East Sussex, BN1 9Qt TEL: +44 273 606755 x 2617 EMAIL: (JANET) andrewn@syma.sussex.ac.uk | (UUCP) ...mcsun!ukc!syma!andrewn
drane@sequent.UUCP (Dorsey Drane) (09/14/89)
In article <1355@syma.sussex.ac.uk> andrewn@syma.UUCP (Andrew D Nimmo) writes: > > On compiling a C program on our Symmetry, the compiler > complained that '$' was an illegal character. Compilers on other > machines have never given me this problem - is it a bug or do we have to > live with it? >-- > Andrew D. Nimmo, VLSI and Graphics Research Group, > EAPS II, University of Sussex, Falmer, BRIGHTON, East Sussex, BN1 9Qt > TEL: +44 273 606755 x 2617 > EMAIL: (JANET) andrewn@syma.sussex.ac.uk | (UUCP) ...mcsun!ukc!syma!andrewn 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. (It's invalid in ANSI C too.) My guess is that C compilers that do accept '$' in identifiers have been so extended because they had a need to interface C routines with routines written on other languages. E.g., DEC's VAX systems make heavy use of $ in system routines, and I can see that they would find such an extension handy. If you have such a need, you might do what I did when I needed a C function that had a '%' in its name: I compiled the C function with -SO, which gave me the assembly language output on stdout, and piped that through sed which changed the name to what I wanted, and then piped that into the assembler. cc -SO -O func.c | sed /func_name/s//%&/ | as -o func.o This put my '%' as the leading char of the name, where I needed it. You could do the same with a '$'. (Of course a '$' can't be the leading char in an identifier as a leading '$' has a different meaning to the assembler.) This kludge will let you change a valid C name to the required name. Finally, if you really need this enhancement, please file a mailbug specifying that it's important to you to be able to compile such identifiers. It could be that there's a growing source of C code coming from non-Unix systems that have this need, and Sequent should provide the ability. (If we do so, I'm sure we'd enable the feature only when specified by some new command-line option.) Good luck, - Dorsey
guy@auspex.auspex.com (Guy Harris) (09/17/89)
>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.
drane@sequent.UUCP (Dorsey Drane) (09/23/89)
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.