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.hThe 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, ZachMaybe I misunderstood. I thought we were deprecating the use of "u32"in favor of the C99-defined "uint32_t". Why would we define anotherset of types when there a perfectly fine versions already available aspart 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 thisdebate to prefer s32/u32. POSIX is dumb; however, that doesn't mean wecan'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.
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 enforcefrom here on. With less typing (this goes both for the types themselvesand 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.
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.
Cheers, Zach
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
