Hello Pádraig, On Jul 15, 2015, at 21:25, Pádraig Brady <[email protected]> wrote: > Given the overlap it would be best to move the shared code > (and any associated global vars) to a set-fields.c module
Attached is a better draft, doing just that. Regarding the implementation - there are few stylistic decisions to be made. I'm happy to hear opinions: > FATAL_ERROR() or error() could be used, but I'd have a very > slight preference for error(). I've currently kept FATAL_ERROR, because it also calls 'usage()' which adds the 'try $prog --help for more information' message. If anything, this keeps the existing behavior of 'cut' intact, while 'numfmt' is new enough so there's no real harm in changing its error reporting. > For divergences you could > key on an extern int field_mode, initialized globally > in both cut.c and numfmt.c Instead of a global variable, I've added an 'options' bitfield to the 'set_fields' function (explained in set-fields.h). Is a global variable preferred? Also, I've changed the error messages as little as possible, to be consistent with 'cut' while still being mostly generic and usable by 'numfmt'. The second of the three patches contains only the changed wording of cut's error messages in the cut.pl test module - easier to examine. comments welcomed, - assaf
set-fields.patch
Description: Binary data
