Pointers

[ByteSurfer]

I am realy confussed bout pointers.. Can you guys please tell me what
is the difference or is there any kinds of pointers ?

char** a;
char *a;
*char a;

etc if there is any that i don't know or i am wrong.

Thanks

Regards,
Billy

[Mark McIntyre]

On 8 Mar 2005 06:39:45 -0800, in comp.lang.c , "ByteSurfer"
<by********@gmail.com> wrote:

I am realy confussed bout pointers.. char** a;
pointer to a pointer to a char
char *a;
pointer to a char
*char a;

syntax errror.
If you need to understand this better, usenet is a REALLY bad place to do
distance learning. Sit down calmly with your C textbook, and work carefully
through the chapter on pointers.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Christopher Benson-Manica]

<11*********************@f14g2000cwb.googlegroups. com>
ByteSurfer <by********@gmail.com> wrote:

char** a;
a is a pointer to a pointer to a char.
char *a;
a is a pointer to a char.
*char a;

Syntax error.

--
Christopher Benson-Manica
ataru(at)cyberspace.org

[bjrnove]

*char a; IS NOT VALID AT ALL.

Look at this example:

char chr = 'a'; /* Just another char */
char* pchr = &chr; /* A pointer to the char above */
char** ppchr = &pchr; /* A pointer to the pointer to the char */
char*** pppchr = &ppchr; /* A pointer to a pointer to a pointer to a
char */

This can go on for a while (your code will probably crash after added
tons of *, but there doesn't have to be a limit. It's all compiler and
machine specific.)

Now you can use this pointers. Adding a * in front of a pointer (not
when declaring it, but ever after) will give you the stuff inside a
pointer. You could therfor do something like this:

printf("The char chr is: %c\n", chr);
printf("The char pointed to by pchr is: %c\n", *pchr);
printf("The char pointed to by ppchr is: %c\n", **ppchr);
printf("The char pointed to by pppchr is: %c\n", ***pppchr);

Now I know this may sound a bit confusing, but when you understand
pointers it wil be much clearer. I can recomend you to read this
chapter in a online book on c:
http://publications.gbdirect.co.uk/c_book/chapter5/
It will basicly try to teach you everything about pointers.

One last thing. Usaly you never need more than a pointer and in some
cases a pointer to a pointer. It's actualy pretty weird to see a
pointer to a pointer to a pointer.

--
bjrnove

[ByteSurfer]

some times is am kinda confused.
they like to code

char* a;
char *a;

is that both are of the same ??

and some more is it :

*const char a;
-> a pointer of a constant address to a character

const char* a; or const char *a;
-> a constant value of a char.

then how bout *const char* a;

will the spaces char* and char * the same ??

[bjrnove]

> some times is am kinda confused.

they like to code

char* a;
char *a;

is that both are of the same ?? Yes.

and some more is it :

*const char a;
-> a pointer of a constant address to a character No. Its an error. You want:
char const * a;

const char* a; or const char *a;
-> a constant value of a char. It's a pointer to a char. NOT a char.
char a; is a char.

then how bout *const char* a; Not valid.
char* const* a; is valid thow.

will the spaces char* and char * the same ??

Yes.
char * a;
is the same as
char* a;

Spaces doesn't mather as long as you have one space it's a space. The
rest is ignored by the compiler.

[Jens.Toerring]

ByteSurfer <by********@gmail.com> wrote:

some times is am kinda confused.
they like to code char* a;
char *a; is that both are of the same ??
Yes, it doesn't matter if you have white space before or after the '*'.
There's also the third and fourth possibility:

char * a;
char*a;

That shows it doesn't matter at all where and how much white space
you put before ot after the asterisk.

Some people prefer 'char*' to 'char *' because they feel that it
makes it more obvious that the variable to be defined is a pointer,
while others don't like it because they feel that it makes it easier
to overlook that in

char* a, b;

'b' isn't a pointer but a simple char variable despite the '*' after
the 'char'.
and some more is it : *const char a;
-> a pointer of a constant address to a character
No, that's a syntax error. You can't have a '*' at the start when
defining a variable.
const char* a; or const char *a;
-> a constant value of a char.
No, that's a pointer to an array of chars with the attached promise
that you won't change the contents of what the pointer points to.
This is quite useful when you use pointers that point to literal
strings, i.e.

