[PATCH] mswin32-vc6 segmentation fault due ruby_in_eval wrong definition

Summary:

Working in collaboration with Aman Gupta, we were trying to make
ParseTree on Windows a fully working gem+extension. During the process
of testing the changes, we found a segmentation fault raised by the C
extension in ruby_in_eval increment:

ruby_in_eval++;
... some code ...
ruby_in_eval--;

The synthetic code was reduced to this:

#include "ruby.h"
#include "env.h"

void Init_test_in_eval()
{

  printf("&ruby_safe_level: %d\r\n", &ruby_safe_level);
  printf("ruby_safe_level = %d\r\n", ruby_safe_level);

  printf("&ruby_in_eval: %d\r\n", &ruby_in_eval);
  printf("ruby_in_eval = %d\r\n", ruby_in_eval);

  ruby_in_eval++;
  ruby_in_eval--;
}

Trying to find why this was happening, found that env.h defined:

extern int ruby_in_eval;

in contrast with ruby_safe_level (ruby.h):

RUBY_EXTERN int ruby_safe_level;

I took ruby_safe_level for comparison only and isn't used directly by
ParseTree code.

This problem block us continue checking the ParseTree windows
compatibility. ruby_in_eval was referenced but pointed to garbage
memory...

Solution:

Attached is a patch for ruby_1_8 branch that correct this. Done a
build test of the checkout with the modification in case this was used
internally by ruby. Everything work without problems, now the
test_in_eval extension and ParseTree compiles and run without crashes.

Since 1.9 moved away from ruby_in_eval to rb_parse_in_eval() there is
no need to back port the change to trunk.

We are looking forward this patch gets committed.

Regards and have a nice week everybody.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi