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

41–50 of 50 posts

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

#41

Post by emsy »

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.

This will bite you if your code depends on int being 32 bit (for example if you depend on overflows or use asm). If your code explicitly uses an int32, this will always be true.

Silently increasing the size of an int is more likely to break things than it'll be helpful. If you really want an int to be 32 bit on a 32 bit machine and 64 bit on a 64 bit machine, make it explicit (e.g. intptr_t for pointers)

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

#42

Post by jstelly »

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…

There are many cases where using fixed size types can save a significant amount of memory (and your application is constrained by memory on some platform) or CPU time (design to minimize cache misses happens all the time in high performance applications like games).

Neither of these situations is happening in a text editor application though.

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

#43

Post by saurik »

jerf wrote: post #23
Kretiini wrote: post #11

Stupid question: why not unsigned int?

In my experience with languages that have both signed and unsigned ints, but have no overflow or underflow protection (which is pretty much all of them), you really want to use signed ints so that you can write assertions that numbers you expect to be positive are positive. You can't do that with unsigned ints since they are all by definition >= 0, so you always end up finding bugs where suddenly you've got MAX_INT -…

You still have to deal with wraparound all the way off the bottom of the negative end (which is absolutely possible: these kinds of massive additions and subtractions have been the basis of various exploits, often involving array math), and so you need to solve that problem anyway; but now you also have to constantly verify the number is positive, and it is extremely common to see checks in the wild which only verify that a sized index is less than some maximum :/.

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

#44

Post by saurik »

This is actually an unfortunate patch... it rearranged lines for no particular reason, and scrambled the comments without updating them: they were multi-line sentences and referenced each other's positions.

The original code:

 	struct line *b_dotp;	/* Link to "." struct line structure   */
 	short b_doto;		/* Offset of "." in above struct line  */
 	struct line *b_markp;	/* The same as the above two,   */
 	short b_marko;		/* but for the "mark"           */
 	struct line *b_linep;	/* Link to the header struct line      */
The new code:

  	struct line *b_dotp;	/* Link to "." struct line structure   */
 	struct line *b_markp;	/* The same as the above two,   */
 	struct line *b_linep;	/* Link to the header struct line      */
 	int b_doto;		/* Offset of "." in above struct line  */
 	int b_marko;		/* but for the "mark"           */
 	int b_mode;		/* editor mode of this buffer   */

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

#45

Post by Someone »

saurik wrote: post #44

This is actually an unfortunate patch... it rearranged lines for no particular reason, and scrambled the comments without updating them: they were multi-line sentences and referenced each other's positions. The original code: struct line *b_dotp; /* Link to "." struct line structure */ short b_doto; /* Offset of "." in above struct line */ struct line *b_markp; /* The same as the above two, */ short b_marko; /* but f…

Even though Linus wrote "it probably made sense 30 years ago as a way to save a tiny amount of memory" the rearrangement probably is to optimize structure layout.

If a pointer is 8 bytes and an int 4, the old structure typically (this is compiler dependent) would be 40 bytes, the new one 36.

But yes, that should have been two commits, and he should have updated the comments.

This also is somewhat of an argument for giving the compiler the freedom to choose filed order, as the order that is optimal for memory usage isn't the best for human understanding.

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

#46

Post by saurik »

Someone wrote: post #45
saurik wrote: post #44

This is actually an unfortunate patch... it rearranged lines for no particular reason, and scrambled the comments without updating them: they were multi-line sentences and referenced each other's positions. The original code: struct line *b_dotp; /* Link to "." struct line structure */ short b_doto; /* Offset of "." in above struct line */ struct line *b_markp; /* The same as the above two, */ short b_marko; /* but f…

Even though Linus wrote "it probably made sense 30 years ago as a way to save a tiny amount of memory" the rearrangement probably is to optimize structure layout. If a pointer is 8 bytes and an int 4, the old structure typically (this is compiler dependent) would be 40 bytes, the new one 36. But yes, that should have been two commits, and he should have updated the comments. This also is somewhat of an argument for g…

> If a pointer is 8 bytes and an int 4, the old structure typically (this is compiler dependent) would be 40 bytes, the new one 36.

Ah: I actually did work out the alignment math, as I considered that as a reason to reorder the fields, but I was hoping that the goal would have been only to do that if the change was making the struct even larger (which it doesn't) and failed to think about a 64-bit computer :(. However, I personally don't consider "save four bytes per window" to be a particularly compelling reason to rearrange fields (which seem to have been put in that order more for semantic purposes than compression), and yeah: the real issue is that this is all in one patch and scrambled the comments :(. It is essentially at best a an unrelated optimization that seemingly didn't even notice how it broke the comments. (BTW: an issue with having a compiler decide the field order is that you then make separate compilation and sharing structures between libraries really really hard.)

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

#47

Post by [deleted] »

Someone wrote: post #45
saurik wrote: post #44

This is actually an unfortunate patch... it rearranged lines for no particular reason, and scrambled the comments without updating them: they were multi-line sentences and referenced each other's positions. The original code: struct line *b_dotp; /* Link to "." struct line structure */ short b_doto; /* Offset of "." in above struct line */ struct line *b_markp; /* The same as the above two, */ short b_marko; /* but f…

Even though Linus wrote "it probably made sense 30 years ago as a way to save a tiny amount of memory" the rearrangement probably is to optimize structure layout. If a pointer is 8 bytes and an int 4, the old structure typically (this is compiler dependent) would be 40 bytes, the new one 36. But yes, that should have been two commits, and he should have updated the comments. This also is somewhat of an argument for g…

[deleted]

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

#48

Post by Someone »

saurik wrote: post #46
Someone wrote: post #45

Earlier quoted context omitted.

Even though Linus wrote "it probably made sense 30 years ago as a way to save a tiny amount of memory" the rearrangement probably is to optimize structure layout. If a pointer is 8 bytes and an int 4, the old structure typically (this is compiler dependent) would be 40 bytes, the new one 36. But yes, that should have been two commits, and he should have updated the comments. This also is somewhat of an argument for g…

> If a pointer is 8 bytes and an int 4, the old structure typically (this is compiler dependent) would be 40 bytes, the new one 36. Ah: I actually did work out the alignment math, as I considered that as a reason to reorder the fields, but I was hoping that the goal would have been only to do that if the change was making the struct even larger (which it doesn't) and failed to think about a 64-bit computer :(. Howeve…

It would be simple to either have compiler directives that control structure layout or (a bit more limited) some way to indicate that the compiler should keep your field order (just as, in Pascal, the 'PACKED' modifier to a struct directs the compiler to omit most padding)

Also, since Linus worked on kernel code a lot, that reordering probably was like a knee reflex; it didn't involve his brain. His brain wrote that we shouldn't be bothered by this in an editor, but his spine made the edit, anyways, and, apparently, his spine doesn't read comments.

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

#49

Post by beached_whale »

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 also int_least8_t or what ever size and signedness too. or int_fast8_t. You explicitly state I want at least 8 bits or I want at least 8 bits but whatever is fastest.

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

#50

Post by jwilk »

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.

For ptrdiff_t: "%td"

For size_t: "%zu"

There's no format for off_t, though. The best you can do is to typecast it to intmax_t, and then use "%jd".

Post reply on HN