Is it possible to make void * safer? | Bytes (2024)

I was just thinking about the virtues of C vs. C++ wrt. ADT/generic
programming. The biggest complaint about writing container libraries for
ADTs is that void * offers no type safety. Does it really have to be this
way?

Couldn't you for instance track an object's accesses with void pointers and
ensure they are used consistently across calls?

---------

typedef struct {
size_t count;
/* ... */
void *data;
} array_t;

int array_push(arra y_t *array, void *data);
void *array_pop(arra y_t *array);

---------

Based on these two interface functions, we can on an individual object of
type array_t track that the parameter passed to push() has the same type as
the one to which you would assign from the pop() function.

Of course, for functions that take multiple void arguments or use void
arguments in inconsistent ways, we would need to track how those arguments
are used and are eventually assigned/read to/from the members of type
array_t.

This would appear to work in theory for code in which you have all the
source files available. It falls apart however when you only have a header
file as a specification for a pre-compiled library. I suppose since the
parameter identifiers are optional in function prototypes that you might be
able to divine something if the programmer elects to use some sort of
predictable naming for the void arguments.

At any rate, it was just a random thought. My idea is full of holes but it
was at least in the spirit of C :)

Thanks,

-Clint

Subscribe Reply

Ian Collins wrote:

we******@gmail. com wrote:

You probably could simulate this is C with a struct comprising function
pointers defined within a macros, something like:

#define X( type ) \
typedef struct xX##type { \
void (*push)( array_t*, type ); \
} X##type; \
void push##type##( array_t* array, type data ) { \
array_push( array, (void*)data); }
Well this means that the data is getting implicitely copied into from
the call site to the local parameter. The cast to (void *) looks
wrong, I think you mean: (void *)&data, but you're still getting 1
shallow copy (suppose <type> is a struct.)

Actually, it should have been 'type* data )' in the function definition,
I was assuming type was a struct.

Well, then x.push (array, <any pointer>) is not going to be properly
type checked.

#define GET_X( type, name ) \
X##type name; \
name.push = push##type;

I'm not sure what you're gaining from this function pointer abstraction
since you are requiring, specifically "push##type " to exist in file
scope.

The ability to create an instance of the object, as illustrated by the
example push in my original post.

I was specifically demonstrating how to mimic template in C with macros.

Well, you are also using function pointers. This is a performance
concession, especially if you allow it to have an external interface --
then the compiler can't be "smart", and you eat the indirect function
call cost.

I think my way works best in practice, *except* for the fact that when
you build many of them for various types, the lack of type safety so
easily leads to utter chaos. Unless you run it through a C++ compiler,
but then its just ironic.

That's why I added the function pointers, they are type safe.

Uhhm ... not on the C compilers I use. In fact, I encourage a related
function pointer abuse in Bstrlib (though, I don't require it -- you
can be to the letter if you want; and they are cases where no real
system is actually going to go wrong) for some cases, and it doesn't
come up as an issue.
From what I can tell, pointers are basically never checked by the

compilers -- they take the attitude that all pointers are the same (or
that the programmer knows what s/he's doing), and this includes
function pointer parameters. You have to actually dereference before
you get an error. Obviously you can't get away with this in C++.

I'll check this all again when I get access to a compiler again (I am
not near that kind of a system right now) but I'm pretty sure
contemporary modern C compilers all just screw you on this issue. (The
question is -- is this a "NULLStone" compliance issue, or what? -- Why
do *ALL* the C compilers screw you on this?)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

we******@gmail. com wrote:

I'm not sure what you're gaining from this function pointer abstraction
since you are requiring, specifically "push##type " to exist in file
scope.
The ability to create an instance of the object, as illustrated by the
example push in my original post.

I was specifically demonstrating how to mimic template in C with macros.

Well, you are also using function pointers. This is a performance
concession, especially if you allow it to have an external interface --
then the compiler can't be "smart", and you eat the indirect function
call cost.

Agreed, that's one big hit when simulating templates over using C++
templates. C++ compiles will inline the trivial wrapper functions.

I think my way works best in practice, *except* for the fact that when
you build many of them for various types, the lack of type safety so
easily leads to utter chaos. Unless you run it through a C++ compiler,
but then its just ironic.

That's why I added the function pointers, they are type safe.

Uhhm ... not on the C compilers I use. In fact, I encourage a related
function pointer abuse in Bstrlib (though, I don't require it -- you
can be to the letter if you want; and they are cases where no real
system is actually going to go wrong) for some cases, and it doesn't
come up as an issue.

Yes it will complain, based on my earlier macros:

