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 attachment 9547 [details] 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 attachment 9548 [details] Updated patch addressing joseph's comments This patch addresses josef's remarks. I'll upload the testsuite stuff separately when done.
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)
*** 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 attachment 13025 [details] 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
gdb: fix value_subscript when array upper bound is not known http://www-look-4.com/category/health/ Since commit 7c6f27129631 ("gdb: make get_discrete_bounds check for https://komiya-dental.com/category/crypto/ non-constant range bounds"), subscripting flexible array member fails: http://www.iu-bloomington.com/category/health/ struct no_size { https://waytowhatsnext.com/category/health/ int n; int items[]; }; http://www.wearelondonmade.com/category/health/ (gdb) p *ns $1 = {n = 3, items = 0x5555555592a4} (gdb) p ns->items[0] http://www.jopspeech.com/category/health/ Cannot access memory at address 0xfffe555b733a0164 (gdb) p *((int *) 0x5555555592a4) $2 = 101 <--- we would expect that http://joerg.li/category/health/ (gdb) p &ns->items[0] $3 = (int *) 0xfffe5559ee829a24 <--- wrong address http://connstr.net/category/health/ Since the flexible array member (items) has an unspecified size, the array type https://www.mktrade.fi/muottivalmistus created for it in the DWARF doesn't have dimensions (this is with gcc 9.3.0, http://embermanchester.uk/category/health/ Ubuntu 20.04): http://www.slipstone.co.uk/category/health/ 0x000000a4: DW_TAG_array_type DW_AT_type [DW_FORM_ref4] (0x00000038 "int") http://fishingnewsletters.co.uk/property/suluada/ DW_AT_sibling [DW_FORM_ref4] (0x000000b3) http://www.logoarts.co.uk/category/health/ 0x000000ad: DW_TAG_subrange_type DW_AT_type [DW_FORM_ref4] (0x00000031 "long unsigned int") http://www.acpirateradio.co.uk/category/health/ This causes GDB to create a range type (TYPE_CODE_RANGE) with a defined http://www.go-mk-websites.co.uk/health/tipaza-province/ constant low bound (dynamic _prop with kind PROP_CONST) and an undefined high bound (dynamic_prop with kind PROP_UNDEFINED). http://www.compilatori.com/category/health/ value_subscript gets both bounds of that range using get_discrete_bounds. Before commit 7c6f27129631, get_discrete_bounds http://www.mconstantine.co.uk/health/shanghai/ didn't check the kind of the dynamic_props and would just blindly read them as if they were PROP_CONST. https://www.webb-dev.co.uk/category/health/ It would return 0 for the high bound, because we zero-initialize the range_bounds structure. And it didn't really matter in this case, because the returned high bound wasn't used in the end.