const char *my_hello = "Hello, boys and girls!";

because the compiler may be able to gently remind you you're doing
something stupid when you don't keep your promise, or when you use
this for function arguments to indicate that the function is not
going to change the elements of the array it receives. An example is

char *strcpy( char *dest, const char *src );

This makes it immediately clear that strcpy() will only change the
destination string, but will leave the source string alone. And
again it doesn't matter if you have white space before or after
the '*' or before and after the asterisk or none at all.
then how bout *const char* a;
will the spaces char* and char * the same ??

That's also a syntax error.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Randy Yates]

Je***********@physik.fu-berlin.de writes:

while others don't like it because they feel that it makes it easier
to overlook that in

char* a, b;

'b' isn't a pointer but a simple char variable despite the '*' after
the 'char'.

This is a flaw in the C standard, in my opinion. Logically the "*" is
a modifier of the type. To associate it with the identifier rather
than the type is to confuse its function.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
ra*********@sonyericsson.com, 919-472-1124

[Randy Howard]

In article <xx*************@usrts005.corpusers.net>,
ra*********@sonyericsson.com says...

Je***********@physik.fu-berlin.de writes:

while others don't like it because they feel that it makes it easier
to overlook that in

char* a, b;

'b' isn't a pointer but a simple char variable despite the '*' after
the 'char'.

This is a flaw in the C standard, in my opinion. Logically the "*" is
a modifier of the type. To associate it with the identifier rather
than the type is to confuse its function.

No, it's a flaw in the way people use it.

If they did it correctly, I.e.

char *a, b;

or even better

char *a;
char b;

then it would be obvious. Multiple variables on one line isn't
necessarily lazy, but it does lead to a lot of strange bugs,
particularly for those not already fluent in the language.
--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig

[Keith Thompson]

Randy Yates <ra*********@sonyericsson.com> writes:

Je***********@physik.fu-berlin.de writes:

while others don't like it because they feel that it makes it easier
to overlook that in

char* a, b;

'b' isn't a pointer but a simple char variable despite the '*' after
the 'char'.

This is a flaw in the C standard, in my opinion. Logically the "*" is
a modifier of the type. To associate it with the identifier rather
than the type is to confuse its function.

The principle is that declaration mimics use (more or less). Specifically,

char *a;

means that "*a" is of type char (from which you can infer that a is of
type pointer-to-char). Similarly,

char arr[10];

means that arr[whatever] is of type char (from which you can infer
that arr is of type array-of-char).

Yes, it can be confusing, and if you could only apply a single "*" or
"[...]" to a type name it would be silly, but you need to understand
the principle (or have a copy of the cdecl program) to be able to
decipher things like

void (*signal(int sig, void (*func)(int)))(int);

It's often helpful to avoid putting too many things on one line,
either by declaring only one variable per line or by using
intermediate typedefs.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On 8 Mar 2005 07:30:06 -0800, in comp.lang.c , "ByteSurfer"
<by********@gmail.com> wrote:

some times is am kinda confused.
they like to code

char* a;
char *a;

is that both are of the same ??
yes. C doesn't care where you put the whitespace.

char * a;
is also the same.
and some more is it :

*const char a;
synax error. The * must come AFTER a type.
const char* a; or const char *a;
-> a constant value of a char.
pointer to a char that is const
then how bout *const char* a;
syntax error.
will the spaces char* and char * the same ??

whitespace is ignored.

Read expressions right to left

const char* const x;

"x is a const pointer to a char that is const. "

(I hope....)

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[ByteSurfer]

char chr = 'a'; /* Just another char */
char* pchr = &chr; /* A pointer to the char above */
using only one pointer like as you stated above than using a pointer to
a pointer to a char ... what will be the benifit and what is the use ??

char** ppchr = &pchr; /* A pointer to the pointer to the char */
char*** pppchr = &ppchr; /* A pointer to a pointer to a pointer to a
char */

some more when i am doing a function and then i thought eg.
start(*const char *a); will be valid ..

[Thomas Stegen]

Randy Howard wrote:

No, it's a flaw in the way people use it.

If they did it correctly, I.e.

char *a, b;
That is no more correct than

char* a, b
then it would be obvious. Multiple variables on one line isn't
necessarily lazy, but it does lead to a lot of strange bugs,
particularly for those not already fluent in the language.

Hence it is a problem in the language.

It is the whole declaration mimics use. And it is not really
a very smart thing always.

If, as you say, it is "incorrect" why allow it in the language in the
first place?

--
Thomas.

[Randy Yates]

"ByteSurfer" <by********@gmail.com> writes:

char chr = 'a'; /* Just another char */
char* pchr = &chr; /* A pointer to the char above */

using only one pointer like as you stated above than using a pointer to
a pointer to a char ... what will be the benifit and what is the use ??

Consider, instead of an array of characters (i.e., a "word"), an
array of character strings (i.e., a "paragraph"). Then each element
in the array is not a character but a pointer to the first of an array
of characters, and therefore the identifier (the variable name) of the
array is a pointer to a pointer.

char* word = "country";
char** wordArray = {"Now", "is", "the", "time", "for", "all", "good",
"men", "to", "come", "to", "the", "aid", "of",
"their", "country"};
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
ra*********@sonyericsson.com, 919-472-1124

[Jarno A Wuolijoki]

On Tue, 8 Mar 2005, Randy Yates wrote:

Je***********@physik.fu-berlin.de writes:

while others don't like it because they feel that it makes it easier
to overlook that in

char* a, b;

'b' isn't a pointer but a simple char variable despite the '*' after
the 'char'.

This is a flaw in the C standard, in my opinion. Logically the "*" is
a modifier of the type. To associate it with the identifier rather
than the type is to confuse its function.

If you're ever going to "fix" the flaw (by developing a new language,
bribing the committee, or something..), please don't make it like:
char* a;
but
&char a;
instead.

The odd reverse syntax of C makes sense precisely because you're
declaring that something_that_looks_like_an_expression will be of type
base_type instead of plain_identifier is of some_complex_derived_type.

(of course to get this right with function pointers, you need to have
a syntax for constructing functions on the fly, but that's just a good
thing;)

[Old Wolf]

Thomas Stegen wrote:

Randy Howard wrote:

No, it's a flaw in the way people use it.

If they did it correctly, I.e.

char *a, b;

That is no more correct than

char* a, b

Currently, the order of items in a declaration list doesn't
matter; these are all the same:

char a, b, *c, d();
char d(), b, a, *c;
char *c, d(), a, b;
char b, *c, d(), a;

Are you really suggesting that it would have been better
if one of those lines did something different to the others?

[john_bode]

ByteSurfer wrote:

char chr = 'a'; /* Just another char */
char* pchr = &chr; /* A pointer to the char above */
using only one pointer like as you stated above than using a pointer

to a pointer to a char ... what will be the benifit and what is the use ??
Double indirection comes into play several places. For example, if you
create a function that has to write a pointer value to one of its
parameters, you have to pass a pointer to that pointer. For example,
take the strtol() function in the standard library:

long strtol(const char *str, char **ptr, int base);

What strtol() does is take a string of digit characters pointed to by
str and convert them to the equivalent integral value (e.g., "1234" =>
1,234). It will write the address of the first character that is not a
digit to ptr. Since we're writing to a parameter, we must pass its
address (a pointer value); since that parameter is of type pointer to
char, we must pass a pointer to pointer to char.

You'll also see double and higher indirection when dealing with
multidimensional arrays.

char** ppchr = &pchr; /* A pointer to the pointer to the char */
char*** pppchr = &ppchr; /* A pointer to a pointer to a pointer to a char */

some more when i am doing a function and then i thought eg.
start(*const char *a); will be valid ..

No. What are you trying to convey here? Here are some examples that
may help:

char *a; // a and what it points to are both writeable
const char *a; // a is writeable, what it points to is not
writeable
char * const a; // a is not writeable, what it points to is
writeable
const char * const a; // neither a nor what it points to are writeable

[ByteSurfer]

Randy Yates wrote:

"ByteSurfer" <by********@gmail.com> writes:

char chr = 'a'; /* Just another char */
char* pchr = &chr; /* A pointer to the char above */
using only one pointer like as you stated above than using a pointer to a pointer to a char ... what will be the benifit and what is the

