Live data from Hacker News

Comp.lang.c Frequently Asked Questions

c-faq.com

51–56 of 56 posts

Re: Comp.lang.c Frequently Asked Questions

#51

Earlier quoted context omitted.

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…

>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

Make sure to be careful and realize that sizeof my_array returns the number of bytes that my_array uses, not the number of elements. An array of 10 ints likely has sizeof == 40, while indexing past 9 would be undefined behavior.

Re: Comp.lang.c Frequently Asked Questions

#52

Earlier quoted context omitted.

Ah thanks, that's what I was thinking. But somehow I got caught up in unaligned cacheline accesses, which are much larger than 32-bits. It's early where I am. :)

I mean there are 4 different concepts at play here: Unaligned memory access, types generally have an alignment which is the same as their length and structs have the alignment of their largest member because many architectures get quite cross with unaligned access e.g. trying to load a 32b integer from memory to register while it's not aligned to 32b, this is where compilers will pad structures to ensure everything i…

cache alignment also gets stupid complicated when you add in what kind of malloc you use, c.f. google's tcmalloc: https://github.com/google/tcmalloc

Re: Comp.lang.c Frequently Asked Questions

#53
post #51

Earlier quoted context omitted.

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…

>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 Make sure to be careful and realize that sizeof my_array returns the number of bytes that my_array uses, not the number of elements. An array of 10 ints likely has sizeof == 40, while indexing past 9 would be undefined behavior.

Excellent point, that largely contradicts my earlier position in fact. I was thinking of an array of chars and should have considered that's only a special case.

Re: Comp.lang.c Frequently Asked Questions

#54
post #28

Earlier quoted context omitted.

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.

Connecting with an FTP client shows that the connection times out.

Re: Comp.lang.c Frequently Asked Questions

#55
post #42
post #39

Earlier quoted context omitted.

> bit-packing with int_fast8_t allows you to represent I assume you meant `int_least8_t`?

Either is valid, but int_fast8_t is more meaningful, in my mind. Using an int_fast8_t encourages the compiler to use the fastest representation, except when explicitly bit-packed. When the value is pulled into a register it's probably not going to matter (unless the compiler is doing something quite silly with regards to handling unsigned overflow for a uint*), but it means that spilling it to the stack, etc, will pr…

> And of course we have bit packing when we need to pack more efficiently than reasonable; bit-packing with *int_fast8_t* allows you to represent "I need this to take exactly 8 bits of memory, whatever it costs compute-wise, because I'm basically filling memory with these."

AFAICT, "int_fast8_t" is generally typedef to "int", and "int_least8_t" is generally typedef to "char", which conflicts with "I need this to take exactly 8 bits of memory, whatever it costs compute-wise, because I'm basically filling memory with these."

Re: Comp.lang.c Frequently Asked Questions

#56
post #55
post #42

Earlier quoted context omitted.

Either is valid, but int_fast8_t is more meaningful, in my mind. Using an int_fast8_t encourages the compiler to use the fastest representation, except when explicitly bit-packed. When the value is pulled into a register it's probably not going to matter (unless the compiler is doing something quite silly with regards to handling unsigned overflow for a uint*), but it means that spilling it to the stack, etc, will pr…

> And of course we have bit packing when we need to pack more efficiently than reasonable; bit-packing with *int_fast8_t* allows you to represent "I need this to take exactly 8 bits of memory, whatever it costs compute-wise, because I'm basically filling memory with these." AFAICT, "int_fast8_t" is generally typedef to "int", and "int_least8_t" is generally typedef to "char", which conflicts with "I need this to take…

Right. The context here is when combined with bit-packing, i.e. `int_fast8_t : 8` vs `int_least8_t : 8` in a struct or similar.
Post reply on HN