kandr2 question

[tom st denis]

    Sounds like you were saying I'm saying and thinking things I'm not.

You said they're not always equivalent and that's true. But you
weren't asking about the times where they're not equivalent, therefore
I wasn't answering about the times you didn't ask about.

Tom

 

[tom st denis]

It is, of course, completely unreasonable for someone like Bill
Cunningham, who has been "learning" C for more than a decade, and
should therefore have long since ceased being a newbie, to be unaware
of this fact.

    No I'm not a newbie. And I know they mean the same here in this
circustance. I was wondering why they weren't using the char *s convention.
I will have to answer my own question and guess they are trying to simplify
things. If that guy thinks I'm trolling why is he talking to me and to come
right say I don't understand the likenesses in char *s and char s[] is an
insult to me.

Who the **** knows why they used it. I replied the way I did to your
post because you're an annoying person who asks retarded questions
over and over because you like to post nonsense. You're not "learning
C." It doesn't take 10+ years to learn C to a degree where you can
successfully write things like "I want to write an integer to a file"
or whatever your random project of the week is.

Tom

 

[Bill Cunningham]

If you don't know that char s[] is equivalent to char *s by now you
have to be trolling and are deserving of contempt.

Of course I know that Dick. What's that got to do with anything? Read
the standard.

And frankly I don't get you. Trolling comp.lang.c? Do you know how
specific that is? Of the few 100,000 people on the planet who are
aware of C you have to be one of the trolls? Seriously? Get a hobby.

You're the one dropping a troll.

 

[Bill Cunningham]

If you don't know that char s[] is equivalent to char *s by now you
have to be trolling and are deserving of contempt.

And you should know Prick that char s[] and char *s *are not* equivalent
always.

 

[Bill Cunningham]

And since clearly you seem to know this [judging by your reply here]
why the **** are you asking?

None of your God Damn Business and *I* was right. But that's not my point.

 

[Bill Cunningham]

Yup, but I was replying in context to his original question so the
pedantic police need not apply.

You Obviously didn't understand the original question in you infinite
mind. Dick.

 

[Keith Thompson]

§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.

Apparently you were wondering about this as a style issue, though your
original question gave no hint of that (and nobody is going to assume
that you understand the language issue).

Personally, I dislike using array notation for pointer parameters;
in my opinion it obfuscates the fact that the parameter is really
a pointer. But there are sound arguments for using it. If I write:

void func(char *s);

the intent could be either that s points to a single object of type
char, or that s points to the first element of an array of one or
more char elements. Using array notation:

void func(char s[]);

can make it clear to the reader that it's intended to point to the
first element of an array. (I'd rather express this distinction
in a comment rather than using language syntax.) Furthermore, C99
added features that let you express additional information between
the square brackets. This:

void func(char s[42]);

requires s to point to the first element of an array of *at least*
42 elements. (This requirement is imposed on the caller, and it's
not enforced by the compiler; if you violate it, your program's
behavior is undefined.)

The standard itself uses array notation when defining the
two-parameter definition of main:

int main(int argc, char *argv[]) { /* ... */ }

Again, I prefer to write:

int main(int argc, char **argv) { /* ... */ }

It's interesting to note that the standard *doesn't* use array
notation for the <string.h> functions:

size_t strlen(const char *s);

even though s must point to the first element of an array. This is
arguably a slight inconsistency in the standard, but I don't think
it's worth worrying about.

 

[Bill Cunningham]

N1570 6.7.6.3p7.

Is this the part your talking about Keith?
6.7.6.3 Function declarators (including prototypes)

Constraints

 

[Bill Cunningham]

You Obviously didn't understand the original question in you infinite
mind. Dick.

You asked if a char s[] inside a parameter list should instead be char
*s.

The answer is no. It doesn't have to be.

[snip]

I have never seen good function prototypes except these examples declare an
array definition as char s[] in the prototype. Are you looking at a babie's
code? They must be writing like this is kandr2 to simplify things.

 

[Bill Cunningham]

It's convention to use the star but that's not mandatory. Just like
you could write

char a[4];

a[3] = 4;

Or

3[a] = 4;

They're equivalent C code. Most people would use the former instead
of the latter even though they have the same effect.

Tom

In my original question I was asking about convention.

 

