On 05/29/2012 09:05 PM, Joseph S. Myers wrote:
> On Tue, 29 May 2012, Christian Bruel wrote:
>
>> So I tested the following semantics, with the ones that you pointed.
>
> Thanks for the testing. The patch is OK with the ChangeLog conflict
> markers removed (and the dates on log entries updated
On Tue, 29 May 2012, Christian Bruel wrote:
> So I tested the following semantics, with the ones that you pointed.
Thanks for the testing. The patch is OK with the ChangeLog conflict
markers removed (and the dates on log entries updated to the date of
commit).
--
Joseph S. Myers
jos...@codes
> Please do send such a patch (with an explanation in each case of how
> "validated" still gets set with that redundant setting removed).
>
'validated' can only be removed for user --specs switches, this is why I
think it doesn't need to be propagated to do_specs. My mistake from the
previous m
On Tue, 29 May 2012, Christian Bruel wrote:
> 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
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
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 machiner
On 05/28/2012 06:27 PM, Joseph S. Myers wrote:
> On Mon, 28 May 2012, Christian Bruel wrote:
>
>>
>>
>> On 05/28/2012 01:11 PM, Joseph S. Myers wrote:
>>> On Mon, 28 May 2012, Christian Bruel wrote:
>>>
I shared the same concern, however, after playing bits with spec toys, I
couldn't a
On Mon, 28 May 2012, Christian Bruel wrote:
>
>
> On 05/28/2012 01:11 PM, Joseph S. Myers wrote:
> > On Mon, 28 May 2012, Christian Bruel wrote:
> >
> >> I shared the same concern, however, after playing bits with spec toys, I
> >> couldn't a find a way to get a %< switch recognition failure, s
On 05/28/2012 01:11 PM, Joseph S. Myers wrote:
> On Mon, 28 May 2012, Christian Bruel wrote:
>
>> I shared the same concern, however, after playing bits with spec toys, I
>> couldn't a find a way to get a %< switch recognition failure, since the
>> switches passed on the command line at this poi
On Mon, 28 May 2012, Christian Bruel wrote:
> I shared the same concern, however, after playing bits with spec toys, I
> couldn't a find a way to get a %< switch recognition failure, since the
> switches passed on the command line at this point are already validated
> if necessary.
Suppose with t
Hello
On 05/22/2012 03:52 PM, Joseph S. Myers wrote:
> On Mon, 21 May 2012, Christian Bruel wrote:
>
>> 1) Lazily check the flag validation until all command line spec files
>> are read. For this purpose, 'read_specs' records specs, to be analyzed
>> with 'file_spec_p'. Such flags have 'live_cond
On Mon, 21 May 2012, Christian Bruel wrote:
> 1) Lazily check the flag validation until all command line spec files
> are read. For this purpose, 'read_specs' records specs, to be analyzed
> with 'file_spec_p'. Such flags have 'live_cond' = SWITCH_USER
I like the idea of allowing flags mentioned
Hello,
This patch restores the --specs flags functionality.
There are 2 parts
1) Lazily check the flag validation until all command line spec files
are read. For this purpose, 'read_specs' records specs, to be analyzed
with 'file_spec_p'. Such flags have 'live_cond' = SWITCH_USER
2) --specs optio
13 matches
Mail list logo
