It's really a bunch of bytes, right? So u8 * would be a better description?Doesn't "void *" behave better for casts though?Quite the contrary. Saying "void *" means: "compiler, don't check". If you have a buffer and declare it "char *", then it cannot be confused with a "struct urb *urb". But a "void *" can.
One common convention is: use "void *" for opaque pointers,
where the compiler _can't_ reasonably check, and typed pointers
("struct urb *", "char *") everywhere else.
If you want to talk about confusion and pointers, it's been my
experience that using multiple levels of indirection is what's
confusing ... adding casts from "char *" (as a not-opaque pointer
type) is usually tedious make-work, it doesn't help find or prevent
bugs. Plus, making casts become routine means they stop being
good flags for potential trouble.
Also, "u8 *" is not "char *". With a "u8 *" buffer, some platforms
won't let you assign a "char *" pointer to it since "char" is signed.
That's one example where "void *" pointers are better than "u8 *",
since a whole class of platform problems vanishes.
... except when you're working with typeless/opaque data, such as:Therefore it is generally a bad idea to use void * pointers.
# egrep 'kmalloc|kfree' include/linux/slab.h
extern void *kmalloc(size_t, int);
extern void kfree(const void *);
#
APIs use both "void *" and "char *", even within Linux.
I don't know any that use "u8 *", and I'd personally
rather stick with the model that casts should only be
needed when doing real type punning ... never just to
convert a pointer from typeless to typed.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
