[comp.lang.c] generic pointers without ANSI C

friedl@vsi.UUCP (Stephen J. Friedl) (02/24/88)

Netpeople,

     We run SVR3 on a 3B2 and wish we had an ANSI C compiler [I
know there aren't any yet, but you know what I mean :-) ].  We
are anxiously waiting the day when this will be available and are
trying to stick with the spirit of ANSI as much as we can.

     One of the many attractions for us will be void * pointers
that can point to any kind of object.  We occasionally write rou-
tines that are passed a pointer to some kind of data along with
an indication of the type.  With a void pointer, lint will be
quiet about it and force you to cast it to the type you want.

     On our machine, void pointers get complaints galore from
lint -- it objects about argument mismatches and says that the
variables so declared are undefined.

     We are thinking of how to get around this.  Obviously, char
* pointers will work but declaring them this way loses a little
bit of self-documentation -- it would be nice to know by the de-
claration that there is no implicit type.

     We thought of doing:

        #define generic char

(or a typedef, I suppose) in our local standard #include file and
using this in our code:

        printdata(pdata, type)
        generic *pdata;         /* this is the guy */
        int     type;
        {
                ...

     Presumably we could do "#define generic void" on an ANSI
compiler and retain backwards self-documentation.

     What are your thoughts on this?  We don't necessarily feel
strongly about this particular way of doing things so please no
flames on how silly we are to change around the language.  I am
aware of the "if you change the compiler with macros then every-
body will have to know your #include file" concerns and appreci-
ate them: alternate suggestions of doing this kind of thing
would be appreciated.  Finally, if my understanding of the pro-
posed standard is lacking I would like to hear about it as well.
I have a very old draft (April 30, 1985) and I know lots has
changed since then.

     Please send e-mail and I'll summarize if requested.

     Steve
-- 
Life : Stephen J. Friedl @ V-Systems Inc/Santa Ana, CA     *Hi Mom*
CSNet: friedl%vsi.uucp@kent.edu  ARPA: friedl%vsi.uucp@uunet.uu.net
uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl

gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/24/88)

In article <43@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>        #define generic char

Given the current state of C implementations, you probably have some
sort of system-dependent configuration header that you #include in
your applications (mine is called <std.h>).  You can use such a
header to provide system-independent types; for example mine has
	typedef char *pointer;	/* void * if you have it */
Then your application need not be modified during porting, just the
system-dependent configuration header.

This can obviously be carried to an extreme; you should use it mainly
for those things that cannot be done portably in this pre-ANSI C era.
(Mine also introduces a "bool" data type, which supports my style of
coding, but that's not a portability issue.)