kandr2 question

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

Bill

[tom st denis]

Fuck off.

[Bill Cunningham]

tom st denis wrote:

> Fuck off.

Go fuck yourself. That's what I have been told.

[tom st denis]

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

[Keith Thompson]

N1570 6.7.6.3p7.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

tom st denis <t...@iahu.ca> writes:
[...]
> ... char s[] is equivalent to char *s ...

As you know, the equivalence applies only for function parameters.

[Bill Cunningham]

tom st denis wrote:

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

[tom st denis]

On Oct 30, 6:04 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> tom st denis wrote:
> > 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 you wrote...

>int getline (char s[], int lim)
>
>Unless I'm missing something here to pass an array shoudn't that first
>parameter be char *s ?

And I wrote "they're equivalent."

So maybe yes it should be char *s out of convention but char s[] is
allowed there as for function parameters they're equivalent.

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

Tom

[Bill Cunningham]

tom st denis wrote:

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

[tom st denis]

On Oct 30, 6:01 pm, Keith Thompson <ks...@mib.org> wrote:
> tom st denis <t...@iahu.ca> writes:
> [...]
>
> >                    ... char s[] is equivalent to char *s ...
>
> As you know, the equivalence applies only for function parameters.

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

Tom

[BartC]

"tom st denis" <t...@iahu.ca> wrote in message
news:3f556c91-92ab-4d83...@s18g2000yqh.googlegroups.com...

> On Oct 30, 5:50 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:

>> That's what I have been told.
>
> 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.

But in certain contexts, they are not the same. The question is reasonable.

--
Bartc

[Bill Cunningham]

tom st denis wrote:
> And since clearly you seem to know this [judging by your reply here]
> why the fuck are you asking?

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

[tom st denis]

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.

Tom

[tom st denis]

On Oct 30, 6:08 pm, "BartC" <b...@freeuk.com> wrote:
> "tom st denis" <t...@iahu.ca> wrote in messagenews:3f556c91-92ab-4d83...@s18g2000yqh.googlegroups.com...

>
> > On Oct 30, 5:50 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> >>   That's what I have been told.
>
> > 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.
>
> But in certain contexts, they are not the same. The question is reasonable.

As a function parameter? They're entirely interchangeable. It's
convention to use the star but you can use [] if it floats your boat.

Tom

[Bill Cunningham]

tom st denis wrote:

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

[tom st denis]

Right about what? It doesn't have to be "char *s" it CAN be "char
s[]" and be perfectly valid code [when used as a parameter to a
function].

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

[tom st denis]

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.

You only wrote one question in your original post. Unless you have
some sort of vanishing NNTP ink that I don't know of I think saw and
answered your original question.

Tom

[Bill Cunningham]

Keith Thompson wrote:

> N1570 6.7.6.3p7.

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

Constraints

[Bill Cunningham]

tom st denis wrote:
> On Oct 30, 6:12 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
>> tom st denis wrote:
>>> 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.
>
> 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.

[tom st denis]

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.

Tom

[Keith Thompson]

tom st denis <t...@iahu.ca> writes:
> On Oct 30, 6:01 pm, Keith Thompson <ks...@mib.org> wrote:
>> tom st denis <t...@iahu.ca> writes:
>> [...]
>>
>> >                    ... char s[] is equivalent to char *s ...
>>
>> As you know, the equivalence applies only for function parameters.
>
> Yup, but I was replying in context to his original question so the
> pedantic police need not apply.

Nevertheless, I was concerned that other readers might not pay
sufficient attention to the context.

[Bill Cunningham]

tom st denis wrote:

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

[Keith Thompson]

"Bill Cunningham" <nos...@nspam.invalid> writes:
> tom st denis wrote:
>> 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.

Will *both* of you please calm the &^%$ down?

[tom st denis]

On Oct 30, 6:30 pm, Keith Thompson <ks...@mib.org> wrote:
> tom st denis <t...@iahu.ca> writes:
>
> > On Oct 30, 6:01 pm, Keith Thompson <ks...@mib.org> wrote:
> >> tom st denis <t...@iahu.ca> writes:
> >> [...]
>
> >> >                    ... char s[] is equivalent to char *s ...
>
> >> As you know, the equivalence applies only for function parameters.
>
> > Yup, but I was replying in context to his original question so the
> > pedantic police need not apply.
>
> Nevertheless, I was concerned that other readers might not pay
> sufficient attention to the context.

