void * vs char *

[Francine.Neary]

I've been reflecting on these two types of pointer. As far as I can
glean from books, void * and char * are functionally equivalent: the
key property of both is that they are pointers that can be faithfully
cast to any other pointer type.

The only difference seems to be that it is legal to perform arithmetic
on a char *, but not on a void *.

So if a char * really is just a more functional void *, why would
anyone ever use a void * in their code, instead of a char *?

[Francine.Neary]

On Mar 19, 10:33 pm, Ian Collins <[e-mail] mwrote:

No, void* serves as a generic pointer, to have char* double up (and
don't forget it used to, before void* was added to the language) adds
complexity.

Surely a language with a superfluous extra pointer type has "more
complexity" than one without??

It's interesting to think - if void * was added to the language, at
the time it was added people must have thought there was a compelling
reason to put it in. It would be interesting to read the discussions
of the Powers That Be from that time to see what the original
rationale was.

[J. J. Farrell]

On Mar 19, 4:50 pm, Francine.Ne...@ googlemail.com wrote:

On Mar 19, 10:33 pm, Ian Collins <[e-mail] mwrote:

No, void* serves as a generic pointer, to have char* double up (and
don't forget it used to, before void* was added to the language) adds
complexity.

Surely a language with a superfluous extra pointer type has "more
complexity" than one without??

It's interesting to think - if void * was added to the language, at
the time it was added people must have thought there was a compelling
reason to put it in. It would be interesting to read the discussions
of the Powers That Be from that time to see what the original
rationale was.

Track down a copy of the original ANSI C Standard - X3.159-1989. The
Rationale for the Committee's decisions is given in the "Rationale"
appendix. The rationale for void * is what people here have been
telling you repeatedly - to distinguish between a 'generic object
pointer' and a 'pointer to char'. To quote from the Rationale for
section 3.2.2.3

"The use of void * ("pointer to void") as a generic object pointer
type is an invention of the Committee. Adoption of this type is
stimulated by the desire to specify function prototype arguments that
either quietly convert arbitrary pointers (as in fread) or complain if
the argument type does not exactly match (as in strcmp)."

As I remember, this was one of the committee inventions which was
broadly welcomed for the clarity and reduction in confusion which it
brought to the language.

[Keith Thompson]

Ian Collins <ia******@hotma il.comwrites:

>[...]

I think you're looking at a copy of the 1990 standard. C99 dropped
implicit int.

Yes, "main()" is legal in C90 (Ian was partly mistaken on that point),
but in my opinion "int main(void)" is better.

Where I'm sitting, C == C99 :)

Ok, given that context, you're correct. (You might want to make that
a bit clearer, but we needn't re-open that debate.)

I see the smiley, but I'm ignoring it because I'm a humorless pedant.

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Fr************@ googlemail.com writes:

On Mar 19, 7:33 pm, Keith Thompson <[e-mail] ote:

>You seem to be arguing that the compiler should shut up about implicit
conversions that don't lose any information; in other words, you want
C's type checking to be even weaker than it is. You're certainly
entitled to that opinion, but it's not one many people share. If you
want a generic pointer type, use void*. There are plenty of
mechanisms that let you be sloppy with types if you do it
deliberately ; *I* want the compiler to warn me if I do it
accidentally .

That's an interesting way to put it. Maybe that's what's happening -
I've been forced to use Java for the last couple of years, which has
this horrible over-bearing strict typing, so maybe I'm reacting
against that now and trying to push the liberating flexibility that C
gives me...

However, I'm not completely sure it should be the job of the compiler
and not some optional lint tool to pick through my code for places
where I might just have meant something else.

There are limits to how much I'm willing to trust the compiler to
figure out what I actually meant.

In particular, if I have a function that expects a char* argument, and
I call it with a struct foo* argument, that's a constraint violation.
The compiler shouldn't try to guess that I meant to insert a cast, and
quietly do the conversion for me implicitly. Such a guess would be
wrong; it's far more likely that what I *meant* to do was write
correct code in the first place.

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.

In most other languages I've used, there's no separate "lint" tool;
the compiler does all the checking (and may have an option to control
how strict it is).

I won't go beyond that because I don't want to start a language war.

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Fr************@ googlemail.com writes:

On Mar 19, 10:33 pm, Ian Collins <[e-mail] mwrote:

>No, void* serves as a generic pointer, to have char* double up (and
don't forget it used to, before void* was added to the language) adds
complexity.

Surely a language with a superfluous extra pointer type has "more
complexity" than one without??

[...]

No, I don't think it does.

C has the concept of a generic pointer type and the concept of a
pointer-to-character type. Using the same name for both of these
concepts doesn't reduce the complexity; it merely makes the existing
complexity more difficult to deal with.

strlen() takes a char* argument. Suppose I have an abstract type that
represents a dynamic string, and it's represented as a pointer. If I
accidentally call strlen() with one of my dynamic_string pointers, I
want the compiler to tell me I've made a mistake.

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Jack Klein]

On Mon, 19 Mar 2007 19:35:07 +0000, Richard Heathfield
<rj*@see.sig.in validwrote in comp.lang.c:

Fr************@ googlemail.com said:

On Mar 19, 10:39 am, Ian Collins <[e-mail] mwrote:

Francine.Ne...@ googlemail.com wrote:

<snip>

#include <stdio.h>

Let's start by making it legal C:

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

main()
int main(void)

???

main() is perfectly valid C - it defines main to be a function taking
no arguments and returning int.

Agreed. (In C99, it has to be int main() at the very least, but in C90
main() is legal.)

You may have a personal preference for
the more verbose form,

Yes. Adding the return type makes it C99-conforming, and using the
prototype form is good style, but these are choices, not requirements.

<rant>

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

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?

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

A responsible professional programmer always has coding requirements,
whether they are the policy of the organization he/she works for, or
self-imposed.

It is possible even today that a professional C programmer has to
write or maintain code for a pre-standard compiler which does not
accept prototypes in declarations and definitions.

Other than that remote scenario, 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.

There are many reasons why so many software/firmware projects these
days are late, cancelled, seriously over budget, and/or riddled with
defects. Many of those reasons are beyond the control of the
programmer, but several of the major ones are not.

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. Of course that does not
apply to the majority of clc regulars, but we hardly represent the
average C programmer.

And the majority of programmers, regardless of language, do not know
who their real customer is. It is not the manager, the company, the
client, even the user. The real customer of computer source code is
programmers, whether it is the author at some time in the future, a
maintenance programmer who has to update the code, or participants in
code inspections.

There are very true "matters of style" in C programming. As an
example, where to put the braces is one of them, absent an
organization's coding guide. Whether to put in optional braces, is
not.

Sadly, one of the greatest impediments to better software is
programmers' egos.

</rant>

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Ian Collins]

Keith Thompson wrote:

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

My experience was similar.

C's use of void* as a generic pointer type is an elegant solution to the
problem faced by all typed languages, writing a generic function.
My recent work has been split between four languages, C++, C, PHP and
JavaScript listed in order of "type strictness". At one extreme, a
strongly typed language requires a combination of function overloading
and generics and at the other, there isn't any type checking at all. C
fits in the middle, rudimentary type checking and a simple, elegant,
solution to the generic function: void*.

--
Ian Collins.

[Richard Heathfield]

Jack Klein said:

On Mon, 19 Mar 2007 19:35:07 +0000, Richard Heathfield
<rj*@see.sig.in validwrote in comp.lang.c:

<snip>

>>
Yes. Adding the return type makes it C99-conforming, and using the
prototype form is good style, but these are choices, not
requirements .

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

Fr************@ googlemail.com wrote:

On Mar 19, 12:11 am, Ian Collins <[e-mail] mwrote:

>To avoid casting every assignment of something other than a char*
to and from a char*.

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

No you don't. See modification below.

>
#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)
{

struct s *ps;

ps = p; /* alternatively use local initialization */
printf("%d\n", ps->a); /* look ma, no casts */

printf("%d\n",p->a);
}

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Keith Thompson wrote:

>

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

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

--
Posted via a free Usenet account from http://www.teranews.com