On Sun, 2009-05-24 at 21:37 -0700, 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.
Why did I type POSIX when I meant C99? *sigh* And I do not mean to cast aspersions against anyone doing standards development work; open standards move the industry forward. I simply mean to say that there is no reason to adopt every little detail from _every_ standard. After all, I've heard it said that the great thing about standards is that there are so many to choose from.... In this case, the shorthand types are the de facto standard, based on the majority of lines of code that use them. They have already won. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
