Hi, Le 07.02.2010 19:04, Florian Köberle a écrit : > Hello gentildemon > > I too have thought about doing something against the unsigned integers > in wormux. > Unsigned integers in C++ are a bad thing in my opinion for the following > reasons: > 1. They overflow easily. > 2. Their overflow behaviour is not defined: Different compilers or > different optimization flags may cause different results. [2] > 3. There is no good reason for using them: When you fear that a signed > 32 bit integer may be to small for a value then using a unsigned 32 bit > integer will do not much good. Instead it's often better to use a signed > 64 bit integer. For example does System.currentTimeMillis() of the Java > API return a long (64 bit) instead of a unsigned 32 bit integer like the > SDL API. > > An alternative to your idea would be to use signed integers at all > places where currently unsigned integers get used. If necessary we can > use a 64 bit integer. The idea of your friend isn't bad either. When you > have time I suggest that we have a chat session about it. >
I mostly agree that unsigned integers have no real interest and that long should be used instead if we fear that signed int may be to small. Anyway, using 'unsigned int' is indication for the programmer that this variable should never be negative. I have thought about "typedef uint int" (or a simple 'sed s/uint/int/g'), but the problem is that we will not be able to detect bad logic where the code relies on the fact that the number is positive. I'm pretty sure that most of the overflows we have comes from subtraction of a higher number. As soon as we store it in an unsigned int, that means the code makes wrong assumption. I guess that some of the unsigned int could already converted to signed int, but there is a lot! (git grep uint | wc -l returns me 1306). Regards, Matt (gentildemon) > Best regards, > Florian Köberle > > [2] http://www.airs.com/blog/archives/120 > > Matthieu Fertré wrote: > >> Hi, >> >> I'm quite fed up with integer overflow/wrap. Unsigned integers in >> particular are particularly dangerous [1]. Last week, I have again fixed >> a bug related to unsigned int wrap (uint length = 0 - 4, the result of >> this operation gives a very big number, not zero nor -4) >> >> One friend suggests me to implement an UnsignedInt class, redefining >> operators, so that it ensures that unsigned never begans negative and >> launches assertion failure when it happens. Then, we just have to >> "typedef uint UnsignedInt" instead of "typedef uint unsigned int". >> >> Are you ok with that ? (The class may optionnally be used only in debug >> mode) >> >> Regards, >> >> Matt (gentildemon) >> >> >> [1] >> https://www.securecoding.cert.org/confluence/display/cplusplus/INT30-CPP.+Ensure+that+unsigned+integer+operations+do+not+wrap >> >> >> _______________________________________________ >> Wormux-dev mailing list >> Wormux-dev@gna.org >> https://mail.gna.org/listinfo/wormux-dev >> >> >> >> > > _______________________________________________ > Wormux-dev mailing list > Wormux-dev@gna.org > https://mail.gna.org/listinfo/wormux-dev > _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
