void * vs char *

[Stephen Sprunk]

Maybe you're right! I guess the issue I have is that I'm not really
convinced that void * should exist at all. I mean, char * can double
up perfectly well as both a pointer to char and a "generic pointer",
but for some reason if you work with char * you need to do a lot of
extra explicit casting.

All casting is explicit. The reason you have to cast a char* to other
things is because you've told the compiler you have a pointer to char; if
you want to use it for something else, you have to make that clear. OTOH,
when you use a void* you're telling the compiler you have a pointer to
something unknown, and converting that to, say, a pointer to int doesn't
need a cast.

When you "double up" on the meaning of constructs, you're introducing
ambiguity, and ambiguity breeds bugs. Differentiating between char* and
void* allows you to remove ambiguity, and that's always a good thing.

At the very least, there seems to be a lot of duplication between
the function of void * and char *, whereas I always think minimality
and efficiency is a virtue.

And the supposed duplication you speak of was intentionally added to C due
to the problems with using char* for pointers to things other than chars.
Not needing to cast a void* improves programmer efficiency and code
maintainability by making the intent clearer. Remember, the primary
audience for your code is other programmers (or even yourself), not the
compiler.

S

 

[CBFalconer]

.... snip ...

When I was first exposed to C (many many years ago), I was horrified
by how lax it was about certain things (I called a function with the
wrong number of arguments, and the compiler didn't complain). That
particular problem is largely solved by prototypes, but I still see
C as an extremely permissive language. Flexibility is good, but
failure to diagnose obvious errors is not.

I somewhat parallel your experience. Before C89 appeared I
absolutely refused to use it, because of its insecurities. At
least I could see exactly what was going on in assembly. All else
used Pascal.

 

[Richard Heathfield]

Jack Klein said:

<rant>

I have absolutely no idea why you persist in your anti-C99 crusade.

I don't know what makes you think I'm anti-C99. For example, I take
great care to ensure that all the new code I produce is C99-conforming
so that, when - or rather *if* - it eventually becomes mainstream, I
won't have a bunch of re-work to do.

Have you tried putting the effort into lobbying the suppliers of the
compilers you use, instead of putting it into denigrating those who
point out the latest standard?

I have not denigrated anyone for pointing out the latest standard. In
the very article to which you replied, I myself was pointing out the
latest standard. I think you may have replied in haste, Jack.

As for lobbying compiler suppliers, why bother? I have no particular axe
to grind with regard to C99. I see no particular need for it, but if it
ever happens I'll be ready. Why trouble myself to hurry along a change
that I consider pointless? If those who want C99 to become a reality
can't persuade their compiler suppliers to provide conforming C99
implementations, why should those same suppliers listen to those who
don't care either way?

As for the use of prototype form being "good style" and not a
requirement, your attitude is questionable at best, dangerous at
worst.

My attitude is that prototypes are good style but not required by the
language. This is the simple truth. I use prototypes myself, I advocate
them, I recommend them, and I wholeheartedly endorse them - but they
are *not* required by the rules of C. To claim otherwise would be
questionable at best, dangerous at worst.

[...] any C programmer who chooses to write
non-prototype function declarations and definitions, rejecting the
single most important language improvement in almost 25 years of
standardization efforts, is either ignorant or an egotistical prima
donna.

Nevertheless, it is not a requirement of the language.

The majority of programmers (software engineers, whatever) do not
actually know the standard and specification of their programming
language, whether it is C or anything else.

Then I suggest they learn. And one thing they need to learn is the
difference between a requirement and a recommendation. Prototypes are a
very, very good and important feature of C, and it is very, very, very
good style to use them, because they are such a boon to the compiler's
type-checking of arguments. But they are *not* a requirement.

<snip>

 

[Francine.Neary]

As for the use of prototype form being "good style" and not a
requirement, your attitude is questionable at best, dangerous at
worst.

Sorry I've set off this firestorm!

I think Jack Klein has got the wrong end of the stick here. My own
opinion is that prototypes are an extremely useful device, and I
certainly use them most of the time. However, the discussion here had
been about main(), and the things in issue were whether it's better to
explicitly say main() returns int, and whether it's better to define
main(void) to make intentions clearer than main(). So prototyping
isn't really relevant - after all, I don't think anyone would go so
far as to include a prototype for main!

 

[Keith Thompson]

Sorry I've set off this firestorm!

I think Jack Klein has got the wrong end of the stick here. My own
opinion is that prototypes are an extremely useful device, and I
certainly use them most of the time. However, the discussion here had
been about main(), and the things in issue were whether it's better to
explicitly say main() returns int, and whether it's better to define
main(void) to make intentions clearer than main(). So prototyping
isn't really relevant - after all, I don't think anyone would go so
far as to include a prototype for main!

"int main(void)" is a prototype, even if it's part of the definition
of main (i.e., immediately followed by '{'). A definition is a
declaration; a prototype is a function declaration that includes the
types of the parameters (none, in this case).

A *separate* prototype for main is rarely useful.

 

[Richard Heathfield]

(e-mail address removed) said:

I don't think anyone would go so
far as to include a prototype for main!

I always do. If I'm taking args, it's unavoidable anyway, and even if
I'm not, it's only four characters more, for heaven's sake:

 

[Francine.Neary]

(e-mail address removed) said:


I always do. If I'm taking args, it's unavoidable anyway, and even if
I'm not, it's only four characters more, for heaven's sake:

Ah, sorry, I meant a prototype separate from the function definition.
It seems to me this is definitely unneeded, as the compiler knows
there are only two possible signatures for main, and if main is called
before its definition appears then there can never be any doubt which
is the right one to pick: one takes arguments and the other doesn't.

 

[blufox]

I don't really follow this argument about minimizing number of casts.
For example, the following code fails - I still need to explicitly
cast p to a (struct s*) to avoid a compile-time error.

#include <stdio.h>

void call(void *);
struct s { int a; };

main()
{
struct s a;
a.a=1234;
call(&a);
return 0;

}

void call(void *p)
{
printf("%d\n",p->a);

warning i guess here.
p->a without telling compiler what kind of pointer is p is not legal.
if you want to use void * like this make it

void call(void *p)
{
struct s* t = p;
printf("%d\n",t->a);
}

This is the correct way i guess.

CMIIW
--psr

}

 

[¬a\\/b]

That's C89/C90; C99 deprecated implicit int. There's no reason, short of
laziness, to leave off the int, and there's reason enough not to just to be
compatible with C99 if you ever end up with a compiler that supports it

BTW, go grab a copy of n1124.pdf; that'll be more useful to you than a bunch
of dead trees since it's searchable, and if you lose it you just burn a few
more bits instead of having to pay the library...


Any decent compiler will end up generating the exact same code for both
snippets. However, one is easier to understand and less likely to contain
bugs.

Remember that the primary audience for code is _not_ the compiler but rather
the coder who has to maintain the project after you. Clarity and
correctness are all that is important for 99% of code, and brevity is not
only irrelevant but also counter-productive.

i can see clear you on above have wrong