#define X( type ) \
typedef struct xX##type { \
void (*push)( array_t*, type ); \
} X##type; \
\
void push##type##( array_t* array, type data ) { \
array_push( array, data); }

#define GET_X( type, name ) \
X##type name; \
name.push = push##type;

typedef int* intp;

X(intp)

int main()
{
GET_X( intp, x );

array_t array;
int n = 0;
float f = 0.0;
x.push( &array, &n );
x.push( &array, &f );
}

Will generate warnings for x.push( &array, &f );

--
Ian Collins.

we******@gmail. com writes:
[...]

From what I can tell, pointers are basically never checked by the
compilers -- they take the attitude that all pointers are the same (or
that the programmer knows what s/he's doing), and this includes
function pointer parameters. You have to actually dereference before
you get an error. Obviously you can't get away with this in C++.

I'll check this all again when I get access to a compiler again (I am
not near that kind of a system right now) but I'm pretty sure
contemporary modern C compilers all just screw you on this issue. (The
question is -- is this a "NULLStone" compliance issue, or what? -- Why
do *ALL* the C compilers screw you on this?)

void foo(void)
{
int *ip;
float *fp;
ip = fp;
fp = ip;
}
% gcc -c tmp.c
tmp.c: In function `foo':
tmp.c:5: warning: assignment from incompatible pointer type
tmp.c:6: warning: assignment from incompatible pointer type

Show us an example that you think *ALL* C compilers screw you on.

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

Ian Collins wrote:

we******@gmail. com wrote:

I think my way works best in practice, *except* for the fact that when
you build many of them for various types, the lack of type safety so
easily leads to utter chaos. Unless you run it through a C++ compiler,
but then its just ironic.

That's why I added the function pointers, they are type safe.

Uhhm ... not on the C compilers I use. In fact, I encourage a related
function pointer abuse in Bstrlib (though, I don't require it -- you
can be to the letter if you want; and they are cases where no real
system is actually going to go wrong) for some cases, and it doesn't
come up as an issue.

Yes it will complain, based on my earlier macros:

#define X( type ) \
typedef struct xX##type { \
void (*push)( array_t*, type ); \
} X##type; \
\
void push##type##( array_t* array, type data ) { \
array_push( array, data); }

#define GET_X( type, name ) \
X##type name; \
name.push = push##type;

typedef int* intp;

X(intp)

int main() {
GET_X( intp, x );

array_t array;
int n = 0;
float f = 0.0;
x.push( &array, &n );
x.push( &array, &f );
}

Will generate warnings for x.push( &array, &f );

Have you tried it? After adding in a return 0; MSVC 6.0 says there are
no problems at its highest warning level. I'll check it with Intel,
Watcom, Borland, and gcc in a couple days, but my recollection is that
only Intel at its very highest warning level says anything -- but
Intel's highest warning level is annoying (it tells you strlen(s) +
strlen(t) is suspect because strlen could be overridden and have a side
effect and the + operation does not guarantee order) and I think a lot
of people dial it down at least one level from the highest, at which
point we lose this warning.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

we******@gmail. com writes:

Ian Collins wrote:

[...]

Yes it will complain, based on my earlier macros:

#define X( type ) \
typedef struct xX##type { \
void (*push)( array_t*, type ); \
} X##type; \
\
void push##type##( array_t* array, type data ) { \
array_push( array, data); }

#define GET_X( type, name ) \
X##type name; \
name.push = push##type;

typedef int* intp;

X(intp)

int main() {
GET_X( intp, x );

array_t array;
int n = 0;
float f = 0.0;
x.push( &array, &n );
x.push( &array, &f );
}

Will generate warnings for x.push( &array, &f );

Have you tried it? After adding in a return 0; MSVC 6.0 says there are
no problems at its highest warning level. I'll check it with Intel,
Watcom, Borland, and gcc in a couple days, but my recollection is that
only Intel at its very highest warning level says anything -- but
Intel's highest warning level is annoying (it tells you strlen(s) +
strlen(t) is suspect because strlen could be overridden and have a side
effect and the + operation does not guarantee order) and I think a lot
of people dial it down at least one level from the highest, at which
point we lose this warning.

I'm surprised you got far enough to get any warnings. When I compiled
the above code with gcc, I got:

tmp.c:15: error: parse error before '*' token
tmp.c:15:1: pasting "pushintp" and "(" does not give a valid preprocessing token
tmp.c:15: error: parse error before '*' token

followed by a cascade of other errors.

Getting rid of the macros and stripping down the program, I tried
this:

void push_int(int *ptr)
{
/* ... */
}

int main(void)
{
struct {
void (*push)(int*);
} x;
x.push = push_int;
int n = 0;
float f = 0.0;
x.push( &n );
x.push( &f ); /* This is line 15 */
return 0;
}

"gcc -c tmp.c" gave me:

tmp.c: In function `main':
tmp.c:15: warning: passing arg 1 of pointer to function from incompatible pointer type

