Comments and suggestions on functions for binary buffers

May 29, 2008
571
4
Groton, CT
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.
 
May 20, 2008
11,409
99
Syracuse, NY, USA
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.
 
May 29, 2008
571
4
Groton, CT
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

Administrator
Staff member
May 14, 2008
12,350
150
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!)
 
May 29, 2008
571
4
Groton, CT
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.
 
Similar threads
Thread starter Title Forum Replies Date
V Comments from a first-time user (TCC 26) Support 6
R Documentation v25 Help Comments Support 1
Joe Caverly @SCRIPT does not like all comments Support 2
Dan Glynhampton Documentation v16 Documentation comments Support 4
Dan Glynhampton Documentation Some v16 documentation comments Support 0
D Installer comments Support 2
rconn News Take Command v25 Suggestions Support 0
rconn News Suggestions Forum Support 8
D Started suggestions, not in this version (yet?) Support 1
C Suggestions for Compare Folder Tree routine Support 5
S Closing date for V16 suggestions Support 1
J Suggestions... Support 1
S HELP suggestions - What's New page Support 3
S V12 suggestions Support 0
M Any suggestions for Windows 7 Virtual PC? Support 3
C Few questions and suggestions Support 2
rconn Suggestions for v10 Support 5
A Problem with functions @int @decimal and identifying Powershell as a shell. Support 12
Joe Caverly "Functions" in cmd.exe batch files Support 6
vefatica Library functions and line continuations? Support 4
Charles Dye Documentation Help Nits Forever: Checksum functions Support 0
Joe Caverly SETLOCAL removes Aliases and Functions Support 3
Joe Caverly @NAME supports library functions Support 2
Charles Dye Functions which no-one has ever tried to use.... Support 5
vefatica WHICH and @functions Support 2
vefatica Two @FUNCTIONs/aliases with the same name Support 4
M Keywords for commands, functions, internal variables Support 3
C Documentation near or fully obsolete functions Support 7
Charles Dye Optional F parm in checksum functions Support 0
C coding functions and subroutines Support 9
rps Functions @year[date] @isowyear[date] help Support 7
mikea How to? TCC and XMLnodes/XMLxpath functions Support 0
Dan Glynhampton Are these two functions the same? Support 2
M How to? Logic in functions... Support 5
A WAD function return values with parentheses prevent evaluation of additional functions Support 31
M "History" command not giving me what I want when executed by @Exec... functions... Support 6
Charles Dye Web help on functions Support 2
samintz Help examples for the @ISxxx functions Support 3
R specific functions for number conversion Support 2
C Unsuppressable errors from XML functions Support 5
nikbackm Checksum functions Support 4
J TCC Out of memory with aliases and functions Support 5
Peter Bratton Disappearing functions Support 1
A I dont see anything in the alias/functions/batchvariables tabs in IDE Support 13

Similar threads