A C without void*

[Spiros Bousbouras]

Why does C have void* ? Imagine a C' where the functionality that void*
provides would be provided instead by unsigned char* plus what
unsigned char* usually does. In what way would C' be inferior to C ?

 

[Dr Nick]

Why does C have void* ? Imagine a C' where the functionality that void*
provides would be provided instead by unsigned char* plus what
unsigned char* usually does. In what way would C' be inferior to C ?

Imagine? Some of us remember it! (modulo the "unsigned" bit).

 

[Lauri Alanko]

Why does C have void* ? Imagine a C' where the functionality that void*
provides would be provided instead by unsigned char* plus what
unsigned char* usually does. In what way would C' be inferior to C ?

A void pointer can be converted without an explicit cast (though this
is as much a pitfall as a convenience). Also, a void pointer cannot be
dereferenced or used in pointer arithmetic, so some errors are
detected that would go unnoticed if char pointers were used.


Lauri

 

[Ben Pfaff]

Why does C have void* ? Imagine a C' where the functionality that void*
provides would be provided instead by unsigned char* plus what
unsigned char* usually does. In what way would C' be inferior to C ?

C' would require more casts.

 

[Ian Collins]

Why does C have void* ? Imagine a C' where the functionality that void*
provides would be provided instead by unsigned char* plus what
unsigned char* usually does. In what way would C' be inferior to C ?

I guess you haven't been programming in C long enough to remember K&R C?

 

[Keith Thompson]

Why does C have void* ? Imagine a C' where the functionality that void*
provides would be provided instead by unsigned char* plus what
unsigned char* usually does. In what way would C' be inferior to C ?

It would fail to distinguish between a pointer that points to data
whose type is not explicitly stated, and a pointer that points to
character data. (See pre-ANSI K&R C.)

 

[J. J. Farrell]

Why does C have void* ? Imagine a C' where the functionality that void*
provides would be provided instead by unsigned char* plus what
unsigned char* usually does. In what way would C' be inferior to C ?

Why imagine it when we can remember it? Many of us used it for years
(give or take 'unsigned'), it's possible that some still do - some
certainly have to work with code which suffers from the legacy. We
remember what an improvement the addition of void was, both for the
documentary effect of explicitly having a pointer to 'something
unspecified' as distinct from a pointer to char, and also for how it got
rid of so many ugly casts.

 

[Nobody]

Why does C have void* ? Imagine a C' where the functionality that void*
provides would be provided instead by unsigned char* plus what
unsigned char* usually does. In what way would C' be inferior to C ?

Having void* allows the programmer to specify that the type of data to
which the pointer points is unspecified, rather than having to lie to keep
the compiler happy.

 

[Ian Collins]

But if you read actual C++ code in the wild, it's thick with explicit casts.
In fact, so much so that one would think the design must somehow
fundamentally encourage it.

Not in mine you wont. I hardly see any in other people's code I work
with either.

 

[Gerald Breuer]

Am 20.03.2011 21:00, schrieb Spiros Bousbouras:

Why does C have void* ? Imagine a C' where the functionality that
void* provides would be provided instead by unsigned char* plus
what unsigned char* usually does. In what way would C' be inferior
to C ?

C isn't a idiot-proof lange in any way so dropping void * wouldn't
make a significant change.

 

[Spiros Bousbouras]

C' would require more casts.

When I say "the functionality that void* provides would be provided
instead by unsigned char*" I include automatic conversions.

 

[Spiros Bousbouras]

I guess you haven't been programming in C long enough to remember K&R C?

No I haven't so I was hoping for some historical knowledge or insights.
For example were there any discussions , perhaps here , on adding void ?
Were there any compilers which were offering void as an extension before
it was standardised ? Were people committing bugs and thinking "if only
I had void this wouldn't have happened" ?

 

[Ben Pfaff]

When I say "the functionality that void* provides would be provided
instead by unsigned char*" I include automatic conversions.

C' would be less type-safe, then.

 

[lawrence.jones]

No I haven't so I was hoping for some historical knowledge or insights.
For example were there any discussions , perhaps here , on adding void ?
Were there any compilers which were offering void as an extension before
it was standardised ? Were people committing bugs and thinking "if only
I had void this wouldn't have happened" ?

There were extensive discussions in the original ANSI C committee. void
by itself already existed in C++ and was generally regarded as a good
idea. void * was, as I recall, a C committee invention to fill the need
for a "generic" pointer that freely converts to and from other pointer
types to allow for library functions like free() and memcpy() to be used
without requiring casts while still preserving type safety for the other
pointer types.

 

