kandr2 question

[Bill Cunningham]

Sidenote: /This/ (e-mail address removed) doesn't sound like the usual
Bill that we all know. Either something has changed drastically with
Bill, or the group has been trolled by someone posing as Bill.

What do you mean? I'm starting to get tired of being misrepresented and
accused of things wrongly. I have problems focusing and other mental issues.
I'm not whining but there's a reason I catch on slow. And a lack of things
to do with C except the UNIX API. I'm thinking of an example cbc_crypt in
the API for n*xs that takes arrays and the prototypes are declared as
pointers to char.

Bill

 

[Keith Thompson]

I just didn't appreciate being attacked and accused of not knowing
things I know obviously. I am not a newbie no but it was *meant* as a style
question as you say.

Not to defend the attacks you've been subjected to in this thread,
but when I read your original question I did assume that you weren't
aware that "char foo[]" and "char *foo" are equivalent as parameter
definitions. It seemed to me to be a reasonable assumption based
on your history. In any case, the exact same question could have
been asked by someone who *didn't* know about the equivalence.

Wording your question more clearly might have avoided a lot of
misunderstanding.

 

[BartC]

§1.9 page 29 has this function.

int getline (char s[], int lim)

Unless I'm missing something here to pass an array shoudn't that first
parameter be char *s ?

It depends on what you mean by "should".

The rest of this thread indicates that you're aware that this:
int getline (char s[], int lim)
and this:
int getline (char *s, int lim)
are equivalent. This is implied by N1370 6.7.6.3 paragraph 7, or by the
corresponding paragraph in earlier versions or drafts of the C standard.

There *is* something funny about char[] and char* being equivalent here.
It's apparent when doing automatic translators of type specifications (from
English, say) to C.

Translating 'array of char' to C is just 'char[]' (0 indirections) for an
ordinary declaration.

And 'pointer to array of char' is 'char(*)[]' (1 indirection). There's a
natural progression.

Now try and use these translations for function parameters; there's an
off-by-one error! A char(*)[] will give two indirections, while char[] gives
you one.

I suppose that since a true char[] parameter would allow pass-by-value
arrays, it was decided to make it mean something else. But it might have
been more useful to actually let it mean that, and to raise an error if
someone tried to use it without adding something more to it (such as
char(*)[]).

It would have made automatic translators simpler too. (Actually there was
bug in my translator because of this. It still worked though, because so
many casts were used elsewhere to make things right; I could have used float
instead of char* or char[] and it would have worked..)

 

[Barry Schwarz]

§1.9 page 29 has this function. int getline (char s[], int lim) Unless I'm
missing something here to pass an array shoudn't that first parameter be
char *s ? Bill

Granted that the parameter COULD be changed as you describe, why do you think it SHOULD be changed?

If you are going to ask questions about text in a document, you should at least quote the document accurately. Yes, the change you made was harmless but you are in no position to make that determination in the general case.

 

[Anand Hariharan]

[...]  Furthermore, C99
added features that let you express additional information between
the square brackets.  This:

    void func(char s[42]);

I think you mean func(char s[static 42]);

requires s to point to the first element of an array of *at least*
42 elements.

<snip>

Is there a document (that can be read/understood by ordinary mortals)
that explains all the different meanings of 'static'?

- Anand

 

[Ben Bacarisse]

[...]  Furthermore, C99
added features that let you express additional information between
the square brackets.  This:

    void func(char s[42]);

I think you mean func(char s[static 42]);

requires s to point to the first element of an array of *at least*
42 elements.

<snip>

Is there a document (that can be read/understood by ordinary mortals)
that explains all the different meanings of 'static'?

I am not aware of one.

There are only two positions in which static can appear: the "old" one
in an ordinary declaration and this new one (well, new since 1999) in a
parameter declaration. It feels like, more because the effect of it
appearing in plain a declaration varies a little depending on where that
declaration is: it always gives the declared identifier internal
linkage, but in a declaration at block scope it also gives the object
static storage duration.

 

[James Kuyper]

I am not aware of one.

There are only two positions in which static can appear: the "old" one
in an ordinary declaration and this new one (well, new since 1999) in a
parameter declaration. It feels like, more because the effect of it
appearing in plain a declaration varies a little depending on where that
declaration is: it always gives the declared identifier internal
linkage, but in a declaration at block scope it also gives the object
static storage duration.

It only gives identifiers internal linkage at file scope; block scope
objects have no linkage unless declared 'extern', in which case they
have external linkage. (6.2.2p7)

 

[James Kuyper]

[...] Furthermore, C99
added features that let you express additional information between
the square brackets. This:

void func(char s[42]);

I think you mean func(char s[static 42]);

requires s to point to the first element of an array of *at least*
42 elements.

<snip>

Is there a document (that can be read/understood by ordinary mortals)
that explains all the different meanings of 'static'?

I've read and understood the standard; but perhaps I shouldn't consider
myself an "ordinary mortal"?

In themselves, the other meanings of 'static' aren't very complicated:
At file scope, the 'static' keyword gives function or object identifiers
internal linkage. (6.2.2p3)
At block scope, it gives objects static storage duration. (6.2.4p3)

If you need an explanation of what "internal linkage" or "static storage
duration" mean, that's a little more complicated.

 

[Ben Bacarisse]

It only gives identifiers internal linkage at file scope; block scope
objects have no linkage unless declared 'extern', in which case they
have external linkage. (6.2.2p7)

Quote right. All it does for a block-scope object is change its storage
duration.

 

[Phil Carmody]

Wording your question more clearly might have avoided a lot of
misunderstanding.

