ObDisclaimer IANALL: I am not a language lawyer.

The short form of this is that I think ton's usage is fine.

I believe you are taking the standard too restrictively. If a C compiler were permitted to do wacky things to identifiers beginning with underscore, some other language would be needed to write a compliant libc.

Standardese is a very tricky language. It is difficult to sort out whether a requirement burdens the compiler developer or the user. In the draft version of the standard which you cite, I find two specific sections on allowed names for identifiers.

The fundamental one is §6.4.2.1. It says that a C identifier is made up of characters from [0-9_A-Za-z] with the initial character a non-digit from that set. Aside fron sigils, that is just like Perl. There are provisions to extend those names to wide characters. No provision exists in the standard for a compiler to treat differently a name which satisfies the definition of this section.

In the Library definition, §7.1.3 addresses reserved names. It seems to me that this section digests to "If you use my names, you must replicate my behavior". Undefined things happen if you define your own version of, say, malloc without conforming to the standard of behavior for that function. I an pretty sure that this section concerns what a programmer should expect of the language. Parts of it define conventions for identifier names in the library which I think any user library would be will-advised to follow. One of those is that identifiers beginning with a single underscore have file scope. Effectively, they are private methods..

The only other references to reserved identifiers in the draft standard concern keywords and required macros.

I'm pasting the two sections I discuss below. If someone can cite authority to confirm or deny my reading, I'd appreciate a reference.

Update: There is a companion document called Rationale for International Standard - Programming Languages - C. It documents the intent of the standards committee, and indicates that my notions about redefining libc functions were quite wrong. It tends to support wog's view, but I am still a little confused.

After Compline,
Zaxo

One of those is that identifiers beginning with a single underscore have file scope. Effectively, they are private methods..

Note that the standard is referring to header files. I think that this means a header file can do something like:

static int _foo(void) {
  /* ... do stuff ... */
}
[download]

or like

struct _bar {
  /* ... */
};
[download]

or like

static int _baz;
[download]

(update: Of course, it's important to note that these definitions could be referred to in macros so "overriding" them, even if possible, would make code below the overriding not work.) And when you use XS (or Inline since that uses XS) you are probably indirectly using standard header files. So, if you use these names and the header files, you can have a serious problem with duplicated function names and such.

Also note the first bullet under 7.1.3 paragraph(?) 1. "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use." This seems to mean that the C library may do weird things with those names. Take my C library implementation (glibc), for example. It defines numerous identifiers beginning with _IO for implementing stdio. Some of these even have external linkage, so if you use them with in a program, you could have conflicts linking in libc even if you never use the relevant header files. The standard seems to say the implementation need not worry about creating problems like this even for functions names like _Start or _Crypt.

-Ton
-----
Be bloody, bold, and resolute; laugh to scorn
The power of man...