Day024 WriteFile Problem

Apologies in advance if I miss any relevant information.

So I've been following along on these tutorials in my quest to learn to program, and so far I've been doing really well and understanding much of it.
I ran into a problem in our Win32BeginRecordingInput function where at the very end my writefile fails.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
internal void Win32BeginRecordingInput(win32_state *State, int InputRecordingIndex)
{
	DWORD BytesToWrite = 0;
	State->InputRecordingIndex = InputRecordingIndex;

	char FileName[WIN32_STATE_FILE_NAME_COUNT];
	Win32GetInputFileLocation(State, InputRecordingIndex, sizeof(FileName), FileName);

	State->RecordingHandle = CreateFileA(FileName, GENERIC_WRITE, 0, 0, CREATE_ALWAYS, 0, 0);
	
	BytesToWrite = /*(DWORD)*/State->TotalSize;
	//Assert(State->TotalSize == BytesToWrite);
	DWORD BytesWritten;
	WriteFile(State->RecordingHandle, State->GameMemoryBlock, BytesToWrite, &BytesWritten, 0);
}


So far as I can tell it matches exactly (I had the DWORD commented out for trying to get back to my working state).

After the exe hangs until it reaches memory cap for the 1GB, I stop the debugger and get "Operation taking longer than expected"

1
2
3
game_memory GameMemory = {};
GameMemory.PermanentStorageSize = Megabytes((uint64)64);
GameMemory.TransientStorageSize = Gigabytes((uint64)4);


This was setup in an earlier video and with this code it works as expected, after a short pause from pressing 'l' it starts up and lets me record, then pushing 'l' again it begins to loop correctly. HOWEVER my loop_edit.hmi file is only set to the 64kb size.

I'm at a bit of a loss here and any help would be appreciated.
BytesToWrite is DWORD (which WriteFile expects). DWORD is 32-bit number. 32-bit number can store max 2**32-1 value. Anything above will wrap around from 0.

You are allocating 4GB memory for transient storage. 4GB is 2**32.

Basically when you are assigning TotalSize to BytesToWrite, you are actually writing following code:
1
BytesToWrite = State->TotalSize % (1<<32);
This will discard any bits from 32 and and leave whatever is left below 32nd bit - 64MB for permantent storage.

I assume you got warning about integer loosing precision in assignment due to implicit cast from 64-bit to 32-bit. And you "fixed" it by adding explict (DWORD) cast. That's the mistake. Never add such casts if you don't immediately see why its needed. Such warnings are good indications about potential error.
I should double check my warnings then because I did not receive a warning on compile. When I get back home I'll play around with it a little more and see what I get. Thanks for the swift reply!
you can enable most compiler warnings with /W4 or /Wall

The default compile settings are pretty lenient with that a bit too lenient IMO.
Oh, only IDE created projects have set warning level by default.
If you are compiling in command-line without setting any warning level, then you won't see it.

With "default" warning level W3 which is set for IDE created projects you should see this warning: https://godbolt.org/g/zuNt2N
Okay, so I double checked ya'lls suggestions and tried playing around witht eh conversions a little bit more. I think what has me confused is in Casey's copy for the day he casts everything the same way I was and on the stream video it works prefectly fine for him. Hover both my copies and his copy crash when it gets to teh "writefile" on the beginrecordinginput fuction. Its almost like it can't do the actual 64-bit math. I've double checked already that I have all c/c++ related stuff installed on Visual Studios 2015.
...... Well then.
So I decided to delete the old test.oui and loop_edit.hmi files just for giggles... and it appears to be working correctly now.

Not sure I understand why that's the case quite yet. But Very much appreciate the quick responses!
Casey allocates only 1GB for transient storage. That's why casting for him works fine. 1GB+64MB is less than 2**32.