use ??
Consider, instead of an array of characters (i.e., a "word"), an
array of character strings (i.e., a "paragraph"). Then each element
in the array is not a character but a pointer to the first of an array of characters, and therefore the identifier (the variable name) of the array is a pointer to a pointer.

char* word = "country";
char** wordArray = {"Now", "is", "the", "time", "for", "all", "good", "men", "to", "come", "to", "the", "aid", "of",
"their", "country"};

Is that mean when i just have one pointer to a type i will point to the
first memory location of it. when i have type ** identifier ; i will be
pointing to the memory location of it and the memory will contain
another pointer that point to a new identifier.

then it will be the same of
char * word[] = "{...............};
char ** word;

what make the difference between this two?? or the theories behind
using them is just the same .? then in char ** word; how can i know, i
can put in how many elements in it ?

[Keith Thompson]

Thomas Stegen <th***********@gmail.com> writes:

Randy Howard wrote:

No, it's a flaw in the way people use it.
If they did it correctly, I.e.
char *a, b;
That is no more correct than

char* a, b

Of course it's no more or less correct; since the amount of whitespace
is insignificant, they're identical.

It's "incorrect" only if the programmer's intent was to declare both a
and b as pointer-to-char objects. If the intent was to declare a as a
pointer-to-char and b as a char, it's perfectly correct (though it
would be clearer as two separate declarations).

then it would be obvious. Multiple variables on one line isn't
necessarily lazy, but it does lead to a lot of strange bugs,
particularly for those not already fluent in the language.

Hence it is a problem in the language.

It is the whole declaration mimics use. And it is not really
a very smart thing always.

Any declaration scheme is going to have problems in some cases. C's
can be confusing, but it's consistent. Like anything else, you can
use it correctly if and only if you know how. And it cannot be fixed
without either breaking tons of existing code or inventing a new
language that doesn't pretend to be compatible with C.
If, as you say, it is "incorrect" why allow it in the language in the
first place?

No language can prevent logical errors.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Randy Yates]

Keith Thompson <ks***@mib.org> writes:

[...]
No language can prevent logical errors.

Perhaps not, but it can go a long way towards avoiding the types of errors
that humans tend to make.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
ra*********@sonyericsson.com, 919-472-1124

[Thomas Stegen]

Old Wolf wrote:

Currently, the order of items in a declaration list doesn't
matter; these are all the same:

char a, b, *c, d();
char d(), b, a, *c;
char *c, d(), a, b;
char b, *c, d(), a;

Are you really suggesting that it would have been better
if one of those lines did something different to the others?

No, I am really not suggesting that. Do you really believe
I was suggesting that?

--
Thomas.

[Thomas Stegen]

Keith Thompson wrote:

Thomas Stegen <th***********@gmail.com> writes:

If, as you say, it is "incorrect" why allow it in the language in the
first place?

No language can prevent logical errors.

No, but all languages can avoid logical errors (as opposed to
typos or design errors) in type declarations. (Except for C
apparently).

The oncorrect above could only have been meant syntactically,
that is how I interpreted it anyway. If something is seen as
incorrect syntactically and still allowed by the language why
is not a flaw in tha language. (Note that I did not say it
was "incorrect" syntactically, I was mostly complaining about
rather incomplete reasoning.)

--
Thomas.

[Old Wolf]

Thomas Stegen wrote:

Old Wolf wrote:

Currently, the order of items in a declaration list doesn't
matter; these are all the same:

char a, b, *c, d();
char d(), b, a, *c;
char *c, d(), a, b;
char b, *c, d(), a;

Are you really suggesting that it would have been better
if one of those lines did something different to the others?

No, I am really not suggesting that. Do you really believe
I was suggesting that?

Randy Yates wrote:
This is a flaw in the C standard, in my opinion.
Logically the "*" is a modifier of the type. To
associate it with the identifier rather than the
type is to confuse its function.

meaning that he thinks: char* a,b; should mean that a and b
are both (char *).

You wrote (in response to Randy Howard, who debated what
Randy Yates had said):
Hence it is a problem in the language.

So I thought you were agreeing with Randy Yates.

