Stupid question: why not unsigned int?
Stop using 'short' for line and allocation sizes (2013)
11–20 of 50 posts
Re: Stop using 'short' for line and allocation sizes (2013)
#12I wonder if uemacs is now that rarest of beasts, a piece of software that is actually _done_.
Edit: apparently it has no undo. The rules:
1) Linus does not make mistakes
2) In the event of Linus making a mistake, see rule 1
3) ...
4) git reset --hard HEAD
Re: Stop using 'short' for line and allocation sizes (2013)
#13This reminds me of my first job (in ECAD/EDA) where microemacs was part of the design process. We had microemacs "programs" (like macros) which post-processed the output from other CAD tools. Microemacs had an internal C-like (interpreted) language, and combined with the fact that it ran on DOS and Windows 3.1 made it sort of suitable for this. However I really hope those have been replaced now.
Re: Stop using 'short' for line and allocation sizes (2013)
#14Why 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.
Re: Stop using 'short' for line and allocation sizes (2013)
#15Stupid question: why not unsigned int?
Re: Stop using 'short' for line and allocation sizes (2013)
#16Well, it is called MicroEmacs for a reason ...
Re: Stop using 'short' for line and allocation sizes (2013)
#17Re: Stop using 'short' for line and allocation sizes (2013)
#18Stupid question: why not unsigned int?
You'll be comparing against a lot of other things like offsets that aren't naturally unsigned and having everything be of the same type just tends to reduce the number of potential corner cases.
And it will be a bit faster for certain weird architectures since the overflow behavior of an unsigned is prescribed but signed overflow is undefined. But I really doubt anybody cares about that here.
Re: Stop using 'short' for line and allocation sizes (2013)
#19Why 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 editor.
Re: Stop using 'short' for line and allocation sizes (2013)
#20Why 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.