This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: signed is undefined and has been since 1992 (in GCC)


Gabriel Dos Reis wrote:
Robert Dewar <dewar@adacore.com> writes:

| Olivier Galibert wrote:
| | > Calling a large part of the programs out there, including a non
| > negligible subpart of what I personally write either "blatantly buggy"
| > or "subtly-incorrect" is somewhat childish and insulting.
| | nope, I don't see it that way at all, this is just a statement of fact
| wrt the ISO standard. You may want C or C++ to be different from what
| it is, but the standard is widely accepted,


Those standards are widely accepted and so are very facts that they do
have connections with hardware. In fact, the respective committees
do work seriously on producing TRs for embedded systems and access to
hardware semantics.

I think you miss my point completely about hardware semantics. Let me try, though I am dubious it will be clear. The type int in C is not a hardware type, it is a type with properties defined by the standard. There is not necessarily any unique expectation on how this will be mapped to hardware, or what operations will be mapped. The only requirement is that the required semantics of int in the standard are preserved. For instance on the IBM mainframe one might use signed or unsigned operations to implement int operations. On the original MIPS one might use trapping or non-trapping arithmetic (either would be valid).

Yes, sometimes you need access to the hardware and need to control
exactly what is generated, but using int is not a mechanism that
provides any such guarantee.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]