Application Crash and Faulting Offset
-
@Juan-Dev
Yes, it looks like in the old code you did not allocate room for the extra byte forptrExtract. Now you do.Since it is
extractContent()which allocates room for the terminating\0byte I would set that byte inextractContent()rather than inmain.cppfor clarity, but that is up to you.You code currently relies on the
LONG_EXTRACTinmain.cppbeing equal to thesizeExtractcalculated(?) inextractContent(). It could be less than that, but must not be more (because of themalloc()). This is the kind of "hidden" requirement which can be hard to spot if it goes wrong, you should link these two values as appropriate.In case you are not aware, you might like to use std::memcpy( void* dest, const void* src, std::size_t count ) (or C
memcpy()) to copy the bytes instead of yourforloop:std::memcpy(ptrExtract, ptrMemoryFonc + cursorStart, sizeExtract);Less of your own code to check/clearer :)
@JonB Thank for your answer
Since it is extractContent() which allocates room for the terminating \0 byte I would set that byte in extractContent() rather than in main.cpp for clarity, but that is up to you.
The extract function is sometimes used to extract an area to which I do not necessarily add a '\0' character. This is why I did not integrate this addition into the function itself.
But we agree that even if this character will not be added later, I can reserve a memory space with one more character in my function, this does not pose a problem...?In case you are not aware, you might like to use std::memcpy() to copy the bytes instead of your for loop.
Less of your own code to check/clearer :)We agree on the code to check :). Thank you for this valuable information. I'll look into setting this up.
-
@JonB Thank for your answer
Since it is extractContent() which allocates room for the terminating \0 byte I would set that byte in extractContent() rather than in main.cpp for clarity, but that is up to you.
The extract function is sometimes used to extract an area to which I do not necessarily add a '\0' character. This is why I did not integrate this addition into the function itself.
But we agree that even if this character will not be added later, I can reserve a memory space with one more character in my function, this does not pose a problem...?In case you are not aware, you might like to use std::memcpy() to copy the bytes instead of your for loop.
Less of your own code to check/clearer :)We agree on the code to check :). Thank you for this valuable information. I'll look into setting this up.
@Juan-Dev said in Application Crash and Faulting Offset:
But we agree that even if this character will not be added later, I can reserve a memory space with one more character in my function, this does not pose a problem...?
Absolutely, this is fine. And you must do so in case you do add the terminator. So far as the
malloc()/free()is concerned that works fine; what you do with/without the terminating\0is a different matter.You still have a "dependency" between the value of
LONG_EXTRACTin the caller and the value ofsizeExtractinextractContent()'s call tomalloc(). IfLONG_EXTRACT > sizeExtractyou will have a "hidden" write of a byte beyond themalloc()ed area, which can be hard to spot. I would still make some relationship between those two values, even if it's just that the caller checksLONG_EXTRACTagainst the returned&sizeExtractedContent. If they are supposed to be the sameextractedContent[sizeExtractedContent] = '\0';would be safer. Using a separateLONG_EXTRACThere only makes sense if it can be less thansizeExtractedContent. -
@Juan-Dev said in Application Crash and Faulting Offset:
But we agree that even if this character will not be added later, I can reserve a memory space with one more character in my function, this does not pose a problem...?
Absolutely, this is fine. And you must do so in case you do add the terminator. So far as the
malloc()/free()is concerned that works fine; what you do with/without the terminating\0is a different matter.You still have a "dependency" between the value of
LONG_EXTRACTin the caller and the value ofsizeExtractinextractContent()'s call tomalloc(). IfLONG_EXTRACT > sizeExtractyou will have a "hidden" write of a byte beyond themalloc()ed area, which can be hard to spot. I would still make some relationship between those two values, even if it's just that the caller checksLONG_EXTRACTagainst the returned&sizeExtractedContent. If they are supposed to be the sameextractedContent[sizeExtractedContent] = '\0';would be safer. Using a separateLONG_EXTRACThere only makes sense if it can be less thansizeExtractedContent.@JonB
The part of the code I posted is confusing, I'm sorry.
But I don't always have a dependency in the full application code.In the full application, the
extractContent()function can be used to extract variable-length portions of memory.
And for some extracted portions I control the fixed length and add a '\0' character.
And for others I simply use the extracted portion without checking or adding characters
