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" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Robert Dewar <dewar@adacore.com> writes:
>
> Gabriel Dos Reis wrote:
>> Robert Dewar <dewar@adacore.com> writes:
>> >"has the semantics that Gabriel Dos Reis wants" is not an evaluable
>> >predicate!
>> You completely missed the point, but I guess it is consistent with
>> your denying that there is any connection between C or C++ and
>> hardware.
>
> So, let's make this MUCH more specific. Gabriel, on the MIPS chip,
> do you think there is something in the definition of C that leads
> you to prefer wrap around semantics to trapping semantics?

 Gabriel> When it comes down for the compiler writer to chose
 Gabriel> something for undefined behaviour, it is hardly solely based
 Gabriel> on the C standard.  In fact, the C standard is of much less
 Gabriel> help because it gaves up. 

That's my reaction as well.  The standard says "do something".  The
compiler has to pick a "something".

If the choice is between trapping and wrap for MIPS arithmetic, I'd
choose wrap without a question.  The reason: my expectation is that,
in each place where the situation arises in the code created in our
team, wrap is the better answer.  Ideally the issue should not arise
-- if it's expected in the code, unsigned variables should be used or
the condition should be tested for explicitly.  But if that's missed,
I believe that wrapping will produce the "that's what I meant"
outcome, while an overflow trap will cause the system to malfunction
at the customer site.

   paul


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