GCC Bugzilla Bug 23479

It is suggested to implement binary contants as a GCC extension to the
language.  This is a frequently requested item in microcontroller
environments, and several other compilers already implement it.  The
commonly used prefix is "0b", as this does not contradict the standard
C syntax, and allows for an easy private extension to the language.

Several distributions of AVR-GCC (including the popular "WinAVR" one,
and the FreeBSD port of AVR-GCC) have been shipping with this
extension for quite some time, and general user feedback about it is
positive.

Created an attachment (id=9547) [edit]
Patch to implement binary constants (taken against gcc-4.1-20050813 snapshot)

Confirmed, note I would actually disable binary constants by default instead of
what the patch currently 
does, pedwarns about them.  Or maybe pedwarn about them by default with an
option to turn off that 
pedwarn.

(In reply to comment #2)

> Confirmed, note I would actually disable binary constants by default
> instead of what the patch currently does, pedwarns about them.

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.

I simply followed the established practice in my suggested
implementation.

> Or maybe pedwarn about them by default with an option to turn off
> that pedwarn.

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.  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.  (That should cover any case of __attribute__,
__inline__, __asm__ and such being implicitly used by operating system
headers, etc.)

(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.

(In reply to comment #4)

> 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.

OK, I accept that.

But then, I'm still in favour of collecting all ``dangerous''
extension, as suggested by the -Wgcc-extensions option, instead
of suddenly implying a -half-pedantic behaviour which then can
be turned off by a -not-so-pedantic option.  That would IMHO
violate POLA.

> 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.

That raises the question: how would one propose adding this extension
to the standard itself?  As I said, a number of (commercial) compilers
implement it as well already right now.

I think this is realy a needed feature for mikrocontroller programing. Please
implement it.

Thanks!

Additional remark: GAS also recognizes 0bXXX constants.

If there was a voting system in this Bugzilla, I'd vote for this. It's a very 
useful feature in embedded programming. I also believe that it could be enabled 
by default in GNU C, since it's really easy and well-defined.

Subject: Re:  New: Implement binary constants with
 a "0b" prefix

The patch does not document how the types of binary constants are 
determined.  I suppose the rules are the same as for octal and hexadecimal 
constants, but the documentation needs to say so.

The patch does not document the 0B prefix, although the code accepts it.

The documentation should say @samp{0}, @samp{1}, @samp{0b}.

You can't write diagnostics like

+    SYNTAX_ERROR3 ("invalid digit \"%c\" in %s constant", '0' + max_digit,
+		   radix == 2? "binary": "octal");

because this doesn't work with i18n.  You need to have two separate 
strings, each of them a complete sentence, rather than building up 
sentences from fragments.  If you use a conditional expression, check 
whether you need to mark the strings with N_ to get them in cpplib.pot.

It's not clear how you ensure that someone can't write floating point 
numbers as e.g. 0b1e2 (the check for floats says in part "radix <= 10 && 
(c == 'e' || c == 'E')" which would allow binary, being designed to allow 
8 (0123e4 being decimal but looking like octal at first) and 10).

The patch is missing testcases.  They should include that the values of 
these constants (both 0b and 0B) are correct (both in the compiler and in 
preprocessor conditionals), that the types follow the correct rules (which 
need to be documented; see c99-intconst-1.c for how to test constant type 
rules), that you can't write floating point numbers such as 0b1e2 or 
0b1p3, and that these constants receive warnings with -pedantic and errors 
with -pedantic-errors (for both C and C++, and for both the compiler and 
the preprocessor).

If you don't already have a copyright assignment on file you may need to 
get one.  See <http://gcc.gnu.org/contribute.html>.  As new features can't 
go in until 4.1 has branched there should be plenty of time to do so 
before a complete patch (submitted to gcc-patches) can be considered.

(In reply to comment #9)

Thank you very much for the useful comments.

> The patch does not document how the types of binary constants are
> determined.  I suppose the rules are the same as for octal and
> hexadecimal constants, but the documentation needs to say so.

Yes, I simply didn't think about that.

> The patch does not document the 0B prefix, although the code accepts
> it.

Hmm, I thought that was obvious...  OK.

> The documentation should say @samp{0}, @samp{1}, @samp{0b}.

OK.

> You can't write diagnostics like ...
> because this doesn't work with i18n.

Ah, well, understood.

> It's not clear how you ensure that someone can't write floating
> point numbers as e.g. 0b1e2 (the check for floats says in part
> "radix <= 10 && (c == 'e' || c == 'E')" which would allow binary,
> being designed to allow 8 (0123e4 being decimal but looking like
> octal at first) and 10).

I didn't realize the same parser would also parse FP numbers.  Sure,
FP numbers are allowed to start with 0x these days...  I'll see how to
resolve that.

> The patch is missing testcases.

Is there a tutorial anywhere how to run testcases?

> If you don't already have a copyright assignment on file ...

I do have.

Subject: Re:  Implement binary constants with a "0b"
 prefix

On Fri, 19 Aug 2005, j at uriah dot heep dot sax dot de wrote:

> > The patch is missing testcases.
> 
> Is there a tutorial anywhere how to run testcases?

http://gcc.gnu.org/wiki/HowToPrepareATestcase

For the testing that constants have the correct type, start with the macro 
definitions from c99-instconst-1.c (CHECK_HEX_CONST can be converted to 
what you need by changing 0x and 0X to 0b and 0B) but replace the function 
foo with one checking the binary versions of the hex constants presently 
checked.  (The macros dealing with decimal constants can be removed as 
irrelevant for binary.)

Created an attachment (id=9548) [edit]
Updated patch addressing joseph's comments

This patch addresses josef's remarks.

I'll upload the testsuite stuff separately when done.

Created an attachment (id=9552) [edit]
Reworked patch, includes testsuite

OK, thanks for the hint about the testsuite...	It turned out the integer
overflow checking also needed a patch.

The attached patch now fixes this, and includes a testsuite consisting of the
following parts:

. test acceptance of all required 0b constants in gnu99 mode, including
  preprocessor test
. test -pedantic warnings
. test -pedantic-errors fails
. test other error messages (0b used for FP constant, 0b followed by illegal
  digit)

*** Bug 23697 has been marked as a duplicate of this bug. ***

All P1 enhancements not targeted towards 4.1, moving to P5.

The last update of this has been about a year ago, and talked about it not
being done before GCC 4.1...  Now that GCC 4.2 has been branched off, is there
any news on integrating that patch?

There's one important political aspect of it.  In the C99 rationale, the
following statement has been recorded:

``A proposal to add binary constants was rejected due to lack of precedent and
insufficient utility.''

Apparently, there *is* sufficient utility, considered among almost all
programmers doing embedded systems.  Many other compilers for embedded
systems have already implemented that extension, but they are probably
below the radar of the C99 committee.  Now, if GCC were to adopt this
extension, the "lack of precedence" statement would be no longer true when
the committee were about meeting next time...

There are two things need for this patch to go forward.
First you need a copyright assignment on file.
Second you need to post the patch to gcc-patches@gcc.gnu.org

Created an attachment (id=13025) [edit]
Updated patch, output from "svn diff" as of 2007-02-07

(In reply to comment #18)
> Created an attachment (id=13025) [edit]
> Updated patch, output from "svn diff" as of 2007-02-07
> 

Joerg, as Andrew said, you need a copyright assignment and you need to submit
the patch to gcc-patches@gcc.gnu.org. You can find more info at
http://gcc.gnu.org/contribute.html

Thanks.

(In reply to comment #19)

> Joerg, as Andrew said, you need a copyright assignment and you need to submit
> the patch to gcc-patches@gcc.gnu.org.

Patch submitted to list by 2007-02-09, message-id is
<20070209170816.GZ38723@uriah.heep.sax.de>

I've got a copyright assignment on file since 2003-03-19 (date of
confirmation email from Jessica Natale).

What else do you need?

(In reply to comment #20)
> Patch submitted to list by 2007-02-09, message-id is
> <20070209170816.GZ38723@uriah.heep.sax.de>
> 
> I've got a copyright assignment on file since 2003-03-19 (date of
> confirmation email from Jessica Natale).
> 
> What else do you need?
> 

Unfortunately, I think your patch got missed. You need to ping the patch from
time to time (every 2 weeks or so). See the archives of gcc-patches for
examples. Some people check the patch queue http://www.dberlin.org/patches but
adding the patch to the tracker does not ensure that it will be reviewed. You
still need to ping the relevant maintainers.

Subject: Bug number preprocessor/23479

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00810.html

*** Bug 31476 has been marked as a duplicate of this bug. ***

Joerg,

any news about this? I cannot find the patch in the patch tracker. It seems it
was approved by Mark Mitchell
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01495.html

Have you committed it?

Subject: RE:  Implement binary constants with a "0b"
 prefix



> 
> ------- Comment #24 from manu at gcc dot gnu dot org  
> 2007-05-19 16:21 -------
> Joerg,
> 
> any news about this? I cannot find the patch in the patch 
> tracker. It seems it
> was approved by Mark Mitchell
> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01495.html
> 
> Have you committed it?

I work with Joerg on the AVR toolchain and we work at the same company. He's
on vacation right now.

AFAIK, Joerg does not have write priviledges on GCC (you can verify this
with the MAINTAINERS file).

So, yes, it seems like the patch was approved by Mark. No, the patch has not
been committed yet.

The patch is attached to the bug report:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479>
And the patch was submitted to the patches ml:
<http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00810.html>

Can somebody commit this patch?

Thanks,
Eric Weddington

Can someone from GCC confirm me that Joerg Wunsch has a copyright assignment
in-place? If so, I will commit the patch.

Reminder: this will need an entry in http://gcc.gnu.org/gcc-4.3/changes.html
before closing as FIXED.

Subject: Bug 23479

Author: manu
Date: Tue Jun  5 22:25:27 2007
New Revision: 125346

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125346
Log:
2007-06-05  Joerg Wunsch  <j.gnu@uriah.heep.sax.de>

        PR preprocessor/23479
gcc/
        * doc/extend.texi: Document the 0b-prefixed binary integer
        constant extension.

libcpp/
        * expr.c (cpp_classify_number): Implement 0b-prefixed binary
        integer constants.
        (append_digit): Likewise.
        * include/cpplib.h: Add CPP_N_BINARY, to be used for 0b-prefixed
        binary integer constants.

testsuite/
        * testsuite/gcc.dg/binary-constants-1.c: Add test suites for
        the 0b-prefixed binary integer constants.
        * testsuite/gcc.dg/binary-constants-2.c: Ditto.
        * testsuite/gcc.dg/binary-constants-3.c: Ditto.
        * testsuite/gcc.dg/binary-constants-4.c: Ditto.

Added:
    trunk/gcc/testsuite/gcc.dg/binary-constants-1.c
    trunk/gcc/testsuite/gcc.dg/binary-constants-2.c
    trunk/gcc/testsuite/gcc.dg/binary-constants-3.c
    trunk/gcc/testsuite/gcc.dg/binary-constants-4.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/extend.texi
    trunk/gcc/testsuite/ChangeLog
    trunk/libcpp/ChangeLog
    trunk/libcpp/expr.c
    trunk/libcpp/include/cpplib.h

Fixed.

(In reply to comment #29)
> Fixed.
> 

I was waiting for updating  http://gcc.gnu.org/gcc-4.3/changes.html before
closing, but whatever...

Just mentioning: printf() and std::cout need to be updated if the binary values
are also to be *output*. Any ideas on how or where that is to be done?

Thanks.

(In reply to comment #31)

> Just mentioning: printf() and std::cout need to be updated if the
> binary values are also to be *output*. Any ideas on how or where
> that is to be done?

That would be a library issue, and thus completely out of scope for
the compiler.

I'm afraid you completely misunderstood the subject of this
feature/enhancement: it is *not* about run-time processing of 0b
binary constants (neither for input nor output), but to allow a
*compile-time* specification of such constants.

(In reply to comment #31)
> Just mentioning: printf() and std::cout need to be updated if the binary values
> are also to be *output*. Any ideas on how or where that is to be done?
> 

As Joerg pointed out, that is a library issue. Moreover, this is unrelated to
this bug since you wouldn't need to have binary constants in the compiler in
order to print integer constants in binary. That is, I guess you want something
like:

printf("%b", 2); /* Output: 10 */

but as the example shows you don't need binary constants to be able to print
integers in binary.

What this bug is about (and will appear in GCC 4.3) is to be able to write the
following:

printf("%d", 0b10); /* Output: 2 */

So if what you want is the first thing, then you need to write your own printf
or contact GNU libc developers: http://www.gnu.org/software/libc/bugs.html