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

How to find size of an array in C without sizeof

arjunsreedharan.org

Post reply on HN
Print view View original

171–180 of 212 posts

Re: How to find size of an array in C without sizeof

#171

Post by int_19h »

feelix wrote: post #167
Buge wrote: post #112

Earlier quoted context omitted.

&arr is a pointer to an array (it points to the existing array). &arr + 1 is a pointer to an array that begins just after the existing array. * is the dereference operator, so it seems to me that *(&arr + 1) dereferences the pointer to the array, resulting in an array (or a reference to an array), which then decays to a pointer.

>so it seems to me that (&arr + 1) dereferences the pointer to the array It doesn't. Because an array is already a pointer, in (&arr + 1) &arr is a pointer to a pointer (ie, a handle) so *(&arr) is dereferencing the handle to the pointer. So it's still one pointer level deep - it doesn't dereference it completely.

It doesn't matter what it is a pointer to, type-wise. It is still a pointer one-past-the-end, and it is being dereferenced.

Also, &arr is not a pointer to a pointer. It's a pointer to an array. Specifically, its type is int(* )[5] in this example, and so when you dereference it, the result is of type int[5]. So if you do e.g. sizeof(* &arr + 1), you'll get 5 * sizeof(int).

Re: How to find size of an array in C without sizeof

#172

Post by int_19h »

wruza wrote: post #103
halayli wrote: post #81

Earlier quoted context omitted.

The compiler guarantees that arr + 1 doesn't overflow by making sure arr's address is small enough to not overflow when accessing one element past the array size. &arr + 1 is not one past the array you asked the compiler to allocate. if you're on a 16bit system and you define char x[36], the compiler guarantees that x's address is not more than 65500. if you do &x + 1 then you'll overflow, x + 1 won't. You can pass w…

Wait, wait. char *p = x; p += 36; // overflow? As arr == &arr, so are pointers P and Q that point just after last array item (1+&x[35]) and just after entire array (1+&x). As 6.5.6.8 above said, P is okay, and so must be Q. They said about last element, not second. Can you please explain why is x+1 even an argument? >if you're on a 16bit system and you define char x[36], the compiler guarantees that x's address is no…

No, he is correct. The C and C++ standards do allow pointers past the last element of an array to be produced via a pointer to an element of said array. They also have a provision where a pointer to a nonarray value is treated as if it were a 1-element array (so you can do "int x; int* p = *x + 1"). But in this case, the value is obviously an array object, and it's not an element to another array; hence, it is not legal to do &arr + 1 ("... otherwise, the behavior is undefined").

This is 6.3.6 "Additive operators" in ISO C90 standard, for anyone curious.

Re: How to find size of an array in C without sizeof

#173

Post by int_19h »

cbsmith wrote: post #88
mnarayan01 wrote: post #59

Earlier quoted context omitted.

So then I guess malloc can't return an allocation which actually goes to the end of the address space, but has to leave at least one extra byte to avoid overflow? That's pretty interesting, though I guess it certainly makes sense. Edit: Also now that I think about it, I've written code that relied on that behavior...not sure if I'd heard it before and internalized and forgot it, or just was being foolish.

Technically, this needn't impact malloc, because dereferencing the "one past the end" address is still undefined. All you need is logic in your pointer arithmetic that essentially treats the past the end address as a special value (which normally would never need to be represented).

Not just pointer arithmetic; also pointer comparisons. One-past-the-end pointer must compare greater-than any other pointer into that array.

So an implementation that could stick an array at the very end of the address space, and do wraparound for one-past-the-end so that it's represented by all bits zero, would then need to special-case that zero value when performing any pointer comparisons.

Re: How to find size of an array in C without sizeof

#174

Post by mynameisbahaa »

arjun024 wrote: post #149
mynameisbahaa wrote: post #144

Earlier quoted context omitted.

Please fix your site's header :)

I'll appreciate if you could provide a screenshot :)

(1)- Taken using chrome extension:http://imgur.com/a/PYMRD (2)- Print screen of chrome version 54.0.2840: http://imgur.com/a/dDwK9 (3)- Print screen of internet explorer version 11 :http://imgur.com/a/uxAv5

All running on 32bit windows 8.1

Re: How to find size of an array in C without sizeof

#176

Post by icebraining »

loeg wrote: post #128
flamedoge wrote: post #29

Earlier quoted context omitted.

How likely do you run into array bigger than 2gb?

It's basically bogus to have a single object bigger or equal to half of address space (represented by size_t) in C. 32-bit platforms should detect and abort in such conditions (compiler/linker for static objects, malloc() implementation for dynamic allocations).

Why? If you're running a system with PAE, half of a 32-bit address space is a small fraction of the whole addressable memory.

Re: How to find size of an array in C without sizeof

#177

Post by icebraining »

bonzini wrote: post #70
kabdib wrote: post #67

Earlier quoted context omitted.

Often enough; "pack" files in video games are often many GB. Memory-map one of those and there you are . . .

The parent is taking about >2gb on a 32-bit machine.

So what? You can have up to 64GB of RAM on a 32-bit machine: https://en.wikipedia.org/wiki/Physical_Address_Extension

Re: How to find size of an array in C without sizeof

#178

Post by pascal_cuoq »

tedunangst wrote: post #55
ycmbntrthrwaway wrote: post #5

The result you get with this trick is signed, while the result you get with sizeof is unsigned. Edit: Just to clarify, what you get is ptrdiff_t instead of size_t. So if array size is greater than PTRDIFF_MAX, you get undefined behavior [1]. [1] http://en.cppreference.com/w/c/types/ptrdiff_t

As far as I know, every compiler is badly broken with arrays greater than SIZE_MAX / 2, so this would be the least of your troubles.

Since I have it at hand, here is a list of examples of how compilers are broken if an array is larger than SIZE_MAX / 2 (which is called PTRDIFF_MAX in the post):

http://trust-in-soft.com/objects-larger-than-ptrdiff_max-byt...

Re: How to find size of an array in C without sizeof

#179

Post by angry_octet »

tedunangst wrote: post #58
disposablezero wrote: post #16

Many implementations historically also allocated enough memory to include one extra element at the end of the array.

I find this improbable.

Agreed, compiler implementors rarely decide to use more memory than is required. There may be a stack canary, but this is between stack allocated variables and control flow structures, not for every array.

Re: How to find size of an array in C without sizeof

#180

Post by angry_octet »

While this is as interesting as any c arcana, I truly hope that people are not passing around pointers to arrays and then using sizeof(array)/sizeof(elem) to figure out how big they are, like they are stuck in a first year programming assignment that denies them the use of malloc, so they use C99 VLAs everywhere.
Post reply on HN