octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warnings shut off in ov.cc?


From: Rik
Subject: Re: warnings shut off in ov.cc?
Date: Tue, 15 Oct 2019 14:13:52 -0700

On 10/15/2019 01:26 PM, John W. Eaton wrote:
> On 10/15/19 2:21 PM, Rik wrote:
>> jwe,
>>
>> Can you try the attached patch which implements a warning when non-scalar
>> arguments are used with the colon operator?  Everything looks correct, and
>> the printf debugging that I started using when I got confused shows that
>> the code is executing, but no warnings are printed.  The code is exactly
>> the same format as the warning for complex values using in colon
>> expressions, however that warning fires.  Is there something that disables
>> warnings temporarily in the interpreter when calling operators?
>>
>> Sample session:
>>
>> 1:[3,4]
>> running do_colon_op
>> Got here
>> Got here2
>> ans =
>>
>>     1   2   3
>>
>> whereas
>>
>> octave:1> 1:3*i
>> running do_colon_op
>> warning: imaginary part of complex colon arguments is ignored
>> ans = [](1x0)
>>
>> Maybe this is a red herring, but occasionally warnings seem to be turned
>> off for the complex code path as well.
>>
>> octave:2> 1:(3i)
>> running do_colon_op
>> ans = [](1x0)
>>
>> The last example should also have produced a warning.
>
> I think you are seeing the effect of constant folding in the parser:
>
>
> http://hg.savannah.gnu.org/hgweb/octave/file/5a0543de1e47/libinterp/parse-tree/oct-parse.yy#l2493
>
>
> Warnings are intentionally disabled when doing constant folding
> operations.  The original idea may have been the same as what we should
> be doing for errors, which is to be silent about them when attempting
> constant folding, but if there is an error (or warning), fail to generate
> a constant value so that the expression will generate an error (or
> warning) later at run time.  This is clearly not happening for warnings.
>
> Unfortunately, I don't think that skipping the message but detecting the
> warning is an easy thing to do.
>
> Maybe we should just eliminate the constant folding operations in the
> parser?  I'm not sure that they really provide that much advantage.

Thanks, that is definitely the issue.  I tried two ways of making the
expression non-constant and, sure enough, the warning appears.

x = 4
1:[x, 10]

and

1:[3+1, 10]

What about just not discarding warning messages?  I commented out this line

//    es.discard_warning_messages (true);

and then everything works as expected (no duplicate warning messages either).

Just to be sure, I added more printf test code and even though the warning
is issued, the path through the constant logic is still taken.  Maybe the
unwind_protect frame is only required to capture errors, but warnings are
fine since they return to the original code and it keeps executing?

--Rik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]