On 10/13/07, Aleksey Cheusov <cheusov@tut.by> wrote:

> > Why should I have to go through my perfectly legitimate, legal C
> > program and change all references to the member of my struct that I
> > named "stat" just because the system headers wanted to rename a
> > function?
> Just because you ALREADY do this for many years. Actually EVERY macro
> definition in system headers is a BAD NAME.

Er, I do?  I write my app with a POSIX environment in mind, and when I
go to make it compile on NetBSD I make changes specifically for NetBSD
because it has not looked anything like a POSIX environment for years?

> Why I (as an application programmer) cannot use name, say, O_CREAT or
> EINTR or _LARGEFILE_SOURCE or something similar as a variable name,
> or function name or structure field etc. We all know - this
> is because they are macro definitions.

They're expected macro definitions, for several reasons:
* there's a naming convention that suggests capital letters for macro
definitions in the environments that contain the APIs you want to use
and therefore include the header files for
* O_CREAT and EINTR are both part of documented standard APIs
* _LARGEFILE_SOURCE is part of the implementation-reserved namespace
(underscore-capital) per ANSI/ISO C

Things like stat() are expected to be functions, for several reasons:
* there's a naming convention that suggests lowercase letters for
function identifiers in the environments that contain the APIs you
want to use and therefore include the header files for
* stat() is part of a documented standard API

As non-macro identifiers, they're subject to the usual scope and
context rules of the C language.  Changing such a definition into a
macro violates this.

> My suggestion ('#define stat stat_new' for "all other" compilers)
> just adds some new "bad names" to the existing big pile,
> NOT CREATE A NEW ONE.

Turning it into a macro makes it appear in scopes and contexts it did
not appear in before.  That is most definitely creation.  In the case
of stat(), it also redefines a standard API and makes it no longer
compliant.

Ignoring all of the theoretical reasons for this, in what possible
situation would this make sense from a practical standpoint?
Seriously, why would you want to break existing, portable and
otherwise perfectly happy applications on a source level for the sake
of *binary* compatibility?