simple array question

[Rod Pemberton]

Having reread it completely I am even more convinced it is crap than
when I saw pete saying it was crap.

And, you'd be wrong.

pointers

The C standard disagrees with you.

Actually, it agrees with me completely.

and
RP> values. Occasionally, you'll hear about arrays being "second class
RP> citizens" in C. What that means is arrays are an artificial construct
in C
RP> which appear to be arrays but aren't arrays. So, in a declaration:
Wrong.

Correct.

"char
RP> mstr[10]", mstr or mstr[] is thought of as an array.

Because it is except when it is the declaration of a parameter to a
function.

No, it's not.

But, [] is
actually a
RP> subscript operator which functions on pointers only.

True. Fortunately the name of an array gets automatically converted to a
pointer in this situation.

Incorrect.

Therefore, mstr is
a
RP> pointer, not an array.

Wrong. Or you would be able to do:
mstr = 0;

Correct, because it is a pointer to a const type (remember preallocated
storage?), i.e., the pointer can't be changed.

<snip>

I'm ignoring the rest of the also incorrect drivel.



Rod Pemberton

 

[Flash Gordon]

And, you'd be wrong.

True. Crap is useful, it can be made in to fertiliser. What you have
posted is worse than useless, it is dangerous because some poor innocent
who does not know any better might believe you. You've obviously still
not read the FAQ.

Actually, it agrees with me completely.

C&V. Here is a quote from the standard which defines the term "array type".
| An /array type/ describes a contiguously allocated nonempty set of
| objects with a particular member object type, called the /element
| type/.36) Array types are characterized by their element type and by
| the number of elements in the array. An array type is said to be
| derived from its element type, and if its element type is T, the
| array type is sometimes called 'array of T'. The construction of
| an array type from an element type is called 'array type
| derivation'.

Why would it define an array type if arrays don't exist? Can you quote
anything that says they don't?

Correct.

Nope. Unless you can quote something in the standard that says arrays
are not arrays.

"char
RP> mstr[10]", mstr or mstr[] is thought of as an array.

Because it is except when it is the declaration of a parameter to a
function.

No, it's not.

C&V? I'll give you a clue, there isn't one.

But, [] is
actually a
RP> subscript operator which functions on pointers only.

True. Fortunately the name of an array gets automatically converted to a
pointer in this situation.

Incorrect.

It's what the C standard says. Are you saying the C standard is wrong?
To be precise the standard says:
| Except when it is the operand of the sizeof operator or the unary &
| operator, or is a string literal used to initialize an array, an
| expression that has type 'array of type' is converted to an
| expression with type 'pointer to type' that points to the initial
| element of the array object and is not an lvalue. If the array object
| has register storage class, the behavior is undefined.

This seems to agree with what I said about when the subscript operator
is used.

Correct, because it is a pointer to a const type (remember preallocated
storage?), i.e., the pointer can't be changed.

This is explicitly addressed in section 6 of the FAQ and you've
obviously failed to read it.

<snip>

I'm ignoring the rest of the also incorrect drivel.

So you are going to ignore all the bits in the C FAQ that point out your
error, and the part where I pointed out that code relying on what you
claim will fail to compile and if forced through with a cast does not work.

Here is a nice simple example where a compiler is *required* to produce
a diagnostic *because* arrays are not the same thing as pointers.

#include <stdlib.h>

int main(void)
{
int a[5];
int *p;
if (&a == &p)
return EXIT_FAILURE;
else
return 0;
}

You can add in const in as many places as you want and the compiler will
continue to complain because it is *required* to. Of course, it is not
required to fail to compile, only to produce a diagnostic.

This is all covered in section 6 of the comp.lang.c FAQ, so here is a
link directly to it since you could not be bothered to read the
questions without a link. I expect you read them this time as well, but
any newbie following this thread will have the chance to read it and see
that you are wrong. http://c-faq.com/aryptr/index.html

 

[Dave Thompson]

Extern declarations and definitions of variables of which the names start
with str (followed by a lowercase letter) are not safe, and when <string.h>

Right. Or more precisely, declarations of the names for variables or
functions with external linkage. 'External declaration' is used in the
standard to mean at file scope, even with internal linkage; conversely
a declaration in block scope with external linkage (i.e. the 'extern'
keyword) of a library name is unsafe.

is included neither are static declarations and definitions with file
scope. However, it is true that non-file scope variable names can safely
start with str.

But not this. All library function (and variable) names plus the
extension ranges like str[a-z]* are declared (at file scope) _and
optionally #define'd as macros_ if the relevant header is #include'd.
This reservation as a macro name essentially prohibits any other use
unless you #undef it. See the fifth list item in 7.1.3, and 7.1.4p1.

- David.Thompson1 at worldnet.att.net

 

[Guest]

Right. Or more precisely, declarations of the names for variables or
functions with external linkage. 'External declaration' is used in the
standard to mean at file scope, even with internal linkage; conversely
a declaration in block scope with external linkage (i.e. the 'extern'
keyword) of a library name is unsafe.

Technically, I did say "extern declarations", not "external
declarations" You're right though, thanks.

is included neither are static declarations and definitions with file
scope. However, it is true that non-file scope variable names can safely
start with str.

But not this. All library function (and variable) names plus the
extension ranges like str[a-z]* are declared (at file scope) _and
optionally #define'd as macros_ if the relevant header is #include'd.
This reservation as a macro name essentially prohibits any other use
unless you #undef it. See the fifth list item in 7.1.3, and 7.1.4p1.

No, str[a-z]* may only be defined as function-like macros, not
object-like macros. See 7.1.4p1 again, but take into account that
7.26.11 by itself only permits str[a-z]* function declarations.

 

[Dave Thompson]

Technically, I did say "extern declarations", not "external
declarations" You're right though, thanks.

Glark! So you did. I somehow read that as 'External', which people too
often use somewhat loosely, but you did not. Sorry.

is included neither are static declarations and definitions with file
scope. However, it is true that non-file scope variable names can safely
start with str.

But not this. All library function (and variable) names plus the
extension ranges like str[a-z]* are declared (at file scope) _and
optionally #define'd as macros_ if the relevant header is #include'd.
This reservation as a macro name essentially prohibits any other use
unless you #undef it. See the fifth list item in 7.1.3, and 7.1.4p1.

No, str[a-z]* may only be defined as function-like macros, not
object-like macros. See 7.1.4p1 again, but take into account that
7.26.11 by itself only permits str[a-z]* function declarations.

Well, yes, but. IME it's awful easy to somewhere, accidentally, end up
with an object(like) name adjacent to a parentheses, and then you get
very confusing problems; it's easier to just err a bit on the side of
safety. (This is similar to my position on names beginning with
underscore.) But I'll concede you can use it carefully as a variable,
and I shouldn't overstate the case when we're being exact.

- David.Thompson1 at worldnet.att.net