(This was without any arguments to increase the warning level.)

If you're using a compiler that doesn't at least warn you about this
kind of type mismatch, get a better compiler.

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

we******@gmail. com wrote:

Will generate warnings for x.push( &array, &f );

Have you tried it? After adding in a return 0; MSVC 6.0 says there are
no problems at its highest warning level.

Well it should. That's a rather old and non-compliant compiler.

Sun cc (normal warnings) gives:

"/tmp/x.c", line 28: warning: argument #2 is incompatible with prototype:
prototype: pointer to int : "unknown", line 0
argument : pointer to float

gcc (normal warnings) gives:

/tmp/x.c: In function `main':
/tmp/x.c:28: warning: passing arg 2 of pointer to function from
incompatible pointer type

--
Ian Collins.

Keith Thompson wrote:

I'm surprised you got far enough to get any warnings. When I compiled
the above code with gcc, I got:

tmp.c:15: error: parse error before '*' token
tmp.c:15:1: pasting "pushintp" and "(" does not give a valid preprocessing token
tmp.c:15: error: parse error before '*' token

Interesting, gcc4 gives the error, gcc3 does not.

Which is correct and if it's gcc4, how does one use the preprocessor to
build a function prototype?

--
Ian Collins.

Ian Collins <ia******@hotma il.com> writes:

Keith Thompson wrote:

I'm surprised you got far enough to get any warnings. When I
compiled
the above code with gcc, I got:
tmp.c:15: error: parse error before '*' token
tmp.c:15:1: pasting "pushintp" and "(" does not give a valid preprocessing token
tmp.c:15: error: parse error before '*' token

Interesting, gcc4 gives the error, gcc3 does not.

Which is correct and if it's gcc4, how does one use the preprocessor
to build a function prototype?

The first thing I'd do is drop the unnecessary ## operator that tried
to join an identifier to a '('. When I tried that with the posted
program, I got other errors that I didn't bother to track down.

To summarize: I don't know.

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

Keith Thompson wrote:

Ian Collins <ia******@hotma il.com> writes:

Keith Thompson wrote:

I'm surprised you got far enough to get any warnings. When I
compiled
the above code with gcc, I got:
tmp.c:15: error: parse error before '*' token
tmp.c:15:1 : pasting "pushintp" and "(" does not give a valid preprocessing token
tmp.c:15: error: parse error before '*' token

Interesting , gcc4 gives the error, gcc3 does not.

Which is correct and if it's gcc4, how does one use the preprocessor
to build a function prototype?

The first thing I'd do is drop the unnecessary ## operator that tried
to join an identifier to a '('. When I tried that with the posted
program, I got other errors that I didn't bother to track down.

You're right, removing the unnecessary ## fixes the error. It was
redundant anyway.

Adding

typedef int array_t;
extern int array_push(arra y_t *array, void *data);

to the top of the file as a kludge will remove any remaining errors.

--
Ian Collins.

Ian Collins wrote:

Keith Thompson wrote:

Ian Collins <ia******@hotma il.com> writes:

Keith Thompson wrote:
I'm surprised you got far enough to get any warnings. When I
compiled
the above code with gcc, I got:
tmp.c:15: error: parse error before '*' token
tmp.c:15:1 : pasting "pushintp" and "(" does not give a valid preprocessing token
tmp.c:15: error: parse error before '*' token

Interesting , gcc4 gives the error, gcc3 does not.

Which is correct and if it's gcc4, how does one use the preprocessor
to build a function prototype?

The first thing I'd do is drop the unnecessary ## operator that tried
to join an identifier to a '('. When I tried that with the posted
program, I got other errors that I didn't bother to track down.

You're right, removing the unnecessary ## fixes the error. It was
redundant anyway.

Adding

typedef int array_t;
extern int array_push(arra y_t *array, void *data);

to the top of the file as a kludge will remove any remaining errors.

I have implemented the whole shehbang here:

http://www.pobox.com/~qed/gstack.zip

The ## rules are annoying, and I find that in general, the way to deal
with them is to wrap that whole thing in a two-level macro itself (it
works, so long as we don't care about namespace invasion).

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/