[RPL/2] did i found a bug ?

[BERTRAND Joel]

DEMAINE Benoit-Pierre a écrit :
> On 15/11/10 16:13, BERTRAND Joel wrote:
>>      And it's not a workaround. I'm not pushed this patch in main tree
>> because there is a side effect:
>>
>> RPL/2>  { 123+ }
>>
>> is treated as syntax error but RPL/2 enters in a deadlock... Same
>> constatation with<[ 123+ ]>.
>
> I just pointed that, to me, a memory allocation error is an unexpected
> behaviour; i have no clue what is the expected behaviour; you are the
> author, and you, and only you know how RPL should behave. I made a typo,
> and it ended up in, from MY point of view, to use "ordinary computing
> words", a segfault.

	Try rpl -isd and all memory error won't be caught. You shall obtain 
segfault. In normal operation, RPL/2 catches SIGSEGV to close all 
pipes/files/shared memory/semaphores/process/threads/whatever. When your 
application only has one thread, it's not a problem. Your application 
crashes with a core dump and your OS has to clean up process memory. If 
your application is multithreaded, you has to return an error code to 
parent's thread and to stop all child threads.

	Now "memory allocation error" comes from malloc() itself when this 
malloc() returns NULL pointer. And memory allocation error is not an 
access violation because when memory allocation error is caught, you 
haven't tried to access to memory.

> I just came to report, and test your patch as you asked me.

	And I said: this patch is not good enough to be pushed into next 
release. Problem comes from recursive parser that does not handle 
recursive syntax error.

> Did you repro the bug when pasting my inputs in your own version before
> patch ? if yes, you can fix it without me.

	Yes, I can. But this bug is not fixed yet.

	JKB