YoriInit.ys1 script %__APPDIR__% and %__CD__% environment variables on Windows XP about yori HOT 2 CLOSED

Thanks, this looks like a(nother) Windows bug.

On Windows XP, the function that expands these looks like:

*lengthReturned = sizeOfNewString;
if (bufferSize >= sizeOfNewString) {
    memcpy(buffer, newString, sizeOfNewString);
}
return SUCCESS;

The "return success" part is a bug because the contract was to fail with an error indicating an insufficient buffer. This causes the function to complete back to the caller with uninitialized data.

But there's a second, worse bug, that looks like

if (InnerFunction(&lengthReturned) == SUCCESS) {
    buffer[lengthReturned] = '\0';
}

So in addition to leaving the buffer uninitialized, it will write to invalid memory. This one is harder to work around, and causes this to crash immediately when using a debug version of Yori (that ensures the next page is marked invalid.) So on XP, I think GetEnvironmentVariable either has to ensure these variables are not used, or the caller needs to supply a 64Kb buffer (being the largest representable string) to ensure the function can't fail due to insufficient buffer space.

I think the best fix is to detect these variables and handle them internally. Yori already handled %CD% so adding %__CD__% seems straightforward. %__APPDIR__% is very similar to ~appdir which Yori also already expands. (Frustratingly, %__APPDIR__% would be implemented with GetModuleFileName, which also can't indicate how much buffer it needs, and other uses of this function just use a pessimistic buffer size.)

from yori.

It's perfect this can be fixed someway. These variables sometimes have drastic value! At least for now i'm happy with ~appdir in .ys1 files

from yori.