Hi Lorenzo,
On 12/07/13 18:05, Lorenzo Bettini wrote:
I'll try to get back to you by the end of July.
Just pinging you again. :o)
In general it would be great if we don't break backward compatibility...
Yes, I agree completely. The problems are as follows:
- gengetopt_args_info_usage
gengetopt_args_info_purpose
gengetopt_args_info_description
These strings are no longer statically initialised, but are
dynamically initialised during the required call to
init_args_info(). Also, they don't include the spaces and newlines
required for them to be displayed correctly, with wrapping, if they
are simply printed to stdout.
So, in summary, there are now the additional requirements that:
a) init_args_info() is called prior to use, and
b) that string wrapping be done manually on the strings, at runtime,
when they are being displayed.
- gengetopt_args_info_help
gengetopt_args_detailed_help
gengetopt_args_full_help
All of the above that is true of the usage, purpose and description
string pointers is also true of these arrays. But, additionally,
these arrays are now generated in groups of three (i.e., there are
three times as many entries as before).
So, in summary, and in addition to the two previous requirements, a)
and b), there is also the additional requirement that:
c) the strings are used in groups of three
- args_info::<option>_help
This is now stored as two separate strings, <option>_help_param and
<option>_help_desc. So we couldn't be backwards compatible with out
also generating a (now redundant and otherwise unused) <option>_help
string.
But even if we did this, the same requirements a) and b) would apply.
Would you still prefer to make these strings silently compatible with
existing software, given the changes?