Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop using 'short' for line and allocation sizes (2013)

git.kernel.org

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Stop using 'short' for line and allocation sizes (2013)

#31

Post by kzrdude »

jhallenworld wrote: post #20
marcoms wrote: post #14

Why not fixed-size ints - uint8_t, etc. from stdint.h? I've not been using C for a while, so I wonder what the viewpoints are regarding this.

You typically want to use the native integer size for something like this, for the code to be more portable. The native integer size should really be int, but it's not defined as such in the standard. My preference at the moment: off_t for file offsets ptrdiff_t for memory offsets (vs. size_t for unsigned) int for return flags A problem with this is that printf does not have sizes to match these.

There are whole languages that eschew this approach to portability. Rust is portable, and the language defines u8, u16, u32, u64 to exist, always.

See also https://forge.rust-lang.org/platform-support.html

Re: Stop using 'short' for line and allocation sizes (2013)

#32

Post by craftkiller »

accatyyc wrote: post #27
omtose wrote: post #24

Earlier quoted context omitted.

But then you get different behavior depending on the platform, which doesn't seem any more portable to me.

I'm in the "never use fixed size integers unless needed"-camp. For example, if you write code that's supposed to run on an 8-bit computer (something embedded) as well as your 64-bit desktop, it makes no sense to limit yourself. For example, say that you know that your number will be between 1-200, you could use uint8_t. But why not use int? It will be the native width of the platform, and likely to be faster. Calcula…

In that situation you could use uint_fast8_t which is the fastest uint of at least 8 bits.

Re: Stop using 'short' for line and allocation sizes (2013)

#33

Post by astrobe_ »

accatyyc wrote: post #27
omtose wrote: post #24

Earlier quoted context omitted.

But then you get different behavior depending on the platform, which doesn't seem any more portable to me.

I'm in the "never use fixed size integers unless needed"-camp. For example, if you write code that's supposed to run on an 8-bit computer (something embedded) as well as your 64-bit desktop, it makes no sense to limit yourself. For example, say that you know that your number will be between 1-200, you could use uint8_t. But why not use int? It will be the native width of the platform, and likely to be faster. Calcula…

I think it has more to do with memory use. See for instance the "65535 interfaces ought to be enough" thread. If you allocate a bazillion of a certain structure, then using the shortest allocation unit for its fields can make a difference, especially if you have a lot of these "small" fields.

Re: Stop using 'short' for line and allocation sizes (2013)

#34

Post by zeveb »

> And if you have a line that is longer than 2GB, you only have yourself to blame.

This is why I like languages like Lisp: by default, integers are only limited by the amount of memory available (as an example: (- (expt 2 1024) (expt 3 27)) → 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356321998626652229).

For efficiency one can of course limit things to fixnums, and in a kernel one would want to be careful not to let reading a file eat all memory — but that's all doable in a Lisp.

Re: Stop using 'short' for line and allocation sizes (2013)

#35

Post by hwh »

coldpie wrote: post #30
accatyyc wrote: post #27

Earlier quoted context omitted.

I'm in the "never use fixed size integers unless needed"-camp. For example, if you write code that's supposed to run on an 8-bit computer (something embedded) as well as your 64-bit desktop, it makes no sense to limit yourself. For example, say that you know that your number will be between 1-200, you could use uint8_t. But why not use int? It will be the native width of the platform, and likely to be faster. Calcula…

In practice, how much of my code is going to be run on an 8-bit CPU? Zero. I'd rather have the clarity and consistent behavior of explicitly typed ints than pre-optimize for something that will almost certainly never happen.

The C8051 architecture is still very much a thing in the MCU world. (As is Atmel AVR.)

Re: Stop using 'short' for line and allocation sizes (2013)

#36

Post by boomlinde »

accatyyc wrote: post #27
omtose wrote: post #24

Earlier quoted context omitted.

But then you get different behavior depending on the platform, which doesn't seem any more portable to me.

