On Sun, 24 May 2009, Rick Altherr wrote: > > On May 24, 2009, at 9:37 PM, Zach Welch wrote: > > > On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote: > > > =On May 24, 2009, at 9:04 PM, Zach Welch wrote: > > > > > > > On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote: > > > > > On Sunday 24 May 2009, Zach Welch wrote: > > > > > > - add iN equivalents to intN_t types; i32 is used by replacements.h > > > > > > > > > > The traditional sibling of a "u32" (unsigned) is an "s32" (signed). > > > > > > > > > > I don't know where "i32" came from, it's an interloper. > > > > > > > > That would be me, taking a blind stab in the dark. Mea culpa. > > > > > > > > Fixed: new patch attached for consideration. I have also fixed the > > > > duplicated section heading in the documentation. Anything else? > > > > > > > > Cheers, > > > > > > > > Zach > > > > > > > > > > > > > > > > > Maybe I misunderstood. I thought we were deprecating the use of "u32" > > > in favor of the C99-defined "uint32_t". Why would we define another > > > set of types when there a perfectly fine versions already available as > > > part of the language standard? > > > > Heh. I just went back and re-read the original post and realized my > > mistake; however, I will defend my changes with two principles: > > > > 1) It's shorter/faster to type. This argument has been hashed out > > extensively on the Linux mailing lists. Linus has it right in this > > debate to prefer s32/u32. POSIX is dumb; however, that doesn't mean we > > can't exploit their work for own purposes. > > > > Perhaps I'm jaded from writing code for OS X where function names are intended > to be descriptive and thus end up long. Most editors include autocompletion > which makes the difference minimal in practice. Even when I'm writing code in > vi, I prefer the longer type names since it make it clear that a) it's a type > by having the _t suffix and b) that's an unsigned int. With u32, there are > plenty of cases where odd naming collisions can occur.
As far as my opinion matters, I don't think that uint32_t is that much clearer than u32. It is widely assumed that u32 refers to an integer and not a float, hence having the information carried everywhere is up only for additional typing and screen realestate. And Linux makes for a big example where plenty of odd naming collisions is simply not an issue in practice (I know this example might not have such a weight for OS X fans though). Nicolas _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
