Inconsistent

[jimbo]

Could someone comment on this code please.

1. Are the comments in it correct?

2. Why does sizeof(arr) not work consistently in C? In someFunction()
sizeof(arr) means sizeof(&arr[0]) in main. The compiler knows how big arr
is, so why the difference - esp. as it would be v.useful if sizeof(arr)
worked in someFunction as it does in main - so you could use sizeof(arr) in
the conditional bit of,say, a for loop in someFunction for example?

3. Why doesn't C allow testFunction to be declared char [] testFunction -
seems to me that if it did you could get away with knowing less about
pointers, and it seems as though again that C is incosistent, i.e., you
don't have to declare testFunction's parameter as char *. Surely, the
compiler should know that char [] someFunction actually means char *
someFunction??

char * testFunction(ch ar []);

int main(void)
{
/* Lie to the compiler. Should be ok though as the compiler knows how
big the array really is.*/
char arr[7] = "0123456789 ";

/* Ouput the sizeof the array. And the size of a pointer to it. */
printf("main() sizeof arr = %d\n", sizeof(arr));
printf("main() sizeof arr = %d\n", sizeof(&arr[0]));

/* Pass it on to the function where we'll do some other emaningless
things.*/
testFunction(ar r);
return 0;
}
/* Can't declare testFunction as char [] testF...() - even though the
compiler knows that array's are passed by address.*/

/* The size is ignored - and can't be checked anyway.*/
char * testFunction(ch ar arr[500])
{
int n;

/* Same sizeof line of code that was in main() - note here that it
output the size of a pointer!*/
printf("sizeof arr = %d\n", sizeof(arr));

return arr;
}

[Simon Biber]

Mark McIntyre wrote:

On Sat, 17 Dec 2005 20:11:41 GMT, in comp.lang.c , "jimbo"
<ji***@gmail.co m> wrote:

2. Why does sizeof(arr) not work consistently in C?

It does. Please read the documentation on it carefully, understand the
difrference between a pointer and an array, and understand what
happens to arrays when passed as parameters to functions.

/* Lie to the compiler. Should be ok though as the compiler knows how
big the array really is.*/
char arr[7] = "0123456789 ";

No, its disastrous. You just overwrote memory that doesn't belong to
you.

Any compiler worth its salt will diagnose that error at compile time,
and so you will fix the problem, and never get to the stage of actually
overwriting memory.

In fact, it is a constraint, and as such must be diagnosed by a
standard-conforming C compiler:

6.7.8 Initialization
...
Constraints
2 No initializer shall attempt to provide a value for an object not
contained within the entity being initialized.

--
Simon.

[Barry Schwarz]

On Sat, 17 Dec 2005 21:54:50 +0000, Mark McIntyre
<ma**********@s pamcop.net> wrote:

On Sat, 17 Dec 2005 20:11:41 GMT, in comp.lang.c , "jimbo"
<ji***@gmail.c om> wrote:

2. Why does sizeof(arr) not work consistently in C?

It does. Please read the documentation on it carefully, understand the
difrference between a pointer and an array, and understand what
happens to arrays when passed as parameters to functions.

/* Lie to the compiler. Should be ok though as the compiler knows how
big the array really is.*/
char arr[7] = "0123456789 ";

No, its disastrous. You just overwrote memory that doesn't belong to
you.

Isn't this simply a constraint violation (6.7.8-2) that requires a
diagnostic? Do any existing compilers actually initialize more than
the 7 bytes defined?
<<Remove the del for email>>

[Christopher Benson-Manica]

Simon Biber <ne**@ralmin.cc > wrote:

You remember incorrectly. In the parameter list of a function, char[]
and char* are exactly the same. In any other declaration they are
different. char[] is never an array of pointers. It can represent an
array of char, of unspecified size.

That is what I meant to say; the fact that I did not is disturbing. I
appreciate the correction.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[buda]

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

The indexing operator x[y], takes two operands, a pointer and an
integer (*not* an array and an integer). Typically, the pointer
operand is going to be an array name, which will be implicitly
converted to a pointer before the indexing operator sees its value.
x[y] is by definition equivalent to *(x+y). (Because addition is
commutative, x[y] can be written as [y]x; this odd little quirk is in
no way useful.) ^^^^

ITYM "x[y] can be written as y[x]". For example, "123"[1] is equivalent to
1["123"], but [1]"123" is a syntax error.

[Emmanuel Delahaye]

Keith Thompson a écrit :

Here you are *not* returning an array, you are returning a pointer.

Or more likely, an address...
Is this the old argument about the meanings of the terms "pointer" and
"address"?

Yes. Based on the fact that a pointer is an variable whose value is an
address, an address itself is a pointer constant. It's also the value of
a pointer. (like 123 is an integer constant and also the value of
variable of type char or int etc.)
It's reasonable, IMHO, to use the term "pointer" only to refer to an
object of pointer type, and the term "address" to refer to a *value*
of pointer type.
I'm glad to read that.
Thus the value of a pointer object is an address. I
generally try to use the terms this way myself.

But the standard doesn't make this distinction, at least not
consistently. For example, the malloc() function "returns either a
null pointer or a pointer to the allocated space".
Too bad and confusing. I would have written it like this:

<<the malloc() function "returns either a null pointer constant or the
address of the allocated space">>

