Subject: Re: Compiling NetBSD with another compiler.
To: None <email@example.com>
From: Trevor Talbot <firstname.lastname@example.org>
Date: 10/13/2007 08:06:53
On 10/13/07, Aleksey Cheusov <email@example.com> 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
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?