Hi Allen,
Allen Bierbaum wrote:
> Both of these commits (r639 and r640) were needed to get OpenSG so it
> could run with my newly added memory debugging code activated. The
> problem was that when FCPtrs's are used throughout OpenSG there are some
> routines (cast_dynamic, getCPtr(), etc) that use the pointers in a way
> that offsets and computes things based on the internal pointer to the
> memory buffer for an fc. When this pointer is NULL, the offsets and
> calculations are still performed. IMHO this is a bug and all these
> cased should actually be corrected to recognize the fact that the ptr is
> NULL and act accordingly. It just seems very risky to me to ever: a)
> compute a ptr offset with 0x0 as the base and b) to call any operation
> on a Null FCPtr.
>
> What does everyone else think though? Is this just something that is
> needed in the low-level code or should it be refactored to avoid this
> type of thing?
I'm a little torn about this. This is the hottest spot in OpenSG, and adding
anything to it is not a good idea.
What about adding a NULL test in DEBUG (not MEMORY_DEBUG) mode, but leaving it
out in opt? IMHO it should be the responsibility of the app to make sure to
never dereference NullFCs...
Dirk
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