Of course, it is useful to store this address into a pointer. Once
stored, the pointer points to the allocated block.

Simple wording, simple meaning, no trick... I understand better why
people have hard time with pointers. Seems obvious that the semantic
around'em isn't clear and consistent enough.
I think we have to accept that referring to a pointer value, such as
"returning a pointer", is acceptable.

Unfortunately, yes.

--
A+

Emmanuel Delahaye

[Emmanuel Delahaye]

Flash Gordon a écrit :

Emmanuel Delahaye wrote:

Flash Gordon a écrit :

Here you are *not* returning an array, you are returning a pointer.

}
Or more likely, an address...

The last time I looked the null pointer was not an address,

There is no 'null pointer'. There is a 'null pointer constant' also
known as NULL.

Ok, I should have written :

<<Or more likely, an address the null pointer constant aka NULL>>

although I
will happily accept correction if someone can point out something in the
standard that says otherwise. So I think it more accurate to talk of
returning a pointer than an address.

See Keith's response and my response to him.

--
A+

Emmanuel Delahaye

[pemo]

"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:1a******** ****@news.flash-gordon.me.uk...

jimbo wrote: <snip>

and it seems as though again that C is incosistent, i.e., you
don't have to declare testFunction's parameter as char *. Surely, the
compiler should know that char [] someFunction actually means char *
someFunction??

If both were valid they would mean different things. One would mean
returning an array, which C does not allow, whilst the other does mean
returning a pointer to char.

"If both were valid they would mean different things"

Hmmmm

Suerly, there is an inconsistency here with char ?[]

If

char * someFunction(ch ar arr[])

Can also be written [and has the same meaning as]

char * someFunction(ch ar * arr)

Then we can interpret char arr[] as a parameter type as *NOT* meaning that
an array is passed. E.g., both of these *are* valid, and they both mean
*the same thing*. So "If both were valid they would mean different things"
is not necessarily a good argument against not allowing this as a return
type IMHO.

Why not interpret - consistently with this in a
function-definition/declaration sense - char [] someFun.... as *NOT* meaning
that an array is returned then?

Also, as using char [] as a return type will cause a compiler error, in the
future, its meaning could be 'aligned' with its use when used as a parameter
without breaking any 'old' code. IMHO, this would be a useful semantic
alignment to make.

[pemo]

"Simon Biber" <ne**@ralmin.cc > wrote in message
news:43******** *************** @news.optusnet. com.au...

Christopher Benson-Manica wrote:

Because char[] and char * are not the same. IIRC, char [] is an array
of pointers of unspecified size.

You remember incorrectly. In the parameter list of a function, char[] and
char* are exactly the same. In any other declaration they are different.

I think this is the OP's point - please see my other post re its use as a
return type.

[Flash Gordon]

Emmanuel Delahaye wrote:

Keith Thompson a écrit :

Here you are *not* returning an array, you are returning a pointer. Or more likely, an address...
Is this the old argument about the meanings of the terms "pointer" and
"address"?

Yes. Based on the fact that a pointer is an variable whose value is an
address, an address itself is a pointer constant. It's also the value of
a pointer. (like 123 is an integer constant and also the value of
variable of type char or int etc.)

The problems I see with the term address are:
1) If you talk about returning an address you either imply that a null
pointer constant is an address leading to confusion about what you
can do with it, or continually say "address or null pointer" (or
something similar.
2) You are likely to confuse people about what they cad do. IMHO that
since address is a term used when talking about the hardware where no
type is involved (it is just memory), where as pointers are not.

After all, in summary, C pointers are slightly more abstract than
machine addresses.

<snip>
<<the malloc() function "returns either a null pointer constant or the
address of the allocated space">>

Of course, it is useful to store this address into a pointer. Once
stored, the pointer points to the allocated block.
I think it would be simpler if pointer or pointer value was used
throughout, see above. Just as I would refer to an int being returned by
a function.
Simple wording, simple meaning, no trick... I understand better why
people have hard time with pointers. Seems obvious that the semantic
around'em isn't clear and consistent enough.

Agreed. It would be better if consisten terminology is used.

I think we have to accept that referring to a pointer value, such as
"returning a pointer", is acceptable.

Unfortunately, yes.

I think it would be better if the term "address" was not used, expect
when talking about how pointers are implemented and possibly talking
about converting between pointer types. However, I recognise this is
very much my personal opinion, and I have no authority to call on, so
I'm certainly not going to complain about people talking about
addresses. I certainly see no point to a long discussion on this subject.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Emmanuel Delahaye]

Flash Gordon a écrit :

The problems I see with the term address are: <...> After all, in summary, C pointers are slightly more abstract than
machine addresses. <...> I think it would be better if the term "address" was not used, expect

May be the good wording should be 'reference' ?

"A reference is a (unique ?) value that identifies the memory location
of an object."

"NULL is a reference constant meaning invalid reference."

"A pointer is a variable that holds a reference to an object or NULL."
or:
"A pointer is a variable that holds the reference of an object or NULL."

"When a pointer is typed, the dereference operator (*) allows a read of
write acces to the referenced object."

etc. I'm not going to rewrite the C-standard, but I think that this kind
of wording could be used in C-books and tutorials for consistency.

--
A+

Emmanuel Delahaye