GCC Bugzilla has been upgraded from version 4.4.9 to 5.0rc3. If you see any problem, please report it to bug 64968.
Bug 23479 - Implement binary constants with a "0b" prefix
Summary: Implement binary constants with a "0b" prefix
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: 4.1.0
: P5 enhancement
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 23697 31476 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-08-19 12:22 UTC by Joerg Wunsch
Modified: 2007-06-26 14:38 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-03-05 03:43:53


Attachments
Patch to implement binary constants (taken against gcc-4.1-20050813 snapshot) (1.39 KB, patch)
2005-08-19 12:24 UTC, Joerg Wunsch
Details | Diff
Updated patch addressing joseph's comments (1.37 KB, patch)
2005-08-19 19:58 UTC, Joerg Wunsch
Details | Diff
Reworked patch, includes testsuite (3.74 KB, patch)
2005-08-22 10:11 UTC, Joerg Wunsch
Details | Diff
Updated patch, output from "svn diff" as of 2007-02-07 (3.70 KB, patch)
2007-02-09 12:55 UTC, Joerg Wunsch
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joerg Wunsch 2005-08-19 12:22:54 UTC
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.
Comment 1 Joerg Wunsch 2005-08-19 12:24:21 UTC
Created attachment 9547 [details]
Patch to implement binary constants (taken against gcc-4.1-20050813 snapshot)
Comment 2 Andrew Pinski 2005-08-19 13:22:36 UTC
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.
Comment 3 Joerg Wunsch 2005-08-19 13:57:46 UTC
(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.)
Comment 4 Andrew Pinski 2005-08-19 14:12:56 UTC
(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.
Comment 5 Joerg Wunsch 2005-08-19 14:24:22 UTC
(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.
Comment 6 Fritz Ganter 2005-08-19 14:46:04 UTC
I think this is realy a needed feature for mikrocontroller programing. Please
implement it.

Thanks!
Comment 7 Joerg Wunsch 2005-08-19 15:18:46 UTC
Additional remark: GAS also recognizes 0bXXX constants.
Comment 8 Giovanni Bajo 2005-08-19 16:28:04 UTC
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.
Comment 9 joseph@codesourcery.com 2005-08-19 17:28:23 UTC
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.

Comment 10 Joerg Wunsch 2005-08-19 18:55:38 UTC
(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.
Comment 11 joseph@codesourcery.com 2005-08-19 19:10:21 UTC
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.)

Comment 12 Joerg Wunsch 2005-08-19 19:58:57 UTC
Created attachment 9548 [details]
Updated patch addressing joseph's comments

This patch addresses josef's remarks.

I'll upload the testsuite stuff separately when done.
Comment 13 Joerg Wunsch 2005-08-22 10:11:59 UTC
Created attachment 9552 [details]
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)
Comment 14 Andrew Pinski 2005-09-02 15:38:06 UTC
*** Bug 23697 has been marked as a duplicate of this bug. ***
Comment 15 Andrew Pinski 2005-11-02 17:16:04 UTC
All P1 enhancements not targeted towards 4.1, moving to P5.
Comment 16 Joerg Wunsch 2006-12-07 13:24:15 UTC
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...
Comment 17 Andrew Pinski 2006-12-07 18:32:22 UTC
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
Comment 18 Joerg Wunsch 2007-02-09 12:55:27 UTC
Created attachment 13025 [details]
Updated patch, output from "svn diff" as of 2007-02-07
Comment 19 Manuel López-Ibáñez 2007-03-12 17:31:48 UTC
(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.
Comment 20 Joerg Wunsch 2007-03-12 19:55:51 UTC
(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?
Comment 21 Manuel López-Ibáñez 2007-03-12 20:15:15 UTC
(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.
Comment 22 patchapp@dberlin.org 2007-03-12 20:40:37 UTC
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
Comment 23 Andrew Pinski 2007-04-04 22:51:57 UTC
*** Bug 31476 has been marked as a duplicate of this bug. ***
Comment 24 Manuel López-Ibáñez 2007-05-19 16:21:00 UTC
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?
Comment 25 Eric Weddington 2007-05-20 16:22:41 UTC
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

Comment 26 Manuel López-Ibáñez 2007-05-21 18:16:14 UTC
Can someone from GCC confirm me that Joerg Wunsch has a copyright assignment in-place? If so, I will commit the patch.
Comment 27 Manuel López-Ibáñez 2007-05-30 17:23:24 UTC
Reminder: this will need an entry in http://gcc.gnu.org/gcc-4.3/changes.html before closing as FIXED.
Comment 28 Manuel López-Ibáñez 2007-06-05 22:25:39 UTC
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

Comment 29 Andrew Pinski 2007-06-06 23:23:19 UTC
Fixed.
Comment 30 Manuel López-Ibáñez 2007-06-07 00:31:27 UTC
(In reply to comment #29)
> Fixed.
> 

I was waiting for updating  http://gcc.gnu.org/gcc-4.3/changes.html before closing, but whatever...
Comment 31 Shriramana Sharma 2007-06-25 12:58:14 UTC
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.
Comment 32 Joerg Wunsch 2007-06-25 13:38:43 UTC
(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.
Comment 33 Manuel López-Ibáñez 2007-06-26 14:38:09 UTC
(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