1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Comments and suggestions on functions for binary buffers

Discussion in 'Support' started by dcantor, Jan 30, 2009.

  1. dcantor

    May 29, 2008
    Likes Received:
    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.
  2. vefatica

    May 20, 2008
    Likes Received:
    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]

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

    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.
  3. dcantor

    May 29, 2008
    Likes Received:
    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.

    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.
  4. rconn

    rconn Administrator
    Staff Member

    May 14, 2008
    Likes Received:
    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!)
  5. dcantor

    May 29, 2008
    Likes Received:

    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.

Share This Page