[Morris Keesan]

There were extensive discussions in the original ANSI C committee. void
by itself already existed in C++ and was generally regarded as a good
idea. void * was, as I recall, a C committee invention to fill the need
for a "generic" pointer that freely converts to and from other pointer
types to allow for library functions like free() and memcpy() to be used
without requiring casts while still preserving type safety for the other
pointer types.

void existed in the C compiler in Unix System V, which I think was
before the ANSI standardization effort. I don't remember (void *) in
that compiler.

 

[Eric Sosman]

When I say "the functionality that void* provides would be provided
instead by unsigned char*" I include automatic conversions.

So you're really talking about a C without char*, but plus
the gcc extension for void* arithmetic and a spelling change?

(Okay, I'm mocking you -- but not an awful lot! It's just my
impatience with "Consider proposal X" without a statement of X and
with details dribbled out over time... Ugh.)

 

[Spiros Bousbouras]

No I haven't so I was hoping for some historical knowledge or insights.
For example were there any discussions , perhaps here , on adding void ?
Were there any compilers which were offering void as an extension before
it was standardised ? Were people committing bugs and thinking "if only
I had void this wouldn't have happened" ?

There were extensive discussions in the original ANSI C committee. void
by itself already existed in C++ and was generally regarded as a good
idea. void * was, as I recall, a C committee invention to fill the need
for a "generic" pointer that freely converts to and from other pointer
types to allow for library functions like free() and memcpy() to be used
without requiring casts while still preserving type safety for the other
pointer types.[/QUOTE]

So the committee introduced a new pointer type out of the blue. Wow ,
that's a bold move. Certainly bolder than adding a depth argument to
continue or break which was not done. From the C99 rationale:

6.8.6.2 The continue statement

The C89 Committee rejected proposed enhancements to continue
and break which would allow specification of an iteration
statement other than the immediately enclosing one on grounds
of insufficient prior art.

 

[Spiros Bousbouras]

So you're really talking about a C without char*, but plus
the gcc extension for void* arithmetic and a spelling change?

(Okay, I'm mocking you -- but not an awful lot! It's just my
impatience with "Consider proposal X" without a statement of X and
with details dribbled out over time... Ugh.)

Some questions are more useful if they are open ended.

 

[Keith Thompson]

There were extensive discussions in the original ANSI C committee. void
by itself already existed in C++ and was generally regarded as a good
idea. void * was, as I recall, a C committee invention to fill the need
for a "generic" pointer that freely converts to and from other pointer
types to allow for library functions like free() and memcpy() to be used
without requiring casts while still preserving type safety for the other
pointer types.

So the committee introduced a new pointer type out of the blue. Wow ,
that's a bold move. Certainly bolder than adding a depth argument to
continue or break which was not done. From the C99 rationale:

6.8.6.2 The continue statement

The C89 Committee rejected proposed enhancements to continue
and break which would allow specification of an iteration
statement other than the immediately enclosing one on grounds
of insufficient prior art.[/QUOTE]

Adding a depth argument, in my opinion, would have been a really bad
way to implement multi-level breaks. It would make far more sense
for continue and break to take a *label* as an optional argument.
(There's ample precedent for that in other languages.)

Still, if you're arguing that the committee shouldn't have added void*,
I'll just say that I disagree; in hindsight, it's worked out quite well.

 

[Spiros Bousbouras]

[...]

So the committee introduced a new pointer type out of the blue. Wow ,
that's a bold move. Certainly bolder than adding a depth argument to
continue or break which was not done. From the C99 rationale:

6.8.6.2 The continue statement

The C89 Committee rejected proposed enhancements to continue
and break which would allow specification of an iteration
statement other than the immediately enclosing one on grounds
of insufficient prior art.

Adding a depth argument, in my opinion, would have been a really bad
way to implement multi-level breaks. It would make far more sense
for continue and break to take a *label* as an optional argument.
(There's ample precedent for that in other languages.)

It wouldn't be ideal but I wouldn't call it "really bad". There would
be a potential for bugs but one can have much more insidious bugs in C.
I agree it would make more sense to have labeled loop statements but
for that you would have to change the syntax of for , while , etc.
which would break existing code.

Still, if you're arguing that the committee shouldn't have added void*,

Not at all , I was merely expressing surprise that they made the bold
change despite lack of prior art but not the relatively timid change
which they justified on the basis of insufficient prior art.