Problems with BPEEK

[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.


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.

 

[Steve Fabian]

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]

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.

 

[Steve Fabian]

---- 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

 

[rconn]

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).

 

[Jim Cook]

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

 

[Steve Fabian]

---- 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]

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]

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.

 

[Steve Fabian]

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