jackieku wrote:
The original code uses bytes_actually_read - 1, but after I read the current code I think it shouldn't be -1.
I think that would make it inaccurate. See below:
Code:
-- script2.cpp/BIF_StrLen()
? aParam[0]->var->Length() + aParam[0]->var->IsBinaryClip() // i.e. Add 1 if it's binary-clipboard, as documented.
-- var.cpp/AssignClipboardAll()
mByteLength = actual_space_used - sizeof(TCHAR); // Omit the final zero-byte from the length in case any other routines assume that exactly one zero exists at the end of var's length.
I suppose it was originally intended to use the last byte of the binary clipboard data as the variable's null-terminator (while still including it in StrLen()), but since it isn't necessarily going to be zero (null) when read from an arbitrary file, it might not be safe.
Perhaps we should change mByteLength to match the actual size of the data, and also ensure the usual null-terminator is present (remove the - 1 from A below). Running the script below caused two assertion failures, leading me to lines A and B.
Code:
Clipboard := "TEST"
a := ClipboardAll
b := a
Code:
--A: var.cpp/AssignClipboardAll()
if (!Assign(NULL, space_needed - 1, true, false))
--B: var.cpp/AssignBinaryClip()
if (!Assign(NULL, source_var._CharLength()))
...
LPVOID binary_contents_max = (char *)binary_contents + source_var.mByteLength + sizeof(TCHAR);
--C: script.cpp/Perform()
? ARGVARRAW2->Length() + 1 // +1 to include the entire 4-byte terminator, which seems best in this case.
A should be SetCapacity() as space_needed is in bytes. It would make sense to add aExactSize=true, aObeyMaxMem=false to
B, for consistency with
A and because it is unlikely that the variable will need the extra space.
There's may be something else I've missed.
Edit - Hmm, the following shows "1,0" on AutoHotkeyU whereas it should show ",-2"
Code:
MsgBox % DllCall("MulDiv", "int", 2, "interchangable", 4, "integer", 8, "intriguing") "," ErrorLevel
I'll take care of this one...
Login
Register
FAQ
Search
