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.
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 /.
> 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.
"Bill Cunningham" <nos...@nspam.invalid> writes:
> Barry Schwarz wrote:
>> 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.
-- 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"
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".
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.
>> 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 > ^
> 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.
"Bill Cunningham" <nos...@nspam.invalid> writes:
> 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.
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.
-- 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 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.
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 Cunningham" <nos...@nspam.invalid> writes:
> 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.
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.
-- 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"
> 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.
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.
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.
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.
Barry Schwarz <schwar...@yahoo.com> writes:
> 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.
> 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.
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"
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 /.
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.
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...@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.
> 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.
> 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.
> > 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.
