On Thu, 1 Dec 2005, Peter W. Draper wrote:
>>> Having a genuinely invalid locator caused chaos as dat1_import_loc.c tried
>>> to cast this to (char *) and use the memory to construct an error message.
>>> Maybe a better way to handle that.
>>
>> I don't understand. It uses emsSetnc and that is meant to restrict the
>> number of characters that are stored in the token. It's readonly memory so
>> it shouldn't be writing in areas that are dodgy even if the pointer points
>> to random memory.
>
> Hi Tim,
>
> the fix you've done is clearly worthwhile, but doesn't get to what happened
> here. The locator was over written so had a garbage value, which didn't point
> at any accessible memory, readonly or otherwise, so that caused a core dump
> when an attempt to dereference it happened (the fact that it was during an
> error report and cast to (char *) doesn't matter).
>
> The difference is that in the past this would have mattered less, simply
> because it would be a character array that held garbage values, a point which
> HDS presumably picked up when decoding and made an error report with. Now the
> garbage hits a pointer that HDS actually tries to dereference, that's
> slightly less safe than before (I freely admit this really points to the need
> for better programming and reveals out more of your bugs more quickly). So I
> guess the change in behaviour here is, is do you really want to core dump or
> continue to make error reports about garbage locators?
Should have said that this is one of the points that David was making
about the memory handling in AST.
|