On May 25, 2009, at 1:52 PM, Zach Welch wrote:
On Mon, 2009-05-25 at 13:10 -0700, Rick Altherr wrote: [snip]Sorry Rick, but I think that you and Duane have lost this argument. You have failed to defend your position with facts.I could say the same of everyone else. Considering the entire issue is rooted in preference, there are no hard facts to be presented.Okay, apparently I need to spell them out for you. Here are the facts: 1) They are shorter: 3 < 7 and 3 < 8.
Agreed, but that doesn't make them better for usage. Naming every variable in a function with a single letter is shorter too.
2) most of the OpenOCD code uses the short types - it was developed before the C99 types could be relied upon- "grandfathering" these types says nothing about the rest of OpenOCD
I know _why_ they are there. Keeping them by "grandfathering" does set a precedent or at least makes the rest of the type conventions odd. Imagine how you would document this in the developer manual: "All types are of the form x_t where x is a descriptive name in lower- case with words joined by underscores. The name should encapsulate the subsystem the type is related to and what it represents. NOTE: The types for defined-width integers are an exception to these rules."
3) the patch to unify the changes to short types is minor and finished:- it uses the C99 types fully, so we get all of their benefits - it will fix portability problems on some 64-bit architectures - it leaves the code more correct than it was before the patch
Agreed. Of course, that doesn't mean that it is the only option or even the option we want to go with. A similar patch can provide all of those same benefits by using the C99 types directly but doesn't have the "is minor and already finished" part.
Further, you can argue with the following assertions -- only if you canshow me a patch that proves them wrong: A patch to use C99 types would be: - difficult to create in the first place,
Entirely sed-able.
- bigger than the community would be able or willing to review, and
These usually fall into the "large but mechanical" bucket and are easy to review.
- a major source functional regressions.
Assuming that u32 is a typedef for uint32_t, then there is no possibility of a functional regression. If u32 _isn't_ a typedef for uint32_t, then moving the short types to be based on the C99 types has just as much likelihood for functional regressions.
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
