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.) * The option, passed by the user, is in a .opt file and no spec at all. (Should be rejected.) > 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. -- Joseph S. Myers jos...@codesourcery.com
