Re: Testsuite summary for GNU Bison 3.8.2 : FAIL 2

[Akim Demaille]

Hi Dennis,

> Le 15 oct. 2021 à 01:01, Dennis Clarke <dclarke@blastwave.org> a écrit :
> 
> On 10/14/21 01:28, Akim Demaille wrote:
>> Hi Dennis,
>> 
>>> Le 14 oct. 2021 à 03:40, Dennis Clarke <dclarke@blastwave.org> a écrit :
>>> 
>>> *res = {
>>>   name  = 0x105c30 "<bad address 0x0000000000105c30>"
>>>   type  = 0
>>>   value = {
>>>       var = 0.0
>>>       fun = (nil)
>>>   }
>>>   next  = (nil)
>>> }
>> 
>> Really???  So it seems that strdup on this machine is dead broken.
> 
> This will be really silly long but strdup seems to work just fine :
> 
> beta $ cat /tmp/foo.c
...
> #define _XOPEN_SOURCE 600

Would that be the difference?  If you define this early enough in
the original test case, does it work properly?

I have attached "without-my-strdup.y", that must be installed as
mfcalc.y, for convenience.


> That actually looks pretty good given that the mfcalc output seems
> correct and we have a bucket of debug printout stuff in there as noise.
> However the results look correct.

Yes, this time the test was passing.  So yes, we do have a problem
with strdup.

Please check with-my-strdup.y.


> Funny thing, the exact same code blows up in a spectacular fashion on
> Debian Linux sid on ppc64.

What do you mean?  my_strdup is expected to be portable.  It passes
on this MacOS.

> Yet another thing slightly off topic looking at the core dump from
> c++-types I see :
> 
> ...
> 
> So that is recursive fun and strlen(child2) should be zero? Given that
> it is NULL we end up at the res = malloc (1) with no checks anywhere
> that the malloc even works but anyways maybe it is best to just look at
> the mfcalc stuff for now.

The code looks right to me.  And passed asan and ubsan.  I'm pretty
sure it's strdup that does not work again.

Cheers!

without-my-strdup.y
Description: Binary data

with-my-strdup.y
Description: Binary data