Subject: Re: Gigabit Ethernet
To: None <M.Drochner@fz-juelich.de>
From: Chris G. Demetriou <cgd@netbsd.org>
List: port-i386
Date: 09/08/1999 13:50:38
Matthias Drochner <drochner@zel459.zel.kfa-juelich.de> writes:
> cgd@netbsd.org said:
> > * Any reason why this shouldn't be "void *" as the return type?  I
> > mean, caddr_t probably works just as well, but it's not obvious to me
> > why its use is _ever_ right any more.  8-) 
> 
> I didn't think about it too much, but caddr_t is
> more convenient in many cases because one can do
> arithmetics on it without a cast.

Of course, you might want to do arithmetic on non-char units, or...

> > * I suppose since it's linear that they can just add in their favorite
> > offset themselves, eh?  8-)
> 
> Yes - provided it's not a void* :-)

So, i'm inclined then to say "use char *".  I dunno what standards say
about caddr_t, but at least to my mind it's always seemed bogus that
on ANSI-friendly systems it's a char *, even.  (If it's just a "core"
address, why does it have a specific type?  8-)

Further (and different!), since what's there is memory and only the
user knows what type of memory it actually is, it seems unnecessary to
tell the user that they have to cast the result.  The bus_space
implementation doesn't (or shouldn't 8-) care about what the actual
layout of the memory is.

by your argument, modern malloc, memcpy, etc., should all take or
return char *, not void *...


> > * when documenting this in bus_space(9), _PLEASE_ remind people of the
> > necessity of using bus_space_barrier()...
> 
> Oh - documentation... good that you remind me.
> 
> best regards
> Matthias
> 
> 
> 

-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.