On Sun, 2009-05-24 at 22:43 -0700, 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. It's also not clear that its an integer, > but just an unsigned 32-bit something. To be entirely honest, I > prefer seeing long, descriptive function prototypes like: > > status_t TriggerSetThreadStateFilter(trigger_t trigger, const > thread_state_t * stateMasks, uint32_t numberOfStateMasks, error_t * > error); > > I pulled this particular example from another project I'm working on, > but it should illustrate the point. You can understand what most of > the parameters are and have a decent idea of what the function does. > The compiler doesn't care about names, so we should optimize them for > the people.
Which people? People that need to have their hands held with long fluffy names? Or for advanced coders that they can handle (and prefer) the shorter conventions? We should not dumb-down the OpenOCD code, and that is _exactly_ what you are describing. > > 2) More importantly, this patch applies the principle of least change. > > These changes both unify the type system around the types that are > > defined in "types.h" (and with the Linux kernel). Thus, we achieve > > conformance to an internal (and external) standard that we can enforce > > from here on. With less typing (this goes both for the types > > themselves > > and for the changes necessary to convert the entire tree to use the > > types that are used in only a handful of files today). > > > > Given that the state of the code is a hodgepodge of various naming > conventions, I don't see it being a good source for "it was mostly > that way already". I'd rather we chose a sensible convention based on > merits and apply it wholesale rather than just letting majority rule. Clearly you have not looked at the code with regard to this issue. The code is NOT a "hodgepodge" when it comes to these types. > Having the types align with the Linux kernel is of effectively no > importance. I happen to do all my development on OS X which follows > the C99 naming standards for anything in the BSD layer. Familiarity > in this case doesn't hold across the gamut of our developer base. How about familiarity with the OpenOCD code, which uses these types? How about the fact that 99% of the OpenOCD code already uses them? Sorry Rick, but I think that you and Duane have lost this argument. You have failed to defend your position with facts. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
