Comments and suggestions on functions for binary buffers

[dcantor]

I started trying out the new binary buffer support.

@BPEEK and @BPOKE

I see that the length of the value written or read is constrained to be 1, 2, 4, or 8 bytes. Why not 3, 5, 6, and 7? Suppose I want to read a 24-bit quantity. I can do it by reading 32 bits and ANDing it with 0xffffff, but it would be much more convenient to be able just specify 3 bytes. Writing a 24-bit quantity requires two or three writes. It ought to (IMO) require just one. Please consider this for the next version.

(For completeness (which I know you probably don't want to bother with, Rex), I would also allow 0 bytes, and the result would always be 0.)

(I would have preferred a number of BITS rather than bytes.)




@BREAD and @BWRITE

There's an offset argument indicating the offset from the current position of the file to be read or written to/from the binary buffer. It would seem that there ought to be another argument to mean from the beginning, current position, or end of the file, like in the @FILEREAD function. Trying to read from any file position not specifyable as an offset from the current position (such as, say, 2 bytes before the EOF) requires a separate @FILESEEK.

Alternatively, if one is willing to do the @FILESEEK before a @BREAD or @BWRITE, we could eliminate the offset argument from those calls completely.

(I kind of wish I had seen the alpha and early beta versions -- this comment would have been better timed then.)


I'm trying to be constructive here. What was implemented is a GREAT improvement. I will use this feature extensively.

 

[vefatica]

On Fri, 30 Jan 2009 21:31:35 -0600, dcantor <> wrote:

>I started trying out the new binary buffer support.
>
>@BPEEK and @BPOKE
>
>I see that the length of the value written or read is constrained to be 1, 2, 4, or 8 bytes. Why not 3, 5, 6, and 7? Suppose I want to read a 24-bit quantity. I can do it by reading 32 bits and ANDing it with 0xffffff, but it would be much more convenient to be able just specify 3 bytes. Writing a 24-bit quantity requires two or three writes. It ought to (IMO) require just one. Please consider this for the next version.
>
>(For completeness (which I know you probably don't want to bother with, Rex), I would also allow 0 bytes, and the result would always be 0.)
>
>(I would have preferred a number of BITS rather than bytes.)

Windows has built-in types of 1,2,4,8 bytes. It'd be a nightmare for Rex, and
probably for the user too, to keep track or arbitrary sizes. Just use the
smallest field that will accommodate your data ... there's no need to AND it
with anything; 3-byte data will occupy 3 bytes of the four and come back out as
it went in.

v:\> echo %@bpoke[%h,0,4,0xABCDEF]
0

v:\> echo 0x%@convert[10,16,%@bpeek[%h,0,4]]
0xABCDEF

>@BREAD and @BWRITE
>
>There's an offset argument indicating the offset from the current position of the file to be read or written to/from the binary buffer. It would seem that there ought to be another argument to mean from the beginning, current position, or end of the file, like in the @FILEREAD function. Trying to read from any file position not specifyable as an offset from the current position (such as, say, 2 bytes before the EOF) requires a separate @FILESEEK.

I don't think @FILEREAD has an offset argument.

>Alternatively, if one is willing to do the @FILESEEK before a @BREAD or @BWRITE, we could eliminate the offset argument from those calls completely.

@FILESEEK seems the right way to go about it. The file_offset parameter might
be convenient once in a while ... I'm not sure it's worth always having to deal
with it.

 

[dcantor]

On Fri, 30 Jan 2009 21:31:35 -0600, dcantor <> wrote:

Windows has built-in types of 1,2,4,8 bytes. It'd be a nightmare for Rex, and
probably for the user too, to keep track or arbitrary sizes. Just use the
smallest field that will accommodate your data ... there's no need to AND it
with anything; 3-byte data will occupy 3 bytes of the four and come back out as
it went in.

v:\> echo %@bpoke[%h,0,4,0xABCDEF]
0

v:\> echo 0x%@convert[10,16,%@bpeek[%h,0,4]]
0xABCDEF

You misunderstood.

Suppose I have a buffer where
> echo 0x%@convert[10,16,%@bpeek[%h,0,4]]
is 0x12345678

and I want to deposit the 24-bit (3-byte) quantity 0xFEDCBA into the right-most positions, leaving the 0x12 at the beginning.

I want to say

> echo %@bpoke[%h,0,3,0xFEDCBA]
but I cannot. Instead I need to do something like
> echo %@bpoke[%h,0,2,0xDCBA]%@bpoke[%h,2,1,%0xFE]

After that the echo statement will yield 0x12FEDCBA .


For reading, I'd like to be able to read a 3-byte integer (even if Windows doesn't have that as a datatype, there can be an are instances of things like that in existing files for different applications). I can do that by reading 4 bytes and ANDing off the leftmost byte. It would be better to be able to just specify 3 bytes. This isn't as important as writing, of course.

I don't think @FILEREAD has an offset argument.

@FILESEEK seems the right way to go about it. The file_offset parameter might
be convenient once in a while ... I'm not sure it's worth always having to deal
with it.

Right. I'm saying make @BREAD and @BWRITE like @FILEREAD and @FILEWRITE, reading or writing at the current position of the file as set by @FILESEEK, and leaving out the file-offset argument.

 

[rconn]

I started trying out the new binary buffer support.

@BPEEK and @BPOKE

I see that the length of the value written or read is constrained to be 1, 2, 4, or 8 bytes. Why not 3, 5, 6, and 7?

Because nobody would ever use that. (What is a 5-byte integer??)

If you want to write random values in odd lengths, use @BPEEKSTR / @BPOKESTR. @BPEEK and @BPOKE are for integer writes.

(I can't even imagine why you would need to write random bit lengths!)

 

[dcantor]

Because nobody would ever use that. (What is a 5-byte integer??)

If you want to write random values in odd lengths, use @BPEEKSTR / @BPOKESTR. @BPEEK and @BPOKE are for integer writes.

(I can't even imagine why you would need to write random bit lengths!)

Because there are files that store strange-length integers on non-byte boundaries.

Using @BPEEKSTR for strange-length, byte-aligned integers isn't going to work when any of the bytes happens to be binary zero, will it?

I do in fact have a file where I need to store 3-byte integers. Up until now, I've been using XXD, and it works. Now I want to use @BPOKE and I can make it work with two consecutive calls to @BPOKE like I illustrated earlier.

Hey, you can't blame a guy for asking.


Like I said, what's been implemented is good. These binary buffer functions are a BIG, BIG help.