https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
Andrew Pinski changed:
What|Removed |Added
CC||vstinner at redhat dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #12 from gnzlbg ---
> I disagree. Once it's documented, people will rely on it and scream if it
> changes. Caveats about something maybe changing in future don't help. If it's
> documented to behave one way today, people will depend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #11 from Jonathan Wakely ---
I disagree. Once it's documented, people will rely on it and scream if it
changes. Caveats about something maybe changing in future don't help. If it's
documented to behave one way today, people will depen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #10 from gnzlbg ---
> But it constrains GCC in future, which leaving it unspecified does not.
Documenting whether GCC's C _Bool has the same valid and trap representations
as the target platform's ABI specifies is a trade-off: it doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #9 from Jonathan Wakely ---
But it constrains GCC in future, which leaving it unspecified does not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #8 from gnzlbg ---
> I think it should be sufficient to either mention which types have padding
> bits,
I am not sure. An intrinsic that tells me that _Bool has 7 padding bits does
not provide me with any new information. The C stan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #6 from gnzlbg ---
> Why do you need more than that?
I'm reading raw data from a file which supposedly contains _Bool's and I'd like
to validate it (the _Bools could have been written to the file by a program
compiled with a differen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #5 from Jonathan Wakely ---
You can copy the bit-pattern from any _Bool with true value, e.g. one
initialized with 'true' or an expression like '0==0'.
Why do you need more than that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #4 from gnzlbg ---
Without that information, how does one know which values can a valid program
write to a `_Bool` via a `char*`?
AFAIK the C standard guarantees that 0x0 must be a valid representation of
_Bool, but there are no gua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #3 from Jonathan Wakely ---
Yes, and an implementation is not required to document which object
representations are trap representations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #2 from gnzlbg ---
> Because (unsigned int)b is undefined otherwise.
AFAICT this is only undefined behavior iff `b` has a trap representation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
Jonathan Wakely changed:
What|Removed |Added
Keywords||documentation
--- Comment #1 from Jona
13 matches
Mail list logo
