Pointers

[Thomas Stegen]

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

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

 

[Old Wolf]

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]

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

 

[Keith Thompson]

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.

 

[Thomas Stegen]

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

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

 

[CBFalconer]

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

 

[Keith Thompson]

I am not saying it is difficult, just that is not as easy and clear
as it could have been.


It was

char* a, b;

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

That was seen as "incorrect" IIRC.


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.

 

[Thomas Stegen]

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.

 

[Keith Thompson]

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

 

[Kenny McCormack]

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]

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