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

 
 

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

Submitter:  Lachlan Andrew <lachlan>
Submitted:  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:  siko1056
Originator Name:  Lachlan Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group Member
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>
Group Member
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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group 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.13-758e.
    Corresponding source code