[Arun B]

draw_slice is a function defined as follows!

uint32_t(*draw_slice)(- - arguments of the function draw_slice - - )

What kind of pointer is it going to return?
What is that data type uint32_t ?

[Ben Pfaff]

ar**********@gmail.com (Arun B) writes:

draw_slice is a function defined as follows!

uint32_t(*draw_slice)(- - arguments of the function draw_slice - - )

What kind of pointer is it going to return?
draw_slice() is a pointer to function, not a function returning a
pointer. It returns type uint32_t, not a pointer type.
What is that data type uint32_t ?

In C99, it is a 32-bit unsigned integer type with no padding bits
and a two's complement representation declared in <stdint.h> and
<inttypes.h>.
--
Go not to Usenet for counsel, for they will say both no and yes.

[Keith Thompson]

Thomas Stegen <ts*****@cis.strath.ac.uk> writes:

Keith Thompson wrote:

Thomas Stegen <th***********@gmail.com> writes:

If, as you say, it is "incorrect" why allow it in the language in the
first place? No language can prevent logical errors.

No, but all languages can avoid logical errors (as opposed to
typos or design errors) in type declarations. (Except for C
apparently).

I'll grant you that C's declaration syntax can be confusing. I don't
think it's a fatal flaw in the language. If you understand it well,
you can use it properly; if you don't, there are ways to avoid the
complexity in code you write, and tools to decipher complex
declarations in code you read.
The oncorrect above could only have been meant syntactically,
that is how I interpreted it anyway. If something is seen as
incorrect syntactically and still allowed by the language why
is not a flaw in tha language. (Note that I did not say it
was "incorrect" syntactically, I was mostly complaining about
rather incomplete reasoning.)

The declaration that was said to be "incorrect" was:

char *a, b;

It's not "seen as incorrect syntactically" by anyone who understands
the language well enough.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Thomas Stegen]

Old Wolf wrote:

Thomas Stegen wrote:

Old Wolf wrote:

Currently, the order of items in a declaration list doesn't
matter; these are all the same:

char a, b, *c, d();
char d(), b, a, *c;
char *c, d(), a, b;
char b, *c, d(), a;

[snip]

[snip]
You wrote (in response to Randy Howard, who debated what
Randy Yates had said):
Hence it is a problem in the language.

So I thought you were agreeing with Randy Yates.

I was, that does not imply that think the above lines should
have different semantics.

One way to see the declaration syntax (losely as it is) is that you
declare expression that evaluate to a certain type, char above.

So you say *c evaluates to char. Sort of. I think it would be better
to say:

pointer_to_char_type a,b,c;

Now all the above is of type char* (as it is now). The above can be
achieved using a typedef of course, but we don't like hiding
pointers in typedefs, do we?

--
Thomas.

[Thomas Stegen]

Keith Thompson wrote:

I'll grant you that C's declaration syntax can be confusing. I don't
think it's a fatal flaw in the language. If you understand it well,
you can use it properly; if you don't, there are ways to avoid the
complexity in code you write, and tools to decipher complex
declarations in code you read.
I am not saying it is difficult, just that is not as easy and clear
as it could have been.

The declaration that was said to be "incorrect" was:

char *a, b;
It was

char* a, b;

That was seen as "incorrect" IIRC.

It's not "seen as incorrect syntactically" by anyone who understands
the language well enough.

My point was that if something is not seen as a flaw in the language
it should not be considered "incorrect" either. Do you agree on this
point, (agreeing or disagreeing here has nothing to do with whether
you think the declaration syntax is flawed or not).

--
Thomas.

[CBFalconer]

Thomas Stegen wrote:

.... snip ...
One way to see the declaration syntax (losely as it is) is that you
declare expression that evaluate to a certain type, char above.

So you say *c evaluates to char. Sort of. I think it would be better
to say:

pointer_to_char_type a,b,c;

Now all the above is of type char* (as it is now). The above can be
achieved using a typedef of course, but we don't like hiding
pointers in typedefs, do we?

I think that is an irrational attitude. We hide pointers all the
time with such things as:

char *thingummy;

If we want to emphasise the pointerness we can write:

char *thingptr;

and there is no reason not to do the same things, for the same
reasons, with types by:

