{"push_id":941168388,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"18522a09a5a9ecbc90dd4f20345ec5f1c78061a2","before":"42b1c44ac0d49f788cec1c17ad253513916aca58","commits":[{"sha":"18522a09a5a9ecbc90dd4f20345ec5f1c78061a2","author":{"email":"b781ed5e0db0289e0ee7f8a9017405c56a2ca6f3@gmail.com","name":"Thomas E. Enebo"},"message":"YYYYYEEEEEHHHHHAAAAWWWWW\n\nOk.  So I think I finally solved the problem with FindFirstFileW.  There\nwere two problems.  One was being hit and I think one was waiting to be\nhit:\n\n1. TCHAR is either 1 byte or 2 bytes depending on use.  Since I was\ncalling with a wide (W) method I needed 2 bytes but I misread this and\nneeding 1 byte chars.  So now it is unsigned short (which is what wchar_t\nseems to be on windows).\n2. This one is more sketchy but I found two mentions that MAX_PATH in this\nstruct can still overflow even though we are honoring the contract of\nthe struct and the functions which use this struct.  One is in rare cases\nyou can try to findfirstfile on a reparsepoint and it can return\n>MAX_PATH.   The second implied that since NTFS can accept paths up to\n32767 that you might somehow get that pushed back into the struct.\n\nSo #2 is pretty sketchy but since we don't actually use these fields I\nthink it is ok to allocate enough memory to guarantee we never overflow\nto be worth the cost.","distinct":true,"url":"https://api.github.com/repos/jnr/jnr-posix/commits/18522a09a5a9ecbc90dd4f20345ec5f1c78061a2"}]}