1) it would be better, but given that it breaks backward compatibility for something that technically should not be used, it's probably not worth fixing.
2) You didn't really give strong example of why empty binvar are needed, an example is this one, happened to me helping westor communicating using RCON protocol over socket:
With a binary protocol, where a newline is not what define a packet, you must keep a buffer of the data until you have enough data to form a 'packet', in this case I simplified it so that whenever we have 4 bytes or more from our buffer, we delete those 4 bytes from the buffer. /bcopy does not accept a position larger than the length of the binvar, which is normal, but in this case when you reach 4 bytes exactly remaining in the binvar, bcopy will then fail, which is not handy in this case. You must then workaround it the way maroon suggested to create an empty binvar so that /hadd won't fail. One may argue this example is easily solved by setting a variable instead, and checking the variable before /hadding &buffer or else hdeleting that item, but it still illustrates the need.
So I agree and like your /bset suggestion to create an empty binvar, but I think that the -c switch should be extended to not give an error if no byte parameter is passed, to create an empty binvar
2bis) I also would like a new switch for bcopy (or maybe extending -c as well) which would allow a position to be larger than the length of the binvar and if a larger position is passed then the binvar is chopped at the position N, making the entire else not required in the above example
ON *:SOCKREAD:test: {
sockread $sock($sockname).rq &read
noop $hget(buffer,buffer,&buffer)
bcopy &buffer -1 &read 1 -1
while ($bvar(&buffer,0)) {
if ($bvar(&buffer,0) < 4) return
if ($bvar(&buffer,0) >= 4) bcopy -c &buffer 1 &buffer 5 -1
else {
bunset &buffer
noop $regsubex(name,,,,&buffer)
}
hadd buffer buffer &buffer
}
}3-5-7) Having control about signed/unsigned, 16bits/32bits numbers for the input and the output would be superb.
4) same answer as 1)
6) yes but definitely the 4th parameter syntax, which preserves backward compat
8) Yes!
9) yes but I think the switch should be -f for file offset, rather than -p, which could be confused with -p of /bset.
