4 ms·

Another problem with the C code, which is perhaps even more subtle, is the usage of `int` for the length, capacity, and loop index. On 64-bit platforms these va

Another problem with the C code, which is perhaps even more subtle, is the usage of `int` for the length, capacity, and loop index. On 64-bit platforms these variables will overflow for very large arrays, which will likely break the entire implementation. The call to `malloc()` should give a signed-to-unsigned conversion warning which will hint about this, but unfortunately many people ignore integer warnings. Incidentally, this could also be caught by compiling with `-ftrapv` or `-fsanitize=undefined`, but this problem is only triggered in a rather extreme corner case that is unlikely to be exposed during testing. The correct integer type to use is `size_t`, which is guaranteed to be large enough to hold the size of any object in memory.

jstimpfle 9y ago
Personally I'm going the other direction. I use int for anything unless there's a serious need to make an exception. The amount of complexity introduced by using a zoo of integer sizes and signedness is unmanageable to me. There is no point in measuring array sizes in size_t. I don't make bigger allocations >2G. (At some point this assumption will probably break and I will have to re-think my approach. Shouldn't we all move to 64-bit integers by default already?)
- burntsushi 9y ago
  > There is no point to measure array sizes in size_t. I don't make bigger allocations >2G. I think almost every Rust program I've ever published regularly encounters files greater than 2GB (even 4GB), and if I had used C and its `int` type everywhere, I'd be in for a very very bad time. This of course doesn't mean I am allocating >2G on the heap, but I might memory map the file. Or there might be some other counter (line counter? byte counter?) where using `int` would just fail. There are even some alternatives to my tools written in C, and either they or their dependencies use `int` instead of `size_t`, and that leads to actual bugs their end users hit in exactly the cases where files are greater than 2GB. Getting integer sizes right is important, and it's not just in cases where you're putting >2G on the heap.
  - jstimpfle 9y ago
    > Getting integer sizes right is important, and it's not just in cases where you're putting >2G on the heap. I prioritize on getting their values right :-). So far I have not encountered bugs due to my pretty uniform usage of int. But if they had to deal with allocations >2G, my programs would just die. Yup, I make some exceptions as well, for example to measure time in microseconds, or to measure the size of very large streams. And of course I try to assert that all downcasts to int are valid, and that my integer operations don't overflow, etc. (why do CPUs still not support overflow exceptions?) I'm pretty sure we could get rid of quite some historical baggage in terms of integer types. For example, I'm currently working on a network module, and there is a type socklen_t which is to indicate the size of a socket structure. I might be missing something, but to me there is no good reason not to use simply int.
    - deleted 9y ago
      [deleted]

jstimpfle 9y ago

Personally I'm going the other direction. I use int for anything unless there's a serious need to make an exception. The amount of complexity introduced by using a zoo of integer sizes and signedness is unmanageable to me. There is no point in measuring array sizes in size_t. I don't make bigger allocations >2G. (At some point this assumption will probably break and I will have to re-think my approach. Shouldn't we all move to 64-bit integers by default already?)

burntsushi 9y ago
> There is no point to measure array sizes in size_t. I don't make bigger allocations >2G. I think almost every Rust program I've ever published regularly encounters files greater than 2GB (even 4GB), and if I had used C and its `int` type everywhere, I'd be in for a very very bad time. This of course doesn't mean I am allocating >2G on the heap, but I might memory map the file. Or there might be some other counter (line counter? byte counter?) where using `int` would just fail. There are even some alternatives to my tools written in C, and either they or their dependencies use `int` instead of `size_t`, and that leads to actual bugs their end users hit in exactly the cases where files are greater than 2GB. Getting integer sizes right is important, and it's not just in cases where you're putting >2G on the heap.
- jstimpfle 9y ago
  > Getting integer sizes right is important, and it's not just in cases where you're putting >2G on the heap. I prioritize on getting their values right :-). So far I have not encountered bugs due to my pretty uniform usage of int. But if they had to deal with allocations >2G, my programs would just die. Yup, I make some exceptions as well, for example to measure time in microseconds, or to measure the size of very large streams. And of course I try to assert that all downcasts to int are valid, and that my integer operations don't overflow, etc. (why do CPUs still not support overflow exceptions?) I'm pretty sure we could get rid of quite some historical baggage in terms of integer types. For example, I'm currently working on a network module, and there is a type socklen_t which is to indicate the size of a socket structure. I might be missing something, but to me there is no good reason not to use simply int.
  - deleted 9y ago
    [deleted]