Rick
On May 19, 2009, at 3:05 PM, David Brownell wrote:
The cosmetic cleanups should IMO just merge. On Tuesday 19 May 2009, Michael Bruck wrote:patch 01 is a rather large one that renames the function arguments 'num_fields' and 'fields' into 'in_num_fields' and 'in_fields' The rationale here is that almost all of these functions take some input fields and produce from that a new set of output fields. The patch sets the stage to later be able to use a local variable 'field' or 'fields' to refer to fields rather then the current endless repetitions of cmd->cmd.scan->fields[...] while at the same time making it clear which one is the input argument and which is the output data.Seems like it can hardly break anything, yes? That does seem to be useful clarity.patch 02 renames a local variable 'x' into 'num_taps' to describe what it meansExcept I don't like seeing declaration blocks split into sections with whitespace:{ jtag_tap_t *tap; - int x; int nth_tap; int scan_size = 0; + int num_taps = jtag_NumEnabledTaps();Just put the "int num_taps..." up where "int x" was.+ /* allocate memory for a new list member */jtag_command_t * cmd = cmd_queue_alloc(sizeof(jtag_command_t));Or what you did in a few other places, "type * ptrvar" should be just "type *ptrvar"; those are IMO neither simplifications nor cleanups. Ditto using the (IMO annoying) C99 feature where declarations don't necessarily live at the beginning of a block.Again none of these patches change any algorithm.Making them all coding style fixes, not simplifications. And at one point some new comments. I liked #5 (other than the "type * ptrvar" issue), that does make the code more clear: p->q->r ==> q->r is mostly better. I'd kind of like to see a standard "indent" ruleset agreed on, so that at least the things that tool handles well could be somewhat automated. (By the way, suggestion: only one patch per mail. It's painful enough to try reviewing attachments, especially text/plain ones that won't get the syntax highlighting that diffs do.) _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
-- Rick Altherr [email protected]"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 [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
