5 ms·

From the coolgeek style guide: "Never use a signed type for a number that can never be negative" One of my pet peeves is developers using int (instead of unsi

From the coolgeek style guide: "Never use a signed type for a number that can never be negative" One of my pet peeves is developers using int (instead of unsigned ints) for primary keys in database tables.

tiglionabbit 12y ago
Unsigned ints aren't supported by any sql database.
- MrOrelliOReilly 12y ago
  Sarcasm? http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview...
  - esaym 12y ago
    His sarcasm is saying that mysql isn't a real database since it has data types that break the sql standard I guess. "SQL only specifies the integer types integer (or int), smallint, and bigint." http://www.postgresql.org/docs/9.3/static/datatype-numeric.html#DATATYPE-INT http://www.postgresql.org/docs/9.3/static/datatype-numeric.h...
  - tiglionabbit 12y ago
    Oh, I wasn't aware that there was a database that supported them. I mostly use postgres and sqlite, which both do not support them.
- deleted 12y ago
  [deleted]
sytelus 12y ago
+1. Everytime I see for(int i=0;...;i++) I wonder why we have developed this habit of defaulting all int as signed and consider uint as taboo (most coding guidelines asks not to use them unless "you know what you are doing"). Most of the time we use integers for counting and so uint should have been more natural. I did this in one of my libraries I was writing from scratch and I was happy for a while but then I got in to trouble because there is lot of code out there with interfaces expecting signed ints even though they should using uint. So ultimately the legacy forced me back to default again at using signed int.
- dkbrk 12y ago
  > Everytime I see for(int i=0;...;i++) In this case, it makes absolutely no difference at all. It could be argued that writing unsigned int would make the code slightly harder to read. That said, I like to use stdint.h and unint32_t would, I think, not have any drawbacks. > there is lot of code out there with interfaces expecting signed ints even though they should using uint That's not a good reason to not use unsigned integers, it's a zero-overhead cast from unsigned to signed (at the risk of overflowing into the negative).
  - Joky 12y ago
    It change the semantic on the loop bound, and thus what the compiler can/cannot do when optimizing the code. Using uint limits the optimizer...
    - detrino 12y ago
      Using int also limits the optimizer in some ways, for example division/modulo becomes more expensive. Every time I see someone mention the optimization argument for signed integers I ask for examples and I've yet see a good one.
- yongjik 12y ago
  Well, in my case, from time to time I have to do these stuff: for (int i = x.size() - 1; i >= 0; i--) ... for (int i = 0; i < x.size() - 1; i++) if (x[i] < x[i+1]) ... Both will blow up badly with unsigned ints. (Well, to be fair, both will blow up with signed ints if x.size() is greater than 2G, so it's a matter of expectations.)
  - Aldo_MX 12y ago
    for( size_t i = x.size(); i-- > 0; ) ...
    - delinka 12y ago
      Now i is no longer an index, it's index-plus-one.
10098 12y ago
yeah, some numbers can never be negative, but their difference can. and that's when it usually comes to bite me in the ass. i almost never use unsigned ints now.
- nly 12y ago
  I disagree, signed integer arithmetic in C and C++ is just toxic. Sure, if you need to compute the difference between two integers, which have both been pre-checked to lie between say -100 and +100, then fine, use signed ints... but for arbitrary input you need to do more work. There's example code on the CERT secure coding guidelines here (look under 'Substraction'): https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow https://www.securecoding.cert.org/confluence/display/seccode... Writing safe code to calculate the absolute difference between two unsigned integers is much less hairy: max(x,y) - min(y,x).
  - Joky 12y ago
    This is true for a signed addition as well, since you are not allowed to overflow.
  - rtpg 12y ago
    do these problems disappear with unsigned arithmetic?
  - sjolsen 12y ago
    All arithmetic in C and C++ is toxic. That's the reality of using bounded-precision types. Honestly, I wish they'd had the foresight not to use the traditional infix operators for built-in types; they practically beg programmers to implicitly treat built-in types like the mathematical types they very vaguely resemble. Really, working directly in fixed-precision arithmetic is absurd. In order to be able to rely on its correctness with any degree of certainty, you need to very carefully track each operation and its bounds, at which point you may as well have just used arbitrary-precision types, explicitly encoded your constraints, and had the compiler optimize things down to scalar types when possible, warning when not.
ANTSANTS 12y ago
Every time I see if (index < 0) { /* error */ } I die a little inside.
imanaccount247 12y ago
>One of my pet peeves is developers using int (instead of unsigned ints) for primary keys in database tables. Seems like a pretty ignorant pet peeve considering that's the only option for every database that doesn't auto-corrupt data.
einhverfr 12y ago
PostgreSQL doesn't give you an unsigned int option but if they did I wouldn't use it. Having a negative pkey space is actually useful. In LSMB we reserve all negative id's for test cases, which are guaranteed to roll back. This has a number of advantages including the ability to run a full test run on a production system without any possibility of leaving traces in the db.
TorKlingberg 12y ago
There are two schools of though here, and I am not convinced either is obviously right. 1) If you don't need negative numbers, use unsigned integers. 2) If you don't need the extra positive range of unsigned integers (or defined wrapping), use signed. You advocate (1), but C is generally based on (2), with the default int being signed, and many standard functions using plain int.
dragonwriter 12y ago
Most DBs don't support unsigned int [0] as a type (though its perfectly sensible to have a constraint that enforces >0.) [0] though several do support UUIDs, which are essentially unsigned 128-bit ints, and which (with a well-selected generation mechanism) are better as server-assigned surrogate keys than sequential integers, signed or unsigned, anyway.

tiglionabbit 12y ago

Unsigned ints aren't supported by any sql database.

MrOrelliOReilly 12y ago
Sarcasm? http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview...
- esaym 12y ago
  His sarcasm is saying that mysql isn't a real database since it has data types that break the sql standard I guess. "SQL only specifies the integer types integer (or int), smallint, and bigint." http://www.postgresql.org/docs/9.3/static/datatype-numeric.html#DATATYPE-INT http://www.postgresql.org/docs/9.3/static/datatype-numeric.h...
- tiglionabbit 12y ago
  Oh, I wasn't aware that there was a database that supported them. I mostly use postgres and sqlite, which both do not support them.
deleted 12y ago
[deleted]

sytelus 12y ago

+1. Everytime I see for(int i=0;...;i++) I wonder why we have developed this habit of defaulting all int as signed and consider uint as taboo (most coding guidelines asks not to use them unless "you know what you are doing"). Most of the time we use integers for counting and so uint should have been more natural. I did this in one of my libraries I was writing from scratch and I was happy for a while but then I got in to trouble because there is lot of code out there with interfaces expecting signed ints even though they should using uint. So ultimately the legacy forced me back to default again at using signed int.

dkbrk 12y ago
> Everytime I see for(int i=0;...;i++) In this case, it makes absolutely no difference at all. It could be argued that writing unsigned int would make the code slightly harder to read. That said, I like to use stdint.h and unint32_t would, I think, not have any drawbacks. > there is lot of code out there with interfaces expecting signed ints even though they should using uint That's not a good reason to not use unsigned integers, it's a zero-overhead cast from unsigned to signed (at the risk of overflowing into the negative).
- Joky 12y ago
  It change the semantic on the loop bound, and thus what the compiler can/cannot do when optimizing the code. Using uint limits the optimizer...
  - detrino 12y ago
    Using int also limits the optimizer in some ways, for example division/modulo becomes more expensive. Every time I see someone mention the optimization argument for signed integers I ask for examples and I've yet see a good one.
yongjik 12y ago
Well, in my case, from time to time I have to do these stuff: for (int i = x.size() - 1; i >= 0; i--) ... for (int i = 0; i < x.size() - 1; i++) if (x[i] < x[i+1]) ... Both will blow up badly with unsigned ints. (Well, to be fair, both will blow up with signed ints if x.size() is greater than 2G, so it's a matter of expectations.)
- Aldo_MX 12y ago
  for( size_t i = x.size(); i-- > 0; ) ...
  - delinka 12y ago
    Now i is no longer an index, it's index-plus-one.

10098 12y ago

yeah, some numbers can never be negative, but their difference can. and that's when it usually comes to bite me in the ass. i almost never use unsigned ints now.

nly 12y ago
I disagree, signed integer arithmetic in C and C++ is just toxic. Sure, if you need to compute the difference between two integers, which have both been pre-checked to lie between say -100 and +100, then fine, use signed ints... but for arbitrary input you need to do more work. There's example code on the CERT secure coding guidelines here (look under 'Substraction'): https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow https://www.securecoding.cert.org/confluence/display/seccode... Writing safe code to calculate the absolute difference between two unsigned integers is much less hairy: max(x,y) - min(y,x).
- Joky 12y ago
  This is true for a signed addition as well, since you are not allowed to overflow.
- rtpg 12y ago
  do these problems disappear with unsigned arithmetic?
- sjolsen 12y ago
  All arithmetic in C and C++ is toxic. That's the reality of using bounded-precision types. Honestly, I wish they'd had the foresight not to use the traditional infix operators for built-in types; they practically beg programmers to implicitly treat built-in types like the mathematical types they very vaguely resemble. Really, working directly in fixed-precision arithmetic is absurd. In order to be able to rely on its correctness with any degree of certainty, you need to very carefully track each operation and its bounds, at which point you may as well have just used arbitrary-precision types, explicitly encoded your constraints, and had the compiler optimize things down to scalar types when possible, warning when not.

ANTSANTS 12y ago

Every time I see if (index < 0) { /* error */ } I die a little inside.

imanaccount247 12y ago

>One of my pet peeves is developers using int (instead of unsigned ints) for primary keys in database tables. Seems like a pretty ignorant pet peeve considering that's the only option for every database that doesn't auto-corrupt data.

einhverfr 12y ago

PostgreSQL doesn't give you an unsigned int option but if they did I wouldn't use it. Having a negative pkey space is actually useful. In LSMB we reserve all negative id's for test cases, which are guaranteed to roll back. This has a number of advantages including the ability to run a full test run on a production system without any possibility of leaving traces in the db.

TorKlingberg 12y ago

There are two schools of though here, and I am not convinced either is obviously right. 1) If you don't need negative numbers, use unsigned integers. 2) If you don't need the extra positive range of unsigned integers (or defined wrapping), use signed. You advocate (1), but C is generally based on (2), with the default int being signed, and many standard functions using plain int.

dragonwriter 12y ago

Most DBs don't support unsigned int [0] as a type (though its perfectly sensible to have a constraint that enforces >0.) [0] though several do support UUIDs, which are essentially unsigned 128-bit ints, and which (with a well-selected generation mechanism) are better as server-assigned surrogate keys than sequential integers, signed or unsigned, anyway.