Fair enough.

Tom

[James Kuyper]

On 10/30/2012 06:11 PM, tom st denis wrote:
> On Oct 30, 6:08�pm, "BartC" <b...@freeuk.com> wrote:
>> "tom st denis" <t...@iahu.ca> wrote in messagenews:3f556c91-92ab-4d83...@s18g2000yqh.googlegroups.com...

...

>>> 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.
>>
>> But in certain contexts, they are not the same. The question is reasonable.
>
> As a function parameter? They're entirely interchangeable. It's
> convention to use the star but you can use [] if it floats your boat.

No - as he said, they're different only "in certain contexts". The fact
that there are contexts where it does make a difference, means that it's
not unreasonable for a newbie to be unaware of their equivalence in this
context.

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.
--
James Kuyper

[tom st denis]

On Oct 30, 6:31 pm, Keith Thompson <ks...@mib.org> wrote:
> "Bill Cunningham" <nos...@nspam.invalid> writes:
> > tom st denis wrote:
> >> 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.
>
> Will *both* of you please calm the &^%$ down?

I dunno, caught a nerve today with usenet trolls... I should just go
out for a pint...

[Bill Cunningham]

James Kuyper wrote:
> 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]

tom st denis wrote:
> 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.

[tom st denis]

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

[tom st denis]

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]

Who the fuck 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]

tom st denis wrote:
> 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
fuck? 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]

tom st denis wrote:

> Who the fuck 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]

tom st denis wrote:

> Who the fuck knows why they used it.

I had a point but it's gone now.

[Keith Thompson]

"Bill Cunningham" <nos...@nspam.invalid> writes:
> §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]

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.

[Ben Bacarisse]

Keith Thompson <ks...@mib.org> writes:
<snip>
> [...] 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>
--
Ben.

[Bill Cunningham]

Keith Thompson wrote:

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

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

[Lew Pitcher]

On Tuesday 30 October 2012 20:28, in comp.lang.c, nos...@nspam.invalid
wrote:

[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/ nos...@nspam.invalid 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.

--
Lew Pitcher
"In Skills, We Trust"

[Bill Cunningham]

Lew Pitcher wrote:

> Sidenote: /This/ nos...@nspam.invalid 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]

Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> Keith Thompson <ks...@mib.org> writes:
> <snip>
>> [...] 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.

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

--

[Keith Thompson]

"Bill Cunningham" <nos...@nspam.invalid> writes:
[...]

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

[christian.bau]

On Oct 30, 9:41 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
>     §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 ?

No.

[BartC]

"Keith Thompson" <ks...@mib.org> wrote in message
news:ln7gq7r...@nuthaus.mib.org...

> "Bill Cunningham" <nos...@nspam.invalid> writes:
>> §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..)

--
Bartc

[Barry Schwarz]

On Tuesday, October 30, 2012 2:41:06 PM UTC-7, Bill Cunningham wrote:
> §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]

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

- Anand

[Ben Bacarisse]

:-) 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.

--
Ben.

[James Kuyper]

On 10/31/2012 09:33 AM, Ben Bacarisse wrote:
> Anand Hariharan <mailto.anan...@gmail.com> writes:
...

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

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]

On 10/31/2012 08:43 AM, Anand Hariharan wrote:
> On Oct 30, 6:31 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> Keith Thompson <ks...@mib.org> writes:

...

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

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

--
Ben.

[Bill Cunningham]

Keith Thompson wrote:
> 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]

Barry Schwarz wrote:

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

[snip]

n1570.

Bill

[Phil Carmody]

Keith Thompson <ks...@mib.org> writes:
> "Bill Cunningham" <nos...@nspam.invalid> writes:
...

> 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
--
Regarding TSA regulations:
How are four small bottles of liquid different from one large bottle?
Because four bottles can hold the components of a binary liquid explosive,
whereas one big bottle can't. -- camperdave responding to MacAndrew on /.

[Kenneth Brody]

On 10/30/2012 6:07 PM, tom st denis wrote:
> On Oct 30, 6:01 pm, Keith Thompson <ks...@mib.org> wrote:
>> tom st denis <t...@iahu.ca> writes:
>> [...]
>>
>>> ... char s[] is equivalent to char *s ...
>>
>> As you know, the equivalence applies only for function parameters.
>
> Yup, but I was replying in context to his original question so the
> pedantic police need not apply.

