Using Replace to replace Chr 0 in string with ""
Archives Forums/Blitz3D Bug Reports/Using Replace to replace Chr 0 in string with ""
| ||
| And by the way, the 50 char topic title length is still ridiculously short. --- So, using the 'Replace' function to replace Chr( 0 ) with an empty string results in a crash (tested in debug mode on Windows 7). The crash doesn't occur if you replace the Chr( 0 ) with a single character non-empty string, but does occur if the replacement string has multiple chars. This crashes. strval$ = "abcdefg" + Chr( 0 ) strval$ = Replace( strval$, Chr( 0 ), "" ) This crashes. strval$ = "abcdefg" + Chr( 0 ) strval$ = Replace( strval$, Chr( 0 ), "asd" ) This doesn't crash. strval$ = "abcdefg" + Chr( 0 ) strval$ = Replace( strval$, Chr( 0 ), "a" ) Not sure if this is an actual bug or just something that needs to be caught by the debugger. It depends on what's meant to be happening under the hood. Last edited 2012 |
| ||
| It's odd that they all work with BlitzPlus. I assumed it would be the same as Blitz3D. |
| ||
| This is a bug. Blitz strings aren't documented as treating Chr(0) in a special way, so they shouldn't. Also, it's the nasty kind of crash that the runtime clearly wasn't designed to handle, not a nice clean MAV. BlitzPlus doesn't appear to have a problem with this, incidentally. |
| ||
Here's a bug report from ten years ago. I think this was fixed but has come back from the dead.; Blitz return "déplor" !!!
Result$ = Trim$ (" déploré ")
Print Result$
WaitKey |
| ||
| I don't know if this can be named a "bug" blitz-string are const char* array terminated with a "0" So if you remove the ending "0" byte you'll end with non-terminated string causing the allocation of the string (read/write) to go outside the memory allocated size. Then, it's not documented, and that's a mistake, but not sure it's a bug (according it probably does what it is supposed to) But I think, blitz should not allow to replace the ending "0" char in any way Then, there is probably something wrong at this point ps : you can overwrite the Trim function Function Trim$(v$) Local l$="", t$=Chr(9), ln=Len(v):If ln=0 Then Return "" Repeat : l=Left (v,1) : If l<>" " And l<>t : Exit : EndIf : ln=ln-1 : v=Right(v,ln) : Until ln<1 : If ln=0 Then Return "" Repeat : l=Right(v,1) : If l<>" " And l<>t : Exit : EndIf : ln=ln-1 : v=Left (v,ln) : Until ln<1 : Return v End Function Last edited 2012 |
| ||
| blitz-string are const char* array terminated with a "0" No they aren't. Blitz strings are Pascal-style: a size prefix followed by any bytes you want. They get automatically converted to C strings when passed to a DLL, but don't use that form internally. You absolutely are supposed to be able to use the null byte in a Blitz string if you want to, because they don't use a terminator code; they don't need one. |
| ||
This seems not to crash:Chr0$=Chr(0) strval=Replace(strval,chr0,"") WaitKey() ___ Incidentally, I should mention that the format referred to by Yasha holds the string length as a 16-Bit short Int, essentially limiting BlitzStrings to 65535 characters in length. |
| ||
| pj, it may not crash cause strval$ is empty? there really seems to be a problem with Replace and chr 0. even if you replace it eg. by "x", replace will quit after findung a chr 0, ignoring and cutting off the rest of the string. here's a replacement for replace...
a$="abcdefg" + Chr$(0) + "xyz"
b$=Replace2$(a$,Chr$(0),"")
Print b$
Function Replace2$(a$,c$,r$) ; about 12 times slower
For i=1 To Len(a$)
If (i+ (Len(c$)-1) )<=(Len(a$))
mi$=Mid$(a$,i,Len(c$))
if mi$=c$
aa$=""
zz$=""
If i >1 Then aa$=Left$(a$,i-1)
If (1+(i+Len(c$)))<Len(a$) Then zz$=Right$(a$,1+ Len(a$)-(i+Len(c$)) )
a$=aa$+r$+zz$
EndIf
EndIf
Next
Return a$
End Function
btw. blitz does not limit string lenght to 16 bit. I guess it's signed 32 bit int, so up to 2 billion. pretty long string tho :o] |
   |