bugGNU Octave - Bugs: bug #45753, warning("error") breaks...

 
 

bug #45753: warning("error") breaks many things

Submitted by:  Lachlan Andrew <lachlan>
Submitted on:  Fri 14 Aug 2015 03:12:59 AM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  Kai Torben Ohlhus <siko1056>
Originator Name:  Lachlan Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 22 Dec 2015 11:33:13 PM UTC, comment #4: 

Alright, thank you very much for your patch. It works for me and no errors occur. I translated your patch to stable adding a test case, thus it gets merged to default very soon. This misbehavior is also present in stable and can be avoided there already in the next upcoming release. See

http://hg.savannah.gnu.org/hgweb/octave/rev/6ed7bae8017b

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Tue 22 Dec 2015 10:12:00 PM UTC, comment #3: 

Kai, it is relative to default.  Sorry for not stating that.

Lachlan Andrew <lachlan>
Mon 21 Dec 2015 01:05:41 PM UTC, comment #2: 

Is your patch for the default or stable branch? Applying it to stable results in an error.

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Sat 19 Dec 2015 10:45:28 AM UTC, comment #1: 

The attached patch fixes this by making warning("error"/"on"/"off") only apply to the default behaviour.

Specifying "all" explicitly [warning("error", "all")] still explicitly removes explicit settings.

(file #35798)

Lachlan Andrew <lachlan>
Fri 14 Aug 2015 03:12:59 AM UTC, original submission:  

The code

warning("error")
help warning

causes the error message

error: concatenation of different character string types may have unintended consequences

That means that once warning("error") is turned on, it is impossible to see if it is possible to return warnings to their default settings.  Other functions are affected too (I found it first in strread).

I'd like to fix this by making  warning("error")  only convert enabled warnings to errors, rather than all warnings.  (That obeys the principle of least surprise.)  This could either be those warnings enabled when the command is issued (easiest and most efficient), or those warnings enabled when the warning is triggered (probably the best, especially for user-defined warnings).

An alternative is to go through all the libraries and eliminate all code that can produce spurious warnings.  The extra checking etc may slow execution down, and would add to code bloat.

(Apologies if this is a duplicate of something I just wrote; I tried to report the bug, but the bug report didn't appear.)

Lachlan Andrew <lachlan>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #35798:  bug_45753.cset added by lachlan (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by lachlan (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-12-22 siko1056 StatusPatch Submitted => Fixed
        Assigned toNone => siko1056
        Open/ClosedOpen => Closed
        Release4.0.0 => dev
        Operating SystemGNU/Linux => Any
    2015-12-20 siko1056 StatusConfirmed => Patch Submitted
    2015-12-19 lachlan Attached File- => Added bug_45753.cset, #35798
    2015-09-28 siko1056 StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.7