bugGNU Octave - Bugs: bug #47918, filter() is not 64-bit ready

 
 

bug #47918: filter() is not 64-bit ready

Submitter:  Lachlan Andrew <lachlan>
Submitted:  Fri 13 May 2016 11:44:27 PM UTC
   
 
Category:  Octave Function Severity:  2 - Minor
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  lachlan
Originator Name:  Lachlan Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 14 May 2016 04:29:48 PM UTC, comment #6: 

I'm looking at it now.

Using -Wconversion generates a lot of noise, but you can grep for the "octave_idx_type to X" warnings to just look at those.

Then the problem is a cascade of other warnings, because some things are declared to return int when they should probably be octave_idx_type, so changing the declaration generates a new set of warnings.

John W. Eaton <jwe>
Group administrator
Sat 14 May 2016 04:05:51 PM UTC, comment #5: 

Rik: The choice depends in part on what we want to say
about 64-bit being "ready for test." It would not
be very friendly to say "ready for test" without first
fixing the ints. This suggests a bug report, and using
John's suggestion it should not be too hard to deal with.


Michael Godfrey <godfrey>
Group Member
Sat 14 May 2016 04:00:23 PM UTC, comment #4: 

Is it worth filing a bug report to check all instances of octave_idx_type/int?  Or should it be put in the list of Octave projects?

Rik <rik5>
Group administrator
Sat 14 May 2016 11:18:07 AM UTC, comment #3: 

I think you will get a warning from GCC for these kinds of assignments if you use -Wconversion.  You'll need to be compiling with 64-bit indexing so that octave_idx_type is wider than int (unless you happen to be on a system where int is also 64 bits wide).

John W. Eaton <jwe>
Group administrator
Sat 14 May 2016 10:51:34 AM UTC, comment #2: 

Thanks, Rik.

I assume that the current code works because of an automatic conversion from octave_idx_type to int.  Would the use of an "explicit" keyword somewhere help?  My knowledge of C++ is mainly from the 1990s...

Lachlan Andrew <lachlan>
Sat 14 May 2016 03:14:20 AM UTC, comment #1: 

I applied your cset here (http://hg.savannah.gnu.org/hgweb/octave/rev/e7f641616581).

Incidentally, doesn't this same thing happen all over the Octave code base?  I believe there are lots of places where coders casually used int when they really wanted an octave_idx_type.  It would be nice if there were an automatic way to find those instances.

Rik <rik5>
Group administrator
Fri 13 May 2016 11:44:27 PM UTC, original submission:  

The function  filter  uses an "int" type to store the stride.  This could cause incorrect results if octave_idx_type is 64 bits and a large array is being processed.

I'll add the (one line) patch once I have the bug number.

Lachlan Andrew <lachlan>

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-05-14 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2016-05-14 lachlan Attached File- Added bug_47918_filter_64bit.cset, #37151
        StatusNone Patch Submitted
        Assigned toNone lachlan

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code