On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
> On May 25, 2009, at 2:24 PM, Zach Welch wrote:
>
> >>> Further, you can argue with the following assertions -- only if you
> >>> can
> >>> show me a patch that proves them wrong:
> >>>
> >
> > Show me your patch, or let me commit mine. This debate is silly.
> >
> > Cheers,
> >
> > Zach
>
>
> It's interesting that every time a discussion about preferences comes
> up, it typically ends with "Here's my patch. This is silly. My patch
> already works, let's just commit it." It's not like discussion is
> painful or this issue is causing problems for anyone. We're better
> off coming up with an answer that everyone is OK with rather than just
> defaulting to whatever patch shows up first.
Actually, these kinds of issues are very frustrating to me personally,
because they always end up being counterproductive. This is why I am
maintaining the Style Guide. I desperately want to hereafter resolve
this debate by shouting "RTFM and STFU"; anything else is time wasted.
The burden of proof lies on the person that lacks a patch in-hand.
Until these matters are fully resolved, the discussion does cause a
problem because it prevents us from moving forward with genuinely
productive work on the system.
> The opposing patch is attached. As I already mentioned, it is large,
> but the changes were done entirely with the following commands:
>
> find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/u16/uint16_t/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/u32/uint32_t/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/u64/uint64_t/g' {} \;
>
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint8_t/_uint8/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint16_t/_uint16/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint32_t/_uint32/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint64_t/_uint64/g' {} \;
>
> The first set just do a bulk rename of the types, but it also changes
> function names. Since it looks odd to include the _t in a function
> name, the second set changes the pattern used for function names to
> not include the _t.
I hate it. You seriously want to make all of the functions that
referred to u16 or u32 to now refer to uint16 and uint32??? This was
_exactly_ what I meant when I said a patch would be hard to create.
Also, you do realize that the scope of these changes is _much_ more
likely to be disruptive to anyone with out-of-tree changes in progress?
Are you insane or merely sadistic? :)
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
