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

51–60 of 212 posts

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

#51

Post by Swizec »

quotemstr wrote: post #41
flamedoge wrote: post #29

Earlier quoted context omitted.

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

The "how likely is it, really?" response to questions of technical correctness has always bothered me. It takes a mindset completely alien to mine to say "Here's a race condition. Sure, it's undefined behavior, but the race is narrow, so it's rare" or to say "Sure, memory allocation can theoretically fail, but in practice almost never does" or to say "fsync is too slow and most computers have batteries these days". S…

Engineering is about tradeoffs. How many once-in-a-thousand bugs do you fix before you tackle the one-in-a-million? Or one in a billion? What about if it takes $10/bug to fix every 1:1000 bug and $100,000 to fix one 1:1000000 bug?

Correctness is great in theory, but in practice it's a matter of what's important.

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

#52

Post by spdionis »

mjburgess wrote: post #43
quotemstr wrote: post #41

Earlier quoted context omitted.

The "how likely is it, really?" response to questions of technical correctness has always bothered me. It takes a mindset completely alien to mine to say "Here's a race condition. Sure, it's undefined behavior, but the race is narrow, so it's rare" or to say "Sure, memory allocation can theoretically fail, but in practice almost never does" or to say "fsync is too slow and most computers have batteries these days". S…

The problem you're latching on to I think is how the context for caculating a probability can vary. If it were really as likely as, say, the sun exploding that X happened then it would be of no use to expend time on X. BUT very often people speaking about the probability of events given suspicious constraints. While a memory allocation might not fail in most situations it will fail often in some situations. And a one…

That's why it's called one in a million...

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

#53

Post by minipci1321 »

Chinjut wrote: post #44

C is such a boondoggle of a language... We're condemned to forever explore its every weird nook and cranny for historical reasons, rather than because it is the cleanest, best approach to things possible.

C for sure has its weird sides, but does appear much more logical and consistent when observed "from the below", from how-the-hardware-runs perspective.

For example, the shift operators have higher precedence than bitwise masking (and/or/xor) since this way the expressions setting/clearing ranges of bits won't require parentheses (so increased readability) and the masking constants in them will be the narrowest. Loading a wide immediate value into a register sometimes takes several instructions, so such precedence also brings in the least cost as well (nowadays compilers take care of that to some extent).

But people frequently mess up this aspect, use lots of parens (and ending up with wide masks) saying this rule is not intuitive. It is.

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

#54

Post by pigz »

vram22 wrote: post #45
flamedoge wrote: post #29

Earlier quoted context omitted.

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

Not likely, but possible. This reminds me of the bug that was found in the binary search algorithm a few years ago, IIRC, in Java. The interesting thing is that binary search is probably one of the earliest-invented algorithms. Yet, in the book Writing Efficient Programs by Jon Bentley (which I mentioned in a recent HN comment), he says that in a class he taught to several industrial programmers with many years of ex…

https://research.googleblog.com/2006/06/extra-extra-read-all...

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

#55

Post by tedunangst »

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.

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

#56

Post by pg_is_a_butt »

droopyEyelids wrote: post #35
shmerl wrote: post #30

Earlier quoted context omitted.

I'm not sure if it's a praise for C though. Arcane design and lack of clarity might be fun to decipher, but it's not something that you'd want to see in the programming language.

Doesn't every language turns into insanity to decipher once you look close enough?

yes. what does "turns into" mean? did you mean "turn into"? you are insane.

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

#57

Post by jbn »

vram22 wrote: post #45
flamedoge wrote: post #29

Earlier quoted context omitted.

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

Not likely, but possible. This reminds me of the bug that was found in the binary search algorithm a few years ago, IIRC, in Java. The interesting thing is that binary search is probably one of the earliest-invented algorithms. Yet, in the book Writing Efficient Programs by Jon Bentley (which I mentioned in a recent HN comment), he says that in a class he taught to several industrial programmers with many years of ex…

I think this is it: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6412541

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

#59

Post by mnarayan01 »

cperciva wrote: post #25
halayli wrote: post #12

this is undefined behavior. &arr + 1 can overflow. There's no guarantee &arr isn't near memory end boundary. &arr + 1 is converted at compile time to rbp - X where X is an integer determined by the compiler similarly to how sizeof works. Basically ptr + integer requires the compiler to determine the sizeof ptr's type.

this is undefined behavior. &arr + 1 can overflow No. From 6.5.6 Additive operators: 7 For the purposes of these operators, a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type. 8 [...] if the expression P points to the last element of an array object, the expression (P)+1 points one past…

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.

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

#60

Post by halayli »

cperciva wrote: post #46
halayli wrote: post #31

Earlier quoted context omitted.

But arr != &arr even though they have the same value. #8 applies to arr (P), but in the post OP is using &arr which is a ptr to array[x] and doesn't apply to it.

That's why I quoted paragraph 7: arr is not an element of an array, so &arr (being a pointer to an object which is not an element of an array) behaves like a pointer to the first element of an array of length one with the type of the arr as its element type. So &arr behaves like it's a pointer to the start of int[5][1].

Yes &arr does behave like arr when it comes to ptr arithmetic but the compiler does not guarantee that &arr + 1 does not overflow. It only guarantees arr + 1. if you have a ptr from heap, ptr + 1 if not alloced previously is UB.

> If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow;

this point doesn't apply to &arr + 1.

Post reply on HN