bugGNU Octave - Bugs: bug #54931, bitpack order in big-endian...

 
 

bug #54931: bitpack order in big-endian machines

Submitter:  Carnë Draug <carandraug>
Submitted:  Thu 01 Nov 2018 04:00:10 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 4.4.1 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 10 Nov 2018 07:31:42 PM UTC, comment #3: 

But is this a bug on the implementation?  Or is the bug just in the documentation?  The one code sample I used to open the bug report is assuming one interpretation of the documentation.  If my interpretation of the documentation is incorrect, then there's no bug in the implementation and the test code is incorrect.

Thing is, documentation says that buts are in order of significance, but then says that bit 0 is first element, bit 1 is second element.  Using an uint32 type and big-endian machine, only one of those is correct.

Carnë Draug <carandraug>
Group Member
Sat 10 Nov 2018 06:08:56 AM UTC, comment #2: 

I added the one code sample that was in this report as a BIST test (https://hg.savannah.gnu.org/hgweb/octave/rev/09665529b6ba).

Rik <rik5>
Group administrator
Thu 01 Nov 2018 06:48:43 PM UTC, comment #1: 

It would probably be useful to add many more %!tests to bitpack and bitunpack that would help catch this. The current unit tests only pack and unpack an array of all zeroes and validate that the type and bit length are correct.

Mike Miller <mtmiller>
Group Member
Thu 01 Nov 2018 04:00:10 PM UTC, original submission:  

The bitpack function packs an array of logical values in an array of another type. Its documentation says:

> Bits come in increasing order of significance, i.e., 'x(1)' is bit 0, 'x(2)' is bit 1, etc.


The documentation has an issue since the position of the least significant bit is not necessarily bit 0, in the case of packing into a 32bit integer, it will be bit 24.

The actual implementation also does not take the values by order of significance, so the results differ between big and little endian machines. On a little endian machine (amd64):


>> x = false (1, 32);
>> x(1) = true;
>> disp (bitpack (x, "uint32"))
1
>> x([1 9]) = true;
>> disp (bitpack (x, "uint32"))
257


While on a big endian machine (mips at https://db.debian.org/machines.cgi?host=minkus )


>> x = false (1, 32);
>> x(1) = true;
>> disp (bitpack (x, "uint32"))
16777216
>> x([1 9]) = true;
>> disp (bitpack (x, "uint32"))
16842752


For what is worth, both the bitpack and bitunpack are Octave only, so what Matlab does does not apply here.

Looking at the code for bitpack, I believe the issue comes from the fact that the bit shifting is done in a char instead of the type that the bits are being packed into.

Carnë Draug <carandraug>
Group Member

 

(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

Digest:
   bug dependencies.

 

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

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-21 carandraug Dependencies- bugs #55521 is dependent

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code