Since I'm not a member of the "pedantic police", I guess I am allowed to
point out that you stripped out the context showing that it was a function
parameter. You simply said:

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


--
Kenneth Brody

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

[Kenneth Brody]

On 10/30/2012 7:30 PM, Bill Cunningham wrote:
[...]

> In my original question I was asking about convention.

Your original question was:

> int getline (char s[], int lim)
>
> Unless I'm missing something here to pass an array shoudn't that first
> parameter be char *s ?

To me, I see no question about "convention", but rather syntax, because you
believe that "char s[]" is "wrong". The wording screams that you feel it's
not valid syntax, rather than "just a different convention" for the same thing.

A question about convention, if I were wording it, would have gone something
like "wouldn't it be clearer to use 'char *s' instead".

--
Kenneth Brody

[Bill Cunningham]

Keith Thompson wrote:

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

Bill Cunningham wrote:
> Keith Thompson wrote:
>
>> 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};

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

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]

Keith Thompson wrote:
> 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]

Keith Thompson wrote:
> 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]

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.

[Bill Cunningham]

SG wrote:
> 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

I guess to each his/her own.

Bill

[Barry Schwarz]

What does the hybrid version of the Infinity Q45 automobile have to do with this discussion?

There is no n1570. All the numbers under the N are in the range of 31 to 45.

And in the draft standard, the word "should" appears 80 times. Not one of those is related to the form a a function parameter. Maybe you should actually read it sometime.

If you are just going to throw random words together, do it in alt.anagrams where it can possibly lead to an interesting thread.

[Ike Naar]

On 2012-11-01, Barry Schwarz <schw...@yahoo.com> wrote:
> On Wednesday, October 31, 2012 10:52:40 AM UTC-7, Bill Cunningham wrote:
>> Barry Schwarz wrote:
>>> Granted that the parameter COULD be changed as you describe, why do
>>> you think it SHOULD be changed?
>>[snip]
>>n1570.
>

> There is no n1570.

There is http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf,
a draft version of the C 2011 Standard.

> All the numbers under the N are in the range of 31 to 45.

No idea what that is supposed to mean. Can you clarify?

[Phil Carmody]

No! Please - we already have one clue-resistent loon in a.a, we don't need another (and f/ups set).

Poster Bill Cunningham =
Bing "Null pointer chasm"

[Bill Cunningham]

Keith Thompson wrote:

> As it should be. You've claimed repeatedly that you understood that
> "char s[]" and "char *s" are equivalent as parameter definitions.

Yes I do.

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.

When this thread began I thought style was part of the standard. And I
do have a n1570.pdf. Convention came to be known as programmer's option.
Standard or a best current practice was what I believed to be using char *s
instead of char s[].
Does that help any? Do you know know what I've been thinking. As I said
I even regret this thread now.

Bill

[Bill Cunningham]

Barry Schwarz wrote:
> There is no n1570. All the numbers under the N are in the range of
> 31 to 45.
>
> And in the draft standard, the word "should" appears 80 times. Not
> one of those is related to the form a a function parameter. Maybe
> you should actually read it sometime.
>
> If you are just going to throw random words together, do it in
> alt.anagrams where it can possibly lead to an interesting thread.

I have n1570.pdf and n1256.pdf which is older.

Bill

[Barry Schwarz]

You have never played Bingo??

--
Remove del for email

[Bill Cunningham]

Ike Naar wrote:

> No idea what that is supposed to mean. Can you clarify?

All I know is I have n1296.pdf and n1570.pdf

Bill

[Anand Hariharan]

On Oct 31, 10:11 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:

> James Kuyper <jameskuy...@verizon.net> writes:
> > On 10/31/2012 09:33 AM, Ben Bacarisse wrote:

> >> Anand Hariharan <mailto.anand.hariha...@gmail.com> writes:
> > ...
> >>> 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.
>
> > 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.
>

Thank you, Ben and James.

sincerely,
- Anand

[Nick Keighley]

On Oct 30, 9:50 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> tom st denis wrote:
> > Fuck off.
>
>     Go fuck yourself. That's what I have been told.

leave some context in you idiot.
who told you? And what did they tell you? (you tend to misquote people)

[Nick Keighley]

On Oct 30, 10:25 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> tom st denis wrote:

> > On Oct 30, 6:12 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> >> tom st denis wrote:

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

I'm no baby and I often use array syntax

[Nick Keighley]

On Oct 30, 10:04 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> tom st denis wrote:

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

what?

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

[Nick Keighley]

On Oct 30, 10:09 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> tom st denis wrote:

CONTEXT!!!!!!!!!!!!!!!

> > And since clearly you seem to know this [judging by your reply here]
> > why the <expletive> are you asking?
>
> None of your <expletive> Business and *I* was right. But that's not my point.

if a question makes no sense then knowing the reason for asking it may
help work what the question is really about. You were not right you
were 100% wrong.

[Nick Keighley]

On Oct 30, 10:30 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> tom st denis wrote:

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

and the answer is it's a convention that isn't adhered to very widely.
Maybe most code uses it but nowhere near all. As I remarked earlier I
use array syntax myself if I expect most callers to be passing an
array. I sometimes think it makes the intent of the code clearer.

[Nick Keighley]

On Oct 30, 11:28 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> tom st denis wrote:

> > On Oct 30, 6:30 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> >> tom st denis wrote:
> >>> 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.

no.

[Nick Keighley]

On Oct 30, 11:50 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> Lew Pitcher wrote:
> > Sidenote: /This/ nos...@nspam.invalid 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.

except you seem to make no attempt to compensate for your alleged
problems. I for instance combat a poor memory by taking notes and
*using* them.

[Nick Keighley]

On Oct 30, 10:11 pm, tom st denis <t...@iahu.ca> wrote:
> On Oct 30, 6:08 pm, "BartC" <b...@freeuk.com> wrote:
>
> > "tom st denis" <t...@iahu.ca> wrote in messagenews:3f556c91-92ab-4d83...@s18g2000yqh.googlegroups.com...

>
> > > On Oct 30, 5:50 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> > >>   That's what I have been told.
>

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

> > But in certain contexts, they are not the same. The question is reasonable.
>
> As a function parameter?  They're entirely interchangeable.  It's

> convention to use the star

no it isna't

> but you can use [] if it floats your boat.
>
> Tom

[Nick Keighley]

On Oct 31, 12:51 am, Keith Thompson <ks...@mib.org> wrote:
> "Bill Cunningham" <nos...@nspam.invalid> writes:
>
> [...]
>
> >     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.

the sun will be a cold cinder before Bill manages to ask a clear, well
thought out question

[Nick Keighley]

On Oct 31, 5:47 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:

> Keith Thompson wrote:
> > 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.

a point I don't agree with

[Nick Keighley]

On Nov 1, 7:13 pm, Barry Schwarz <schwa...@dqel.com> wrote:
> On Thu, 1 Nov 2012 09:34:34 +0000 (UTC), Ike Naar
>
>
>
>
>
>
>
>
>
> <i...@sverige.freeshell.org> wrote:

> >On 2012-11-01, Barry Schwarz <schwar...@yahoo.com> wrote:
> >> On Wednesday, October 31, 2012 10:52:40 AM UTC-7, Bill Cunningham wrote:
> >>> Barry Schwarz wrote:
> >>>> Granted that the parameter COULD be changed as you describe, why do
> >>>> you think it SHOULD be changed?
> >>>[snip]
> >>>n1570.
>
> >> There is no n1570.
>

> >There ishttp://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf,

> >a draft version of the C 2011 Standard.
>
> >> All the numbers under the N are in the range of 31 to 45.
>
> >No idea what that is supposed to mean. Can you clarify?
>
> You have never played Bingo??

I wasn't aware there was a convention for the numbers in bingo

[horme...@gmail.com]

On Saturday, November 10, 2012 6:52:59 AM UTC-8, Nick Keighley wrote:
> the sun will be a cold cinder before Bill manages to ask a clear, well
> thought out question

So Bill is the cure for global warming? ALL HAIL BILL!!!

---
William Ernest Reid

[Old Wolf]

On Oct 31, 10:56 am, tom st denis <t...@iahu.ca> wrote:
> 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 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.

Bill Cunningham has been posting rank beginner questions
to this newsgroup now for, what, 6 years?

It's hard to see how it could be anything other than trolling. Maybe
he
is addicted to the sense of community he feels when people respond to
his posts?