User-namespace pre#defines - new approach

[Christopher Faylor]

On Mon, Apr 15, 2002 at 12:48:12PM -0700, Zack Weinberg wrote:
>On Mon, Apr 15, 2002 at 03:06:54PM -0400, Christopher Faylor wrote:
>> 
>> We don't have an option as far as Windows is concerned.  We really do
>> need to define WINNT, _cdecl, and _stdcall if we want to continue
>> to build Windows apps.
>
>This conflicts with the sanity check I put in gcc.c to prevent specs
>from defining any user-namespace macros at all.  VxWorks also has
>problems with this -- since I'm in the middle of updating that GCC
>port anyway I was just going to fix their headers, but we don't have
>that option with Windows.
>
>I'm now thinking that a different approach would be better.  Suppose I
>add a new command line option (--deprecated-macro, say; it needn't be
>short) to cpplib, and change most of the existing -D[A-Za-z] instances
>to use it instead.  The effect of --deprecated-macro FOO is to cause
>cpplib to define FOO, __FOO, and __FOO__; FOO gets left out if
>-ansi/-std=c*, and if it is defined, using it generates a warning.
>
>This (a) leaves specs free to define user-namespace macros if they
>have no choice; (b) should be easier to validate the patch; (c) still
>allows us to get rid of the %{!ansi:%{!std=c*:...yadda...}} nonsense
>in a lot of specs, often incorrectly, and the %p/%P nonsense in gcc.c;
>(d) offers a gentler transition than the original patch.
>
>Reactions?

Forcing all of those behaviors would pollute the Windows name space
since it doesn't, AFAIK, rely on __WINNT__ at all but it does define
WINNT.  This doesn't accommodate macros like _ctype, either.  Or isn't
that an issue?

Also, calling it "deprecated" makes it sound like it will go away
someday.  While I'd like Windows to go away someday, I don't know how
likely it will be that the macros that Windows (regrettably) used will
ever completely disappear.

cgf