On 05/29/2012 12:50 PM, Joseph S. Myers wrote: > On Tue, 29 May 2012, Christian Bruel wrote: > >>> The existing rule is supposed to be: options are only accepted if in >>> *both* a .opt file *and* a spec. If not in a .opt file, the common >>> machinery will reject them; if in a .opt file but not a spec, the driver's >>> own validation machinery will reject them. >> >> Thanks for confirming this, the question was more specifically for >> <%options. Today, with the current implementation, I see two uses cases: >> >> 1) The flag appears in a %< spec but is not in a .opt file >> -> It is *not* rejected. It is just ignored. > > I don't really see that as a use case; it's more a matter of an internal > consistency check that could be done but isn't. I'm only concerned about > cases where the option is actually passed on the command line to the > driver. > >> 2) The flag appears in a user switch and in a %< spec, and not in a .opt >> file. >> -> It is rejected. > > There are also cases: > > * The option, passed by the user, is in a .opt file, a %< spec but no > other spec. (Should be accepted.)
yes, it is. > > * The option, passed by the user, is in a .opt file and no spec at all. > (Should be rejected.) yes, it is. > >> To refocus on the original question from the patch. I'm still not >> convinced after our discussions and testings that the propagation of the >> user flag to the do_spec functions is required to keep the same semantic. > > With the proposed change to the rules for when a spec serves to validate > an option, all settings of the "validated" field need to be reviewed to > make sure that they are in accordance with the new rules - and that it is > transparent to human readers of the code that they are in accordance with > the new rules. If you don't think propagation is needed to do_spec > functions, then it should be possible to remove the "validated" setting in > there, with a proper explanation of the order in which the various > relevant functions are called and where "validated" will previously or > subsequently be set. > I agree. I see two potential settings of the validated field. The %< that we just reviewed, and the case : /* We have Xno-YYY, search for XYYY. */ It seems possible to remove those, I've just checked this during lunch :-) with the scenarios described above (without use m* f* specs). If it is a prerequisite before my --spec patch, I'd like to propose it as an independent one, since this is a valid modification regardless of the --spec implementation (although it makes it clearer). Many thanks Christian