I'm in the "never use fixed size integers unless needed"-camp. For example, if you write code that's supposed to run on an 8-bit computer (something embedded) as well as your 64-bit desktop, it makes no sense to limit yourself. For example, say that you know that your number will be between 1-200, you could use uint8_t. But why not use int? It will be the native width of the platform, and likely to be faster. Calcula…

I have yet to use a C compiler for an 8-bit platform where int was the native size. sizeof (int) should be at least two chars. Using int instead of an uint8_t where you know its values to fall within those limits would be detrimental to performance in such cases.

That said, the code bases that target both 64- and 8-bit architectures probably aren't that many and both our points are insignificant in those other 99.9% of cases.

Re: Stop using 'short' for line and allocation sizes (2013)

#37

Post by datenwolf »

Sean1708 wrote: post #19
marcoms wrote: post #14

Why not fixed-size ints - uint8_t, etc. from stdint.h? I've not been using C for a while, so I wonder what the viewpoints are regarding this.

Fixed sized integers are useful in two situations (that I can think of); if you're interfacing with a language that doesn't use the same integer size as your C compiler, or if you're relying on integers being a certain width (maybe you're casting between integers and non-integers, or writing a certain number of bytes to a binary file). I doubt either of these situations come up when dealing with line sizes in a text…

And a third situation: Writing device drivers interfacing with hardware registers of specific sizes, although you should use `{u}int_least_t` for that, to give the compiler some leeway with alignment.

Re: Stop using 'short' for line and allocation sizes (2013)

#38

Post by prodigal_erik »

coldpie wrote: post #30
accatyyc wrote: post #27

Earlier quoted context omitted.

I'm in the "never use fixed size integers unless needed"-camp. For example, if you write code that's supposed to run on an 8-bit computer (something embedded) as well as your 64-bit desktop, it makes no sense to limit yourself. For example, say that you know that your number will be between 1-200, you could use uint8_t. But why not use int? It will be the native width of the platform, and likely to be faster. Calcula…

In practice, how much of my code is going to be run on an 8-bit CPU? Zero. I'd rather have the clarity and consistent behavior of explicitly typed ints than pre-optimize for something that will almost certainly never happen.

There were so many bad programmers who assumed 32 bit machines would last forever, that now we're stuck with compilers that don't default to 64 bit ints even building for 64 bit targets.

Re: Stop using 'short' for line and allocation sizes (2013)

#39

Post by prodigal_erik »

boomlinde wrote: post #36
accatyyc wrote: post #27

Earlier quoted context omitted.

I'm in the "never use fixed size integers unless needed"-camp. For example, if you write code that's supposed to run on an 8-bit computer (something embedded) as well as your 64-bit desktop, it makes no sense to limit yourself. For example, say that you know that your number will be between 1-200, you could use uint8_t. But why not use int? It will be the native width of the platform, and likely to be faster. Calcula…

I have yet to use a C compiler for an 8-bit platform where int was the native size. sizeof (int) should be at least two chars. Using int instead of an uint8_t where you know its values to fall within those limits would be detrimental to performance in such cases. That said, the code bases that target both 64- and 8-bit architectures probably aren't that many and both our points are insignificant in those other 99.9%…

The standard requires at least 16 bits in a short and 32 in a long. Oddly "all numeric types are 96 bits" would be fine.

Re: Stop using 'short' for line and allocation sizes (2013)

#40

Post by coldpie »

prodigal_erik wrote: post #38
coldpie wrote: post #30

Earlier quoted context omitted.

In practice, how much of my code is going to be run on an 8-bit CPU? Zero. I'd rather have the clarity and consistent behavior of explicitly typed ints than pre-optimize for something that will almost certainly never happen.

There were so many bad programmers who assumed 32 bit machines would last forever, that now we're stuck with compilers that don't default to 64 bit ints even building for 64 bit targets.

I don't see how explicit int sizes makes this any worse...
Post reply on HN