On Fri, 12 May 2006, Hartmut Kaiser wrote:
Richard Guenther wrote:
Not yet, but I know that this problem was on linux/gcc systems only and my main testing platform is Windows. I'll try to find a linux box with gcc 4.1 istalled today.
OTOH we had this problems on other gcc platforms earlier as well and these went away after the fix I sent you yesterday. So I'm currently a bit out of ideas.
In the mean time, could you please set the
#define BOOST_WAVE_BSIZE 196608
in the same file you fixed yesterday to something bigger as your file size? Does the error still occur?
Raising that to 262144 makes it work. That gives me another hint to where to look.
Doh! Then there is something wrong with the code loading the next chunk of data for large files. This should be reproducible for very small files with
#define BOOST_WAVE_BSIZE 16
now. Is there a '\\n' backslash/newline in your file somewhere around the 'magic' buffer size we had?
I'll have a look at this later this weekend. Regards Hartmut
This patch fixes it for me (again against the 1.33.1 sources). The problem is that after doing the last buffer read with fill, s->lim is zeroed out by the subsequent RET (identifier) as limit was not updated after the call to fill. Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs --- cpp_re.cpp.orig 2006-05-15 13:29:00.000000000 +0200 +++ cpp_re.cpp 2006-05-15 13:31:59.000000000 +0200 @@ -51,7 +50,7 @@ #define YYCURSOR cursor #define YYLIMIT limit #define YYMARKER marker -#define YYFILL(n) {cursor = uchar_wrapper(fill(s, cursor), cursor.column);} +#define YYFILL(n) {cursor = uchar_wrapper(fill(s, cursor), cursor.column); limit = uchar_wrapper (s->lim); } //#define RET(i) {s->cur = cursor; return (i);} #define RET(i) \ @@ -187,7 +186,7 @@