Problems with BPEEK

#1
SET buffer=%@BALLOC[100]
echo %buffer
echo poke %@BPOKE[%buffer,0,8,0x01020304]
echo peek %@BPEEK[%buffer,0,8]
echo free %@BFREE[%buffer]


I thought this would echo something representing 0x01020304 on the "peek"
line, but I just get 0.


TCC 11.00.52 Windows 7 [Version 6.1.7600]
TCC Build 52 Windows 7 Build 7600


TCC 12.00.30 Windows 7 [Version 6.1.7600]
TCC Build 30 Windows 7 Build 7600



--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 
#2
From: Jim Cook
| SET buffer=%@BALLOC[100]
| echo %buffer
| echo poke %@BPOKE[%buffer,0,8,0x01020304]
| echo peek %@BPEEK[%buffer,0,8]
| echo free %@BFREE[%buffer]
|
|
| I thought this would echo something representing 0x01020304 on the
| "peek"
| line, but I just get 0.

Same here. I added a "dump" of the entire buffer, and found, to my surprize, that @BALLOC does NOT initialize the buffer at all. I think that's worth mentioning in HELP page f_balloc.btm.
However, when I tried the same batch file in earlier versions, Iit also failed in V11, but worked in V10. Something must have changed btw. V10 and V11.
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
10,412
95
#3
SET buffer=%@BALLOC[100]
echo %buffer
echo poke %@BPOKE[%buffer,0,8,0x01020304]
echo peek %@BPEEK[%buffer,0,8]
echo free %@BFREE[%buffer]

I thought this would echo something representing 0x01020304 on the "peek" line, but I just get 0.
The problem here is that you've invented a non-existent feature -- the last argument to @BPOKE should be decimal, not hex.
 
#4
---- Original Message ----
From: rconn
To: [email protected]
Sent: Monday, 2010. October 25. 15:17
Subject: RE: [Support-t-2365] Re: Problems with BPEEK

| Quote:
| Originally Posted by Jim Cook
| SET buffer=%@BALLOC[100]
| echo %buffer
| echo poke %@BPOKE[%buffer,0,8,0x01020304]
| echo peek %@BPEEK[%buffer,0,8]
| echo free %@BFREE[%buffer]
|
| I thought this would echo something representing 0x01020304 on the
| "peek" line, but I just get 0.
|
| The problem here is that you've invented a non-existent feature --
| the last argument to @BPOKE should be decimal, not hex.

AFAIK this is the only place in TCC where hexadecimal is not accepted where numeric value is expected.
--
Steve
 
#6
>
>
> The problem here is that you've invented a non-existent feature -- the last
> argument to @BPOKE should be decimal, not hex.
>
>
A slightly modified test batch here shows that 11.00.49 worked as I expected
and 11.00.52 does not. I expected it to work as it did in all the early (at
least up to 11.00.49) and version 10 (I am taking Steve's report as fact for
this).

SET buffer=%@BALLOC[100]
echo %buffer
echo poke %@BPOKE[%buffer,0,8,0x01020304]
echo peek %@BPEEK[%buffer,0,1]
echo peek %@BPEEK[%buffer,1,1]
echo peek %@BPEEK[%buffer,2,1]
echo peek %@BPEEK[%buffer,3,1]
echo free %@BFREE[%buffer]


D:\>ver

TCC 11.00.49 Windows 7 [Version 6.1.7600]

D:\>test
3ca0a80
poke 0
peek 4
peek 3
peek 2
peek 1
free 0

D:\>ver

TCC 11.00.52 Windows 7 [Version 6.1.7600]

D:\>test
23a1958
poke 0
peek 0
peek 0
peek 0
peek 0
free 0

D:\>


--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 
#7
---- Original Message ----
From: rconn
To: [email protected]
Sent: Monday, 2010. October 25. 15:55
Subject: RE: [Support-t-2365] Re: Problems with BPEEK

| Quote:
| Originally Posted by Steve F�bi�n
| AFAIK this is the only place in TCC where hexadecimal is not accepted
| where numeric value is expected.
| Steve
|
| Nope; there are a lot of others.
|
| But this is one of the very few that takes 64-bit input (which
| doesn't support optional hex anywhere).

I hadn't reason to test 64-b input in the past. However, as the @BPEEK and the @BPOKE functions are essentially byte-oriented, as the size field parameter clearly implies, IMHO @BPEEK should accept hexadecimal input, and @BPOKE should have the option to report its value in hexadecimal.
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
10,412
95
#8
A slightly modified test batch here shows that 11.00.49 worked as I expected and 11.00.52 does not. I expected it to work as it did in all the early (at least up to 11.00.49) and version 10 (I am taking Steve's report as fact for this).
That (undocumented, unsupported) behavior went away when 8-byte variable support was added.

Note that the help file says nothing about hex support.
 

rconn

Administrator
Staff member
May 14, 2008
10,412
95
#9
I hadn't reason to test 64-b input in the past. However, as the @BPEEK and the @BPOKE functions are essentially byte-oriented, as the size field parameter clearly implies, IMHO @BPEEK should accept hexadecimal input, and @BPOKE should have the option to report its value in hexadecimal.
Submit it in the Suggestions forum. It will *not* be in v12.
 
#10
----- Original Message -----
From: rconn
To: [email protected]
Sent: Monday, 2010. October 25. 16:44
Subject: RE: [Support-t-2365] Re: Problems with BPEEK


Quote:
Originally Posted by Steve F�bi�n
I hadn't reason to test 64-b input in the past. However, as the @BPEEK and the @BPOKE functions are essentially byte-oriented, as the size field parameter clearly implies, IMHO @BPEEK should accept hexadecimal input, and @BPOKE should have the option to report its value in hexadecimal.

Submit it in the Suggestions forum. It will *not* be in v12.