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: Do C++ signed types have modulo semantics?







Paul Koning <pkoning@equallogic.com> wrote on 27/06/2005 17:47:12:

> >>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:
>
>  >> And all useful programs we write rely on undefined behaviour of
>  >> one sort or the other, starting with GCC.  In the case of
>
>  Nathan> They do? I thought they usually relied on implementation
>  Nathan> defined, documented extensions or were part of the
>  Nathan> implementation.  Now I'm sure you'll prove me wrong in some
>  Nathan> way or other, but please stick to the point -- do real
>  Nathan> important programs that must not break and cannot be changed
>  Nathan> rely on signed modulo behaviour?
>
> I'm sure they do.  Obviously they should not, since the standard says
> not to.  But most programmers are not language lawyers.  Most
> programmers "know" that arithmetic is modulo wordsize.  And those few
> who know the right answer (only unsigned arithmetic is modulo) will
> from time to time slip up and omit the "unsigned" keyword in their
> declarations.
>
> So I can't point to a direct example but I am certain such examples
> exist.
>


Please, these arguments have been beaten to death in previous
threads. We don't want to slip to long discussions on the merits
of either one of the decisions, again.

So from what I understand, gcc does something very inconsistent,
and this has to be fixed. Anyway, as someone mentioned, it is not
clear if the compiler can have a reasonable support for modulo on
x86 without a penalty (the MIN_INT/-1 case). What it means that
numeric_limits<signed>::is_modulo was inconsistent with gcc for
all older gcc/libstdc++ versions.

It is now PR 22200, the potentially long debate can move there.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

  Michael


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