The 'struct foo_s' syntax is code bloat that obscures the actual
algorithms. 'foo_t' is shorter.
Doxygen seems to recognize the foo_s and foo_t version as one an the
same, I don't see what problem you have there. However it will just as
happily accept foo_t only, like in
typedef struct {} foo_t;
Michael
On Mon, Jun 1, 2009 at 1:37 AM, Zach Welch <z...@superlucidity.net> wrote:
> Hi all,
>
> The following things nagged at me when I did the target_type clean-up:
>
> 1) Remove redundant structure typedefs:
> a) Entails the following steps (for each named struct "type"):
> i) s/^typedef struct type_s/struct type_s/
> ii) s/^} type_t;/};/
> iii) s/type_t/struct type_s/
> iv) Fix any messes that these commands miss or make. ;)
> b) Eliminates what are essentially duplicated symbols:
> - simplifies the Doxygen documentation tremendously.
> - eliminates style ambiguity and forward referencing.
>
> 2) Improve the documentation for the target module files.
> - would be best to wait until other cleanup is done.
>
> 3) More moving and module clean-up:
> - I target.h needs some re-organization.
> - I have a jtag.h doc patch in progress.
>
> How do these changes look in the community's eyes? These were on the
> list of things to be considered for 0.2.0, but no one addressed them.
>
> I will post patches to clean-up and removal of jtag_tap_t in reply to
> this thread, to provide better foundation for concrete discussion about
> issue #1. While I think this would help the code and documentation a
> lot, I would even go further to suggest "s/_s//" from all struct names.
>
> Cheers,
>
> Zach
>
>
> _______________________________________________
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
