bugGNU Octave - Bugs: bug #38973, Tiny Bug in base64decode:

 
 

bug #38973: Tiny Bug in base64decode:

Submitted by:  None
Submitted on:  Mon 13 May 2013 04:28:54 AM UTC  
 
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: NoneAssigned to: Carlo de Falco <cdf>
Originator Name: DAVE GOELOriginator Email: -unavailable-
Open/Closed: OpenRelease: 3.2.4
Operating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

Mon 13 May 2013 06:09:19 AM UTC, comment #3:

Yes, this is the right place for the report
but you need to specify it's about a function from a
package.

I'll mark this as an OctaveForge bug and see what's the best
way to deal with it, possibly just obsoleting the functions
base64encode and base64decode in the strings package and relying
on the ones in core Octave.

BTW what version of the strings package do you have?
your Octave is really ancient so your packages may be as well, there is a possibility that the bug has been fixed in more recent versions.

Carlo de Falco <cdf>
Project MemberIn charge of this item.
Mon 13 May 2013 05:58:04 AM UTC, comment #2:

Ah, I apologize. This is part of forge's "octave-strings" package; I forgot to set the right header field, and couldn't figure out how to go and modify my report.

The octave-forge page brought us here, so I assumed this is the right place for the report.
dave

Anonymous
Mon 13 May 2013 05:26:26 AM UTC, comment #1:

Where did you get base64encode from?
I see no such function in any version of Octave I have installed (3.2.3, 3.6.4, 3.7.3+)

In the development version there is a function named base64_encode
but it does not display the behaviour you reported:

notice that in the above the numbers are being treated as double, if I want them to be considered of integer type you need to use an explicit cast

I suspect the function you are using is from some additional package rather than from Octave core, can you specify where it comes from?

Carlo de Falco <cdf>
Project MemberIn charge of this item.
Mon 13 May 2013 04:28:54 AM UTC, original submission:

octave:194> base64encode([99 99 0 0])
error: base64encode is expecting integers in the range 0 .. 255
error: called from:error: /usr/share/octave/packages/3.2/strings-1.0.7/base64encode.m at line 32, column 5

As you can see, the input was actually in the supplied range.

The problem is a simple displaced paren here in the first conditional of line 32

elseif (any(X(:)) != fix(X(:)) || any(X(:) < 0) || any(X(:) > 255))

This should be replaced by:

elseif (any(X(:) != fix(X(:))) || any(X(:) < 0) || any(X(:) > 255))

Thanks.
Dave.
--

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Updated the item)
  • -unavailable- added by cdf (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 16 May 2013 08:06:43 PM UTCjweCategoryNone=>Octave Forge Package
      StatusOctave Forge=>None
    Mon 13 May 2013 06:09:37 AM UTCcdfStatusWorks For Me=>Octave Forge
    Mon 13 May 2013 05:26:26 AM UTCcdfStatusNone=>Works For Me
      Assigned toNone=>cdf

    Back to the top


    Powered by Savane 3.1-cleanup