[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>

 

[Lew Pitcher]

[snip]

Let me write what was intended in my mind,

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

And the answer is no. It should be char *s [by convention] of course.

And you would be wrong.

By convention, the parameter list of a function indicates more than the type
and order of the function arguments. It /also/ may provide hints to the
programmer about /what sort/ of arguments are acceptable.

Given a function prototype of
void foo(char *);
or even a function definition of
void foo(char *bar) { ... }

the parameter indicates that the function takes a pointer to a character.
This is often a hint that the pointer will point to a single character, and
not an array of characters.

Had the function prototype been
void foo(char []);
or the function definition been
void foo(char bar[]) { ... }

then the hint would have been that the pointer will point to an array of
characters.

Note that, regardless of the hint, the parameter is still a pointer.

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.

 

[Bill Cunningham]

It is, of course, completely unreasonable for someone like Bill
Cunningham, who has been "learning" C for more than a decade, and
should therefore have long since ceased being a newbie, to be unaware
of this fact.

No I'm not a newbie. And I know they mean the same here in this
circustance. I was wondering why they weren't using the char *s convention.
I will have to answer my own question and guess they are trying to simplify
things. If that guy thinks I'm trolling why is he talking to me and to come
right say I don't understand the likenesses in char *s and char s[] is an
insult to me.

B

 

[Bill Cunningham]

They are in the context of the question you asked. Of course I wasn't
answering a question you didn't ask. That should go without saying.

Sounds like you were saying I'm saying and thinking things I'm not.

 

[Bill Cunningham]

I've seen it before, like I said I too don't use it, but it's valid C
code [even in C11] so the answer [again] to your original question is
no, it doesn't HAVE to be "char *s" in the parameter list.

My original question,

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

Should've been,

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

And I was attacked for not understanding they were the same. What the
****? Mind reading is off alittle today isn't it? So you could slip that
troll word in there and look better. Well then *don't* feed the trolls.

 

[Bill Cunningham]

Who the **** knows why they used it. I replied the way I did to your
post because you're an annoying person who asks retarded questions
over and over because you like to post nonsense. You're not "learning
C."

That is not a universal belief.

It doesn't take 10+ years to learn C to a degree where you can

successfully write things like "I want to write an integer to a file"
or whatever your random project of the week is.

<snicker>
What??

ROTFL. Have you heard of a killfile? I don't expect to hear from you again
after this thread. Where the hell did you come from?

 

[Bill Cunningham]

Who the **** knows why they used it.

I had a point but it's gone now.

 

[Bill Cunningham]

It's convention to use the star but that's not mandatory. Just like
you could write

char a[4];

a[3] = 4;

Or

3[a] = 4;

They're equivalent C code. Most people would use the former instead
of the latter even though they have the same effect.

Tom

In my original question I was asking about convention.

No you didn't. Here's your original question

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

And the answer is no. It's not an error, it can be "char s[]" if the
author wants to write that way.

Tom

Let me write what was intended in my mind,

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

And the answer is no. It should be char *s [by convention] of course.

 

[Bill Cunningham]

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.

Apparently you were wondering about this as a style issue, though your
original question gave no hint of that (and nobody is going to assume
that you understand the language issue).

Personally, I dislike using array notation for pointer parameters;
in my opinion it obfuscates the fact that the parameter is really
a pointer. But there are sound arguments for using it. If I write:

void func(char *s);

I agree.

the intent could be either that s points to a single object of type
char, or that s points to the first element of an array of one or
more char elements. Using array notation:

void func(char s[]);

can make it clear to the reader that it's intended to point to the
first element of an array. (I'd rather express this distinction
in a comment rather than using language syntax.) Furthermore, C99
added features that let you express additional information between
the square brackets. This:

void func(char s[42]);

requires s to point to the first element of an array of *at least*
42 elements. (This requirement is imposed on the caller, and it's
not enforced by the compiler; if you violate it, your program's
behavior is undefined.)

The standard itself uses array notation when defining the
two-parameter definition of main:

int main(int argc, char *argv[]) { /* ... */ }

Again, I prefer to write:

int main(int argc, char **argv) { /* ... */ }

It's interesting to note that the standard *doesn't* use array
notation for the <string.h> functions:

size_t strlen(const char *s);

even though s must point to the first element of an array. This is
arguably a slight inconsistency in the standard, but I don't think
it's worth worrying about.

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.

Bill

 

[Keith Thompson]

[...] 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]);

Yes, you're right.