Thread: any way to determine size of array thats a function parameter?

Oops I meant division but said sizeof(). And I cannot stress this enough, my brain doesn't truncate decimal values. I never at any point said that the run-time result would be .5 I said that 4/8 = .5, they are two very distinctively different things. Even if you put:

Code:

int f(double *array) {
  size_t size = sizeof(array)/sizeof(*array);
  return (signed)size;
}

int main( void )
{
    double array[] = { 0.0, 1.1, 2.2 };
    printf("returned value is %g\n", (double)f( array ) );
    return 0;
}

printf() would still print 0 due to the limitations of the data-type. I'm not certain of why you are arguing with me as I never said prelude was wrong about how the integers will be handled. However, I did say that sizeof(double *)/sizeof(double) is equal to .5. But since quzah has trouble understanding I will modify my original post:


[revision]

Code:

int f(double *array) {
  size_t size = sizeof(array)/sizeof(*array);
  return (signed)size;
}

Is wrong as you are saying the size of a pointer divided by the size of a double. Which on my machine would be .5, which I guarantee you is not what you were looking for Of course the return of this function will be 0 as the function is using integer math, which will truncate any decimal value.
[/revision]

Is wrong as you are saying the size of a pointer divided by the size of a double. Which on my machine would be .5, which I guarantee you is not what you were looking for Of course the return of this function will be 0 as the function is using integer math, which will truncate any decimal value.

No it isn't. size_t is integeral, thus any value it has will also be integral. As such, you can never have that value be .5 on your machine. It is as stated, impossible. You will never get "sizeof a pointer divided by sizeof a double" to equal anything other than an integer. Period. You are dealing with integers, as stated, and as such, you can never, I repeat NEVER have an integer .5.

Quzah.

>However, I did say that sizeof(double *)/sizeof(double) is equal to .5.
Logically, perhaps, but in every conforming implementation, sizeof evaluates to size_t, which is an unsigned integral quantity. The division is working with integers, so .5 never enters into the equation as far as C is concerned. If you can figure out a good way for a floating-point byte size to be meaningful then you can submit a defect report to ISO.

>#define sizeof_f(type) (double)sizeof((type))
That's a syntax error, but if you remove the parens around type in sizeof, it will compile and work as you expect.

>people would have jumped an my ass and started complaining about how 4/8 is not 0
And they would have been just as wrong as you were by saying that

size of a pointer divided by the size of a double. Which on my machine would be .5

And we would have jumped on their asses about it. Sure, you can make the statement right by converting the result of sizeof before the division, but since the comment in question was about this code:

Code:

size_t size = sizeof(array)/sizeof(*array);

It was wrong (regardless of what you really meant), there are no loopholes in your wording or misunderstandings on our part, and you could have avoided all of this by not defending your mistake. I see where you're coming from, really I do. But it causes unnecessary confusion, so it's better to stick with C's rules and explain them if someone questions you.

Originally Posted by master5001

I never said that it did evaluate to any sort of floationg point value, nor do i see any reason why one would want it to. However, if one really wanted too...

Of course I am certain that if I said sizeof(double *)/sizeof(double) was equal to zero (note now I NEVER said the compiler will evaluate anything to anything) people would have jumped an my ass and started complaining about how 4/8 is not 0. Point, this is almost an argument of symantics, however its not quite one as I didn't exactly leave any loop-holes in my wording.

Sure you did, let me quote you:

Which on my machine would be .5,

Your machine, dividing integers will most definately NOT give you .5 for that.

Quzah.

>Since you two want to keep arguing with me
At this point, you can believe what you want to. However, I'll continue to correct you if you keep trying to confuse people with your little machine/compiler distinction.

What an utterly pointless debate...