bugGNU Octave - Bugs: bug #38974, [octave forge] (strings)...

 
 

bug #38974: [octave forge] (strings) base64decode retains trailing zeros

Submitter:  None
Submitted:  Mon 13 May 2013 04:36:40 AM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Dave GOEl Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * other
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 13 Jul 2021 05:17:50 PM UTC, comment #10: 

The functions `matlab.net.base64encode` and `matlab.net.base64decode` have been added for Octave 7 here:
https://hg.savannah.gnu.org/hgweb/octave/rev/903fe321649b

`matlab.net.base64decode` returns a vector of type uint8. It should be simple for a user to implement a wrapper like the one outlined in comment #8 to typecast the result to a different type.

Closing as fixed since the main part in the strings package was already solved.

Markus Mützel <mmuetzel>
Group administrator
Fri 18 Dec 2020 09:20:43 PM UTC, comment #9: 

this main bug in strings package appears to have been solved, the remaining bug is more of a wishlist item for the core base64_decode function to handle different decode types, and appears comment #8 proposes a way to do that.

probably could at least update the bug title/item group.

Nicholas Jankowski <nrjank>
Group Member
Wed 08 Jul 2015 08:26:50 AM UTC, comment #8: 

an easy way to implement



base64_decode (value, type)


would be to rename the built-in function to
_base64_decode_ and change it to produce
uint8 output.

Then base64_decode.m would be as simple as:


function decoded = base64_decode (value, type = "uint8")
decoded = typecast (__base64_decode__ (value), type);
endfunction



Carlo de Falco <cdf>
Group Member
Tue 07 Jul 2015 09:00:36 PM UTC, comment #7: 

I did a major review of the function's code and the bug is now fixed in the repository
https://sourceforge.net/p/octave/strings/ci/db1ee7036df04061b20c51dc10545993ecf4a183/

As for the base64_* functions in core: base64_encode is already good for general use and a valid replacement for this packages function. Allowing strings as parameters would be a bonus.

However, base64_decode should be changed and decode into uint8 vectors by default. These could then be typecast into binary64 or string or whatever by the user. To decode into binary64 is not very userful, because it limits byte sizes to multiples of 8. Having an optional type parameter for base64_decode would be a bonus, but should not require a lot more code than calling typecast in most cases.

Oliver Heimlich <oheim>
Sun 21 Jun 2015 03:17:43 PM UTC, comment #6: 

base64_encode already supports encoding uint8
encoding strings is as easy as


base64_encode (typecast ('uint8', 'I am a string'))


doing the same for base64_decode is a bit more tricky
as the encoded string does not include any information
about the type of the decoded data.

currently base64_encode assumes the data to be of type
double. Maybe we should assume type uint8 and use an explicit cast or allow a second input a argument specifying the output
type?

The latter would probably look cleaner from the user point of view but would require a lot more checks in the code ...

c.

Carlo de Falco <cdf>
Group Member
Sun 21 Jun 2015 12:44:27 PM UTC, comment #5: 

What if the functions in core are improved to also handle uint8 vectors and strings?

Carnë Draug <carandraug>
Group Member
Fri 19 Jun 2015 06:43:49 PM UTC, comment #4: 

Thanks for pointing me here, I have missed this bug for the recent release.

The difference between the base64 functions in core and in strings package is that core can only deserialize binary64 matrices, whilst the strings package enables us to deserialize uint8 vectors or strings.

I will fix it soon.

Oliver Heimlich <oheim>
Fri 19 Jun 2015 03:00:43 PM UTC, comment #3: 

What is the difference between base64_decode in Octave and base64decode in the strings package?  Is there any reason we need to have both?

John W. Eaton <jwe>
Group administrator
Fri 19 Jun 2015 02:08:01 PM UTC, comment #2: 

This bug is still present in the current development version of the strings package, updating bug summary and ccing strings package maintainer.

Mike Miller <mtmiller>
Group Member
Thu 16 May 2013 08:07:53 PM UTC, comment #1: 

Is this a duplicate of 38974?

John W. Eaton <jwe>
Group administrator
Mon 13 May 2013 04:36:40 AM UTC, original submission:  

It seems to me that base64decode doesn't understand padding correctly. Here, for example, it incorrectly returns extra 0's at the end of the decoded integers.
 
octave:203> assert(base64decode(base64encode("A")),double("A"))
error: assert (base64decode (base64encode ("A")),double ("A")) expected
 65
but got
   65    0    0
Dimensions don't match
error: called from:
error:   /usr/share/octave/3.2.4/m/testfun/assert.m at line 209, column 5



(Notice that (a) char([65 0 0]) will display as simply a on the screen, causing you to think that you got the right answer;
(b) Simply truncating ending 0's is not right either. Sometimes, 0's are actually expected.)





Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by oheim (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by mtmiller
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by cdf (Updated the item)
  • -email is unavailable- added by None (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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-07-13 mmuetzel StatusNeed Info Fixed
        Open/ClosedOpen Closed
        Summary[octave forge] (strings) base64decode retains trailing zeros [octave forge] (strings) base64decode retains trailing zeros
    2017-08-13 jwe Summarystrings package: base64decode retains trailing zeros [octave forge] (strings) base64decode retains trailing zeros
    2015-06-19 mtmiller Release3.2.4 other
        Operating SystemGNU/Linux Any
        SummaryIncorrect result in base64decode: strings package: base64decode retains trailing zeros
        Carbon-Copy- Added oheim
    2015-06-19 mtmiller StatusNone Need Info
    2013-05-16 jwe StatusOctave Forge None
    2013-05-13 cdf StatusNone Octave Forge

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code