Hi Dennis,
> Le 15 oct. 2021 à 01:01, Dennis Clarke <dcla...@blastwave.org> a écrit :
>
> On 10/14/21 01:28, Akim Demaille wrote:
>> Hi Dennis,
>>
>>> Le 14 oct. 2021 à 03:40, Dennis Clarke <dcla...@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 600Would 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
