Ooooh, this one's good - http://c-faq.com/struct/retcrash.html
I think I’ve done that one.
Comp.lang.c Frequently Asked Questions
31–40 of 56 posts
Re: Comp.lang.c Frequently Asked Questions
#32Re: Comp.lang.c Frequently Asked Questions
#33Earlier quoted context omitted.
As a fellow student of "why is this named that, what does this name mean" I have found that asking about counterfactuals is rarely satisfying. Naming stuff is hard and the question assumed a level of intent that I think is rarely present. Asking "how did this thing get named that" works out better, cause it seems that occasionally gets written down.
My point was that it seems more likely that size_t was created to represent sizes than to represent indexes. I don't disagree that size_t is an appropriate type for indexes, but I don't think indexes are literally the reason it was created.
It's named for sizeof, a C operator which returns a positive integer but annoyingly the core C language itself doesn't define what the type of that integer is, the standard library does though, naming it size_t
Now, sizeof does measure the size of things, but, one of the obvious sizes you can measure is an array†, and that's definitely also the maximum index value for the array, so I do think it's fair to say that's (part of) literally why size_t exists.
† One of C's treacherous footguns. In the scope where the array was defined it's an array, and sizeof(array) tells you how big that array is. But, passed as a parameter it becomes a pointer and sizeof(resulting_pointer) is the size of the pointer, not the array :(
Re: Comp.lang.c Frequently Asked Questions
#34Earlier quoted context omitted.
Why isn't it called index_t then?
Because C doesn't really have indexes, it has pointers and offsets. offset_t would make more sense than index_t.
There's also ssize_t and ptrdiff_t for offsets that might be negative. Use is pretty nuanced, read the docs before using, etc.
Re: Comp.lang.c Frequently Asked Questions
#35The maintainer, Steve Summit, lives up to his name. He’s self-described as “five foot twenty-two”.
Re: Comp.lang.c Frequently Asked Questions
#36> Most programs do not need precise control over these sizes; many programs that do try to achieve this control would be better off if they didn't. Interesting that modern languages like rust, go, and zig all lean towards using integer types with well defined sizes. I think that we've learned that the less exact definitions in c can cause problems. For example, if you develope and test in an environment where int is…
Technically the wrong type was used if no less than 32 bits was desired. A common failing when you learn a compiler/platform or two instead of the language. Such has been called many things, among them 'everything is a VAX'.
Re: Comp.lang.c Frequently Asked Questions
#37Newsgroup FAQs are a goldmine. I still find myself referring to the comp.graphics.algorithms FAQ repeatedly: http://www.faqs.org/faqs/graphics/algorithms-faq/
Does anyone know what happened to rtfm.mit.edu? It was, quite recently, an FTP site where all the Usenet FAQs were archived.
Might gave something to do with Firefox removing FTP support.
Re: Comp.lang.c Frequently Asked Questions
#38Re: Comp.lang.c Frequently Asked Questions
#39> Most programs do not need precise control over these sizes; many programs that do try to achieve this control would be better off if they didn't. Interesting that modern languages like rust, go, and zig all lean towards using integer types with well defined sizes. I think that we've learned that the less exact definitions in c can cause problems. For example, if you develope and test in an environment where int is…
Modern C (from C99 onward) introduces a few families of sized types -- [u]int[_least|_fast|][8|16|32|64]_t. The non-least-or-fast types are not guaranteed to exist (e.g., int8_t is optional because implementation may be unreasonable on a 24-bit DSP with no sub-word operations), but the _least and _fast types are generally what you want anyway, unless you're relying on unsigned overflow behavior. In my experience, mod…
> bit-packing with int_fast8_t allows you to represent
I assume you meant `int_least8_t`?
Re: Comp.lang.c Frequently Asked Questions
#40Earlier quoted context omitted.
Because C doesn't really have indexes, it has pointers and offsets. offset_t would make more sense than index_t.
There's also ssize_t and ptrdiff_t for offsets that might be negative. Use is pretty nuanced, read the docs before using, etc.
And intptr_t and uintptr_t for results of computations resulting in pointers. Sadly C's type system isn't really powerful enough to properly take advantage of these.