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


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

Submitted by:  None
Submitted on:  Mon 13 May 2013 04:36:40 AM UTC  
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: Need InfoAssigned to: None
Originator Name: Dave GOElOriginator Email: -unavailable-
Open/Closed: OpenRelease: other
Operating System: Any

Add a New Comment(Rich Markup)

You are not logged in

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


(Jump to the original submission Jump to the original submission)

Wed 08 Jul 2015 08:26:50 AM UTC, comment #8:

an easy way to implement

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:

Carlo de Falco <cdf>
Project 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

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

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


Carlo de Falco <cdf>
Project 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>
Project 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>
Project 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>
Project Administrator
Thu 16 May 2013 08:07:53 PM UTC, comment #1:

Is this a duplicate of 38974?

John W. Eaton <jwe>
Project 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
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.)



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

Attach File(s):

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 oheim (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by mtmiller
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by cdf (Updated the item)
  • -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 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 13 Aug 2017 12:46:29 PM UTCjweSummarystrings package: base64decode retains trailing zeros=>[octave forge] (strings) base64decode retains trailing zeros
    Fri 19 Jun 2015 02:08:01 PM UTCmtmillerRelease3.2.4=>other
      Operating SystemGNU/Linux=>Any
      SummaryIncorrect result in base64decode:=>strings package: base64decode retains trailing zeros
      Carbon-Copy-=>Added oheim
    Fri 19 Jun 2015 02:08:00 PM UTCmtmillerStatusNone=>Need Info
    Thu 16 May 2013 08:07:53 PM UTCjweStatusOctave Forge=>None
    Mon 13 May 2013 06:10:14 AM UTCcdfStatusNone=>Octave Forge

    Back to the top

    Powered by Savane 3.1-cleanup1