Why not use size_t to denote object sizes? Michael
On Mon, Apr 20, 2009 at 5:16 AM, Dick Hollenbeck <d...@softplc.com> wrote: > Zach Welch wrote: >> On Sun, 2009-04-19 at 21:25 -0500, Dick Hollenbeck wrote: >> >>> [snip] >>> Why are you changing this argument from the machine's natural size to >>> one that is 32 bits wide? >>> >>> Dick >>> >> >> Fair enough. Here is take four. >> >> This patch was produced as a band-aid to prevent bleeding if users try >> to checkout and build the current head with those drivers enabled. >> Without this patch, the new -Werror setting could cause them to get cut >> on the sharp edges. >> >> There are a plethora of places in the OpenOCD tree where the types need >> to be revisited systematically and cleaned up. This is not that patch. >> >> Cheers, >> >> Zach >> > > -int ft2232_read(u8* buf, int size, u32* bytes_read) > +int ft2232_read(u8* buf, u32 size, u32* bytes_read) > > > I would simply make that > > int ft2232_read(u8* buf, unsigned size, u32* bytes_read) > > or even > > int ft2232_read(u8* buf, unsigned size, unsigned* bytes_read) > > > If we don't need the "32 bitness", it is best to let the compiler, and the > programmer, use the machine's natural size. int and unsigned are simple. > > On a 64 bit machine, the "unsigned" and the "int" goes to 64 bits, but that > is its natural size, and is generally the most efficient, easier than > accessing 32 bits. > > Microsoft was insidious about injecting needless types into C and C++ code. > When Java was designed, they made a point of slapping that idea in the face. > > u8* is cool, we need unsigned bytes. > > u32 is cool, but only when you have to have the variable be 32 bits wide, > otherwise int or unsigned are better IMO when you don't care if it is 32 bits > or 64 bits. The 64 bit days are here. > > > Dick > > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
