Re: RelesaseBuffer assertion in VC7



thanks guys,
So in VC6 it was still a bug but not detected, or
with current implementation of new MFC it's bug?
But I understand that I need to add NUL at the and
if ReadFile doesnt' do it.
Looks like god idea to switch to VC7 now :)

thanks

"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message
news:89n8j11j9bv54fbuckebfhrd5n4n9fvke6@xxxxxxxxxx
> On Fri, 23 Sep 2005 14:32:48 -0500, "aaron" <aaron@xxxxxxxxx> wrote:
>
>>Yes, you're right, Code is full UNICODE.
>>Assertion text is: ...in atlsimpstr.h line 718
>>Exception: nLength<=getData()->nAllocLength
>
> After adding spaces on either side of the <= operator, I find that text at
> line 791 in VC7.1. It indicates one of the things I suggested last time,
> that a nul wasn't found in the buffer filled by ReadFile.
>
>>Reason of dwSize/2 is because unicode.
>
> To add to what Joe suggested, you must ensure the data you read contains a
> nul, or you must specify the length in the ReleaseBuffer call to prevent
> CString from doing a strlen and reading past the end of the buffer. In
> pretty much all scenarios, a naked ReadFile has to be considered an error:
>
> ReadFile(hIn, sBuffer.GetBuffer(dwSize/2), dwSize, &nIn, NULL);
>
> You absolutely must check how many bytes were actually read, and you must
> check for EOF and errors. On top of that you have the ReleaseBuffer
> considerations I already mentioned.
>
> --
> Doug Harrison
> VC++ MVP


.