But why would a troll do that if he knows he's more likely
to rack up a whole bunch more strokes if he keeps things
badly worded?

Phil

 

[Keith Thompson]

Granted that the parameter COULD be changed as you describe, why do
you think it SHOULD be changed?

[snip]

n1570.

That doesn't answer the question. The standard says that "char *foo"
and "char foo[]" are equivalent as parameter definitions. It says
nothing about which one *should* be used, and it uses both versions in
normative text.

 

[Bill Cunningham]

Not to defend the attacks you've been subjected to in this thread,
but when I read your original question I did assume that you weren't
aware that "char foo[]" and "char *foo" are equivalent as parameter
definitions. It seemed to me to be a reasonable assumption based
on your history. In any case, the exact same question could have
been asked by someone who *didn't* know about the equivalence.

Wording your question more clearly might have avoided a lot of
misunderstanding.

I thought in other posts and as long as I've been around that it would
be a reasonable assumption that in the very least I would know the sameness
and differences about pointers and arrays. Agreed my wording could've been
better but alot of that has always been my problem. I didn't know about the
word "convention" but I know I had been told that in the case of a parameter
declartion for taking an array was a pointer to whatever. I also assume that
kandr2 isn't wrong. So I wanted to clear up the confusion. I believe now
that it is legal C but not conventional.

Bill

 

[Bill Cunningham]

Granted that the parameter COULD be changed as you describe, why do
you think it SHOULD be changed?

[snip]

n1570.

Bill

 

[SG]

Am 30.10.2012 23:41, schrieb Bill Cunningham:

§1.9 page 29 has this function.

int getline (char s[], int lim)

Unless I'm missing something here to pass an array shoudn't that first
parameter be char *s ?

Why?

Personally, I prefer to use [] when declaring a function if the function
potentially wants "more than thing" (i.e. does pointer arithmetic on it
to access more than one object etc). I prefer * otherwise. It makes the
code kind of self-documenting to some degree.

One could argue that * and [] is an irregular aspect of the language and
one should avoid it just to make it easier for people to read the code
who don't know the rule that the compiler replaces the top-level [] in
function parameter types with *.

But then again, we still have array-to-pointer decay which is something
newbies have to deal with eventually... So much for regularity.

Cheers!
SG

 

[Keith Thompson]

That doesn't answer the question. The standard says that "char *foo"
and "char foo[]" are equivalent as parameter definitions. It says
nothing about which one *should* be used, and it uses both versions in
normative text.

Now I'm confused. I thought convention or "what you should do" was to
use int * (in the prototype) when passing a int [2]={0,1}; or similar. So
the standard *doesn't* say that? No wonder then kand2 used a char s[] then.

I don't know where you got the idea that the standard specifies a
"convention" in this case. It doesn't (nor should it IMHO).

There is no single "convention"; there are probably about as many coding
conventions as there are C programmers.

I don't see how your last sentence above follows from anything else.
Using "char s[]" is perfectly valid, but "char *s" is equally valid.

 

[Bill Cunningham]

That doesn't answer the question. The standard says that "char *foo"
and "char foo[]" are equivalent as parameter definitions. It says
nothing about which one *should* be used, and it uses both versions in
normative text.

Now I'm confused. I thought convention or "what you should do" was to
use int * (in the prototype) when passing a int [2]={0,1}; or similar. So
the standard *doesn't* say that? No wonder then kand2 used a char s[] then.

Bill

 

[Bill Cunningham]

That doesn't answer the question. The standard says that "char *foo"
and "char foo[]" are equivalent as parameter definitions. It says
nothing about which one *should* be used, and it uses both versions
in normative text.

Now I'm confused. I thought convention or "what you should do" was
to use int * (in the prototype) when passing a int [2]={0,1}; or
^

Sorry I mean int type[2]={0,1};

similar. So the standard *doesn't* say that? No wonder then kand2
used a char s[] then.
Bill

 

[Bill Cunningham]

I don't know where you got the idea that the standard specifies a
"convention" in this case. It doesn't (nor should it IMHO).

There is no single "convention"; there are probably about as many
coding conventions as there are C programmers.

I don't see how your last sentence above follows from anything else.
Using "char s[]" is perfectly valid, but "char *s" is equally valid.

Ok I understand.

B

 

[Bill Cunningham]

I don't know where you got the idea that the standard specifies a
"convention" in this case. It doesn't (nor should it IMHO).

There is no single "convention"; there are probably about as many
coding conventions as there are C programmers.

I don't see how your last sentence above follows from anything else.
Using "char s[]" is perfectly valid, but "char *s" is equally valid.

I think this entire thread has been a big mistake. When I was told a
prototype for passing an array should be a pointer I was thinking it was
illegal to do anything else. This is embarrassing. I got it straight now
though.

Bill

 

[Keith Thompson]

I don't know where you got the idea that the standard specifies a
"convention" in this case. It doesn't (nor should it IMHO).

There is no single "convention"; there are probably about as many
coding conventions as there are C programmers.

I don't see how your last sentence above follows from anything else.
Using "char s[]" is perfectly valid, but "char *s" is equally valid.

I think this entire thread has been a big mistake. When I was told a
prototype for passing an array should be a pointer I was thinking it was
illegal to do anything else. This is embarrassing.

As it should be. You've claimed repeatedly that you understood that
"char s[]" and "char *s" are equivalent as parameter definitions.
You claimed that your original question was about stylistic
conventions. Now you tell us that you thought "char s[]" would
be illegal. I see no reasonable explanation for this inconsistency.

I got it straight now
though.

A pleasant surprise if true.