Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

@EXECSTR line length limit? ... misbehavior?

May
13,190
180
Outside TCC, I've been playing with MAPM, the arbitrary precision math library that TCC uses. The command ipow.exe 500 5000 correctly sends the number 500^5000 (13495 characters) to stdout. I thought that would be OK with @EXECSTR but echo %@execstr[ipow.exe 500 5000] produces 13506 characters, and among those characters are 00000000㘴ㄵ〵㠷㘱㌸㔶㘸抵쁎鹷00000000.

Any idea what's going on?
 
@EXECSTR seems to be able to handle much longer strings, but it produces more of the garbage output. In fact, the garbage output occurs regularly, almost exactly every 8K characters.
 
Here's IPOW.EXE (zipped). Run IPOW 500 50000 > file1.txt and echo %@execstr[IPOW.EXE 500 50000] > file2.txt and compare the files. Look near byte 8192. Or just run the second command without redirection and scroll back to see the corruption (might need 2000+ console rows).

Code:
v:\> IPOW 500 50000 > file1.txt

v:\> echo %@execstr[IPOW.EXE 500 50000] > file2.txt

v:\> cmp file1.txt file2.txt | head
file1.txt file2.txt differ: char 8193, line 1
 

Attachments

Or, if you are wary, do this. (Note: @eval gives the wrong answer)

Code:
v:\> echo %@eval[500**50000] > file1

v:\> echo %@execstr[echo %@eval[500**50000]] > file2

v:\> cmp file1 file2
file1 file2 differ: char 8193, line 1
 
The problem here wasn't with @execstr, it was because you are loading a 134K line into a 64K (maximum line size) buffer.

I made a change in 30.0.19 to allow a max line size of 2Gb. But don't do that.

Regarding @eval, it returns the same result as your ipow.exe, provided I use the correct syntax and set the max precision.
 
The problem here wasn't with @execstr, it was because you are loading a 134K line into a 64K (maximum line size) buffer.
I don't think that's at the heart of the problem. Here's v29 with a rather small file/line.

1686597343786.png
 
Regarding @eval, it returns the same result as your ipow.exe, provided I use the correct syntax and set the max precision.
Yeah but that's only because 500^50000 has lots of zeroes at the end. Here's a simple example of @EVAL not doing integer exponentiation as well as it might. This should not end in a 0.

Code:
v:\> echo %@eval[2**103]
10141204801825835211973625643010
 
Back
Top
[FOX] Ultimate Translator
Translate