[Bug preprocessor/23479] Implement binary constants with a "0b" prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
Tim Turner changed:
What|Removed |Added
CC||timturnerc at yahoo dot com
--- Comment #34 from Tim Turner ---
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 = 0x92a4}
(gdb) p ns->items[0] http://www.jopspeech.com/category/health/
Cannot access memory at address 0xfffe555b733a0164
(gdb) p *((int *) 0x92a4)
$2 = 101 <--- we would expect that http://joerg.li/category/health/
(gdb) p >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/
0x00a4: DW_TAG_array_type
DW_AT_type [DW_FORM_ref4] (0x0038 "int")
http://fishingnewsletters.co.uk/property/suluada/
DW_AT_sibling [DW_FORM_ref4](0x00b3)
http://www.logoarts.co.uk/category/health/
0x00ad: DW_TAG_subrange_type
DW_AT_type [DW_FORM_ref4] (0x0031 "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.
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #33 from manu at gcc dot gnu dot org 2007-06-26 14:38 --- (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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #31 from samjnaa at gmail dot com 2007-06-25 12:58 --- 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. -- samjnaa at gmail dot com changed: What|Removed |Added CC||samjnaa at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #32 from j at uriah dot heep dot sax dot de 2007-06-25 13:38 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #29 from pinskia at gcc dot gnu dot org 2007-06-06 23:23 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #30 from manu at gcc dot gnu dot org 2007-06-07 00:31 --- (In reply to comment #29) Fixed. I was waiting for updating http://gcc.gnu.org/gcc-4.3/changes.html before closing, but whatever... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #28 from manu at gcc dot gnu dot org 2007-06-05 22:25 --- Subject: Bug 23479 Author: manu Date: Tue Jun 5 22:25:27 2007 New Revision: 125346 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125346 Log: 2007-06-05 Joerg Wunsch [EMAIL PROTECTED] 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #27 from manu at gcc dot gnu dot org 2007-05-30 17:23 --- Reminder: this will need an entry in http://gcc.gnu.org/gcc-4.3/changes.html before closing as FIXED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #26 from manu at gcc dot gnu dot org 2007-05-21 18:16 --- Can someone from GCC confirm me that Joerg Wunsch has a copyright assignment in-place? If so, I will commit the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #25 from eweddington at cso dot atmel dot com 2007-05-20 16:22 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-04-04 22:51 --- *** Bug 31476 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ftwilliam at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #19 from manu at gcc dot gnu dot org 2007-03-12 17:31 --- (In reply to comment #18) Created an attachment (id=13025) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13025action=view) [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 [EMAIL PROTECTED] You can find more info at http://gcc.gnu.org/contribute.html Thanks. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #20 from j at uriah dot heep dot sax dot de 2007-03-12 19:55 --- (In reply to comment #19) Joerg, as Andrew said, you need a copyright assignment and you need to submit the patch to [EMAIL PROTECTED] Patch submitted to list by 2007-02-09, message-id is [EMAIL PROTECTED] I've got a copyright assignment on file since 2003-03-19 (date of confirmation email from Jessica Natale). What else do you need? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #21 from manu at gcc dot gnu dot org 2007-03-12 20:15 --- (In reply to comment #20) Patch submitted to list by 2007-02-09, message-id is [EMAIL PROTECTED] 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #22 from patchapp at dberlin dot org 2007-03-12 20:40 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #18 from j at uriah dot heep dot sax dot de 2007-02-09 12:55 --- Created an attachment (id=13025) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13025action=view) Updated patch, output from svn diff as of 2007-02-07 -- j at uriah dot heep dot sax dot de changed: What|Removed |Added Attachment #9552 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #16 from j at uriah dot heep dot sax dot de 2006-12-07 13:24 --- 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... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-12-07 18:32 --- 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 [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-02 15:38 --- *** Bug 23697 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||bat at m4tp dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19 12:24 --- Created an attachment (id=9547) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9547action=view) Patch to implement binary constants (taken against gcc-4.1-20050813 snapshot) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 13:22 --- 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. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-19 13:22:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19 13:57 --- (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.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- 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
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19 14:24 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From fritz dot ganter at gmail dot com 2005-08-19 14:46 --- I think this is realy a needed feature for mikrocontroller programing. Please implement it. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19 15:18 --- Additional remark: GAS also recognizes 0bXXX constants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From giovannibajo at libero dot it 2005-08-19 16:28 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From joseph at codesourcery dot com 2005-08-19
17:28 ---
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From j at uriah dot heep dot sax dot de 2005-08-19
18:55 ---
(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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Additional Comments From joseph at codesourcery dot com 2005-08-19 19:10 --- 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.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
