> I find the p*_t typedefs handy because they relax me from
> the burdon of writing an extra "*" (and forget it).
>
> Do the p*_t typedefs make the code worse?
I think so. They make APIs more complicated and
baroque ... extra data types to learn and stumble on.
Putting a "p" at the front vs
On Monday, 24. December 2001 22:36, Greg KH wrote:
> Good point. I'll leave the urb_t typedef alone for now as it's used by
> quite a bit of code. The p* typedefs are easy to remove, and I'll do
> that.
This will break my code =8-(
I find the p*_t typedefs handy because they relax me from
the
> will be patching those, and how soon? It would be a bad idea to instantly
> break all custom drivers on this planet!
In the case of kdev_t no, because it was designed to be an opaque cookie
from day one.
___
[EMAIL PROTECTED]
To unsubscribe, use the
> > The absolutely worst happens when someone attempts to re-type
> > a _t over a large body of existing code, for instance inexpirienced
> > coders keep proposing to change kdev_t into a pointer.
>
> I'd hardly call Andries inexperienced, and in fact he did precisely that
> a long time ago but t
Quoting Alan Cox <[EMAIL PROTECTED]>:
> > The absolutely worst happens when someone attempts to re-type
> > a _t over a large body of existing code, for instance inexpirienced
> > coders keep proposing to change kdev_t into a pointer.
>
> I'd hardly call Andries inexperienced, and in fact he did
> The absolutely worst happens when someone attempts to re-type
> a _t over a large body of existing code, for instance inexpirienced
> coders keep proposing to change kdev_t into a pointer.
I'd hardly call Andries inexperienced, and in fact he did precisely that
a long time ago but the work was
> From: Wolfgang Mües <[EMAIL PROTECTED]>
> Date: Mon, 24 Dec 2001 15:40:04 +0100
> > p* can be removed (I don't like it either), but why the _t? It's a clear
> > marking that this is a defined type and it makes the code a tiny bit more
> > readable. And usb.h is not the only one using that style
On Mon, Dec 24, 2001 at 02:11:47PM +0100, Georg Acher wrote:
> On Sun, Dec 23, 2001 at 05:49:17PM -0800, Greg KH wrote:
>
> > Now to try to get rid of those *_t and p* typedefs in usb.h...
>
> p* can be removed (I don't like it either), but why the _t? It's a clear
> marking that this is a defi
On Monday, 24. December 2001 14:11, Georg Acher wrote:
> On Sun, Dec 23, 2001 at 05:49:17PM -0800, Greg KH wrote:
> > Now to try to get rid of those *_t and p* typedefs in usb.h...
>
> p* can be removed (I don't like it either), but why the _t? It's a clear
> marking that this is a defined type an
On Sun, Dec 23, 2001 at 05:49:17PM -0800, Greg KH wrote:
> Now to try to get rid of those *_t and p* typedefs in usb.h...
p* can be removed (I don't like it either), but why the _t? It's a clear
marking that this is a defined type and it makes the code a tiny bit more
readable. And usb.h is not
> Now to try to get rid of those *_t and p* typedefs in usb.h...
Yes please. Luckily most driver authors don't use them ... :)
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-d
On Sun, Dec 23, 2001 at 02:24:01AM -0500, Pete Zaitcev wrote:
>
> > Here's a patch against 2.4.17 that adds documentation for the FILL_*_URB
> > macros, and adds the usb_fill_*_urb() inline functions which are in the
> > 2.5 tree.
>
> Why are they inline? We do have macros, so it's not for speed
> From: Greg KH <[EMAIL PROTECTED]>
> To: Marcelo Tosatti <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Date: Fri, 21 Dec 2001 14:22:55 -0800
> Here's a patch against 2.4.17 that adds documentation for the FILL_*_URB
> macros, and adds the usb_fill_*_urb() inline functions which are in the
> 2.5
Hi,
Here's a patch against 2.4.17 that adds documentation for the FILL_*_URB
macros, and adds the usb_fill_*_urb() inline functions which are in the
2.5 tree.
thanks,
greg k-h
diff -Nru a/include/linux/usb.h b/include/linux/usb.h
--- a/include/linux/usb.h Fri Dec 21 12:58:14 2001
+++ b/
14 matches
Mail list logo
