__chip is evil

Peter da Silva peter at sugar.hackercorp.com
Sat Jan 13 01:46:05 AEST 1990


[ to comp.std.c folks: the discussion is the use of __id for nonportable
  qualifiers in declarations, like Microsoft does with __far. ]

> >Names beginning with two underscores or one underscore and an uppercase
> >letter are reserved to the implementation and may be used for any purpose
> >the implementer desires. Names beginning with one underscore and anything
> >but an uppercase letter may be used with file scope, but as externals are
> >reserved to the implementation.

> Section 4.1.2 of (my draft of) the ANSI standard states that "All external 
> identifiers that begin with an underscore and iether an upper-case letter
> or another underscore are reserved."  However, this simply means that these
> identifiers may be defined in standard header files, so the user should not
> use these names.

What it means is that a portable C program will not use those names for
any purpose. So it's safe to use them for a non-portable extension to the
language, because you will not break any portable programs.

> The standard does NOT say that the implementor may use these 
> identifiers to change the syntax of the C language, as you are doing when you
> introduce things like "__chip".  

And it doesn't say the implementor can't do this either.

In practice it means it's guaranteed to be safe to use them for
this purpose.

> >On the other hand #pragma is not allowed to change the semantics of a
> >program.

> I'm sorry, but I can't find this in the standard.  Can you direct me to 
> the appropriate paragraph?

Anyone in comp.std.c want to take a crack at it? It certainly gets brought
up often enough over there...

Certainly #pragma is a lot less elegant:

	static __chip ushort icon[4+ISIZE];

Or:

	#pragma chip(icon)
	static ushort icon[4+ISIZE];
-- 
Peter "Have you hugged your wolf today" da Silva <peter at sugar.hackercorp.com>
`-_-'
 'U`  "I haven't lost my mind, it's backed up on tape somewhere"



More information about the Comp.std.c mailing list