[Bug preprocessor/23479] Implement binary constants with a "0b" prefix

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-19 14:12 -------
(In reply to comment #3)
> Curious: why?
> 
> There are more than two dozen GCC language extensions enabled by
> default, most of them would allow GCC to accept a program that will
> not be accepted by a different compiler.  E.g., I'd consider most
> targets silently accepting dollar signs in identifiers to be at least
> similarly or even more dangerous.

The main reason is because adding extensions are bad now adays.  We are removing extensions which 
are not used that much and hard to keep working.  Even though this extension is very small and well 
defined, it is just another extension.

> That would equally apply to about all extension.  I'd rather suggest
> to have something like -Wgcc-extensions, and perhaps include that by
> default into -Wall.  This would make anyone aware of the GCC
> extensions used in their applications.  
>Differentiating between
> ``good'' and ``not so good'' GCC extensions seems to be a bit strange
> to me.  

It is not strange to me and many other GCC developers because well some are more defined than 
others.  And having hardly used extension warn by default will cause people to think about a better way 
to write them code and more portable.

> Maybe two levels of GCC extension warnings would be
> appropriate, so any extension keywords starting with two underscores
> would only be warned at an additional level (-Wall-gcc-extensions, or
> perhaps only by -pedantic), as these have been used by the developers
> deliberately.  

__ is reserved  for the implemention by the standard so we should not warn about those use at all.
The use of __inline__ is also like using __extension__ inline and such so marking the line as using 
extensions.  -pedantic does not warn them currently because of that.

If somehow this gets added to a C standard, then the whole point of warning goes away with 
-std=future, just like long long and C99.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479