Sorry, I just realised that you can simplify that to only having a single
256 on the left of the ⊥:
*256 ⊥ 0 0 32 0*
8192
On 9 September 2015 at 12:26, Elias Mårtenson <[email protected]> wrote:
> I'd presume that's 4 binary bytes in big-endian form. If so, then you have
> to do:
>
> *256 256 256 256 ⊥ 0 0 32 0*
> 8192
>
>
> On 9 September 2015 at 12:01, <[email protected]> wrote:
>
>> The result of FIO∆fread FIO∆fopen_ro filename
>> will return a vector of values, where each number is a byte. Many
>> different file format specifications specify a size within the file that
>> may be a head size, a chunk size, etc.
>>
>> Is the correct way to interpret a number that spans many bytes (in this
>> case 0 0 32 0 and 0 0 0 4) to use
>> 10 ⊥ 0 0 32 0 and 10 ⊥0 0 0 4
>>
>> Hope that clears up my idea a little
>>
>> -Alex
>>
>> -------- Original Message --------
>> Subject: Re: [Bug-apl] chunk length specified across bytes
>> From: Elias_Mårtenson <[email protected]>
>> Date: Tue, September 08, 2015 8:44 pm
>> To: [email protected]
>> Cc: "[email protected]" <[email protected]>
>>
>> I'm not entirely sure how this relates to GNU APL in any way?
>>
>> On 9 September 2015 at 11:41, <[email protected]> wrote:
>>
>>> Hi Bug APL,
>>>
>>> The PNG spec says that the length of a "chunk" (their term, not mine) is
>>> specified in the first four bytes of the file. When I read it in, the first
>>> four values are :
>>> 0 0 32 0
>>>
>>> and the length is almost certainly not 32.
>>>
>>> A smaller chunk that was 4 had its first four bytes as:
>>> 0 0 0 4
>>>
>>> What is the weighting given to these values (if that even is the right
>>> question to ask)?
>>>
>>> -Alex
>>>
>>
>>
>