typedef char *thingamabob;
or
typedef char *athingptr;

except that now there is no confusion with multiple definition in:

athingptr a, b, c;

all of which are of type athingptr (or thingamabob if desired). It
is all part of decoupling code modules.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Keith Thompson]

Thomas Stegen <th***********@gmail.com> writes:

Keith Thompson wrote:

I'll grant you that C's declaration syntax can be confusing. I don't
think it's a fatal flaw in the language. If you understand it well,
you can use it properly; if you don't, there are ways to avoid the
complexity in code you write, and tools to decipher complex
declarations in code you read.
I am not saying it is difficult, just that is not as easy and clear
as it could have been.

The declaration that was said to be "incorrect" was:
char *a, b;

It was

char* a, b;

Ok, but that's effectively identical (as you know).
That was seen as "incorrect" IIRC.

It's not "seen as incorrect syntactically" by anyone who understands
the language well enough.

My point was that if something is not seen as a flaw in the language
it should not be considered "incorrect" either. Do you agree on this
point, (agreeing or disagreeing here has nothing to do with whether
you think the declaration syntax is flawed or not).

Incorrect in what sense? I don't see the fact that
char* a, b;
declare a as a pointer-to-char and b as a char as a flaw in the
language. Whether that line is (logically) incorrect depends on the
programmer's intent.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Thomas Stegen]

Keith Thompson wrote:

Thomas Stegen <th***********@gmail.com> writes:

Keith Thompson wrote:

The declaration that was said to be "incorrect" was:
char *a, b;

It was

char* a, b;

Ok, but that's effectively identical (as you know).

But the point was made that the correct way was:

char *a, b;

Since the context was the problem of getting types wrong
I assumed it was implied that the following is incorrect:

char* a, b;

The same post said that even though this last one was
incorrect it is not a language flaw. I am saying that
if something incorrect is allowed, then that is a flaw
in itself.

--
Thomas.

[Keith Thompson]

Thomas Stegen <ts*****@cis.strath.ac.uk> writes:

Keith Thompson wrote:

Thomas Stegen <th***********@gmail.com> writes:

Keith Thompson wrote:
The declaration that was said to be "incorrect" was:
char *a, b;

It was

char* a, b;

Ok, but that's effectively identical (as you know).

But the point was made that the correct way was:

char *a, b;

Since the context was the problem of getting types wrong
I assumed it was implied that the following is incorrect:

char* a, b;

The same post said that even though this last one was
incorrect it is not a language flaw. I am saying that
if something incorrect is allowed, then that is a flaw
in itself.

"Incorrect" and "flaw" are largely subjective terms, and I'm not
going to try to define either one.

As far as the language is concerned, the following are all legal
and equivalent:

char *a, b;
char* a, b;
char*a,b;
char * a , b ;

Of these, I consider the first to be good style, and the others to be
poor style. The second, in particular, is misleading -- but then so
is this:

char string_pointer;

but I wouldn't expect a compiler to diagnose any of them. I suppose
you could say they're "incorrect", but not in the context of the
language.

The C language is largely free-form, allowing programmers to format
their code as they like. I don't consider the fact that this allows
for poorly formatted code (see the IOCCC) to be a flaw in the
language, any more than the failure to diagnose the two errors in
this:

printf("helo, world/n");

is a flaw in the language.

C, as the saying goes, gives you enough rope to shoot yourself in the
foot. Decide for yourself whether this is a flaw (and don't expect
more than 50% of programmers to agree with whatever you decide).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
....

language, any more than the failure to diagnose the two errors in
this:

printf("helo, world/n");

is a flaw in the language.

I don't see any errors in that line. It should do exactly what it looks
like it will do.

[Keith Thompson]

ga*****@yin.interaccess.com (Kenny McCormack) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
...

language, any more than the failure to diagnose the two errors in
this:

printf("helo, world/n");

is a flaw in the language.

I don't see any errors in that line. It should do exactly what it looks
like it will do.

I obviously meant errors in the sense that it probably doesn't do what
the author intended. Call them bugs, logical errors, or goofs if you
like. (If the author really intended to misspell "hello" and print
"/n" rather than a newline, then they aren't errors at all.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.