Open tbonfort opened 12 years ago
Author: dmorissette Date: 2007/02/01 - 15:52
This is probably not specific to PHP. Adding Steve to CC.
Author: sdlime Date: 2007/02/01 - 20:41
That's a test case that I never tried. I'm not sure why it wouldn't work but I
imagine there is some state information that needs to be reset between runs of
the tokenizer. Switching component to the main C library...
Steve
Author: dmorissette Date: 2007/08/01 - 22:55 Steve,
I was able to reproduce this with 5.0-beta2 and stepped through it in the debugger. It turns out that the issue seems to be caused by include_stack_ptr being left to a value of -1 after we hit EOF on the first mapfile.
Then the second parse starts with include_stack_ptr=-1 and never returns an "unexpected EOF" error.
The following patch seems to fix the issue, but I'm not sure if that's the best way to go. I think forcing include_stack_ptr=0 in some initialization code might be better so that in case of errors during parsing of an included file we still start up clean, but I didn't look for or find the right location to do it. I'll leave that to you.
--- maplexer.l (revision 6436)
+++ maplexer.l (working copy)
@@ -521,9 +521,10 @@
<INITIAL>\n { msyylineno++; }
<INITIAL><<EOF>> {
- if( --include_stack_ptr < 0 )
+ if( --include_stack_ptr < 0 ) {
+ include_stack_ptr = 0;
return(EOF); /* end of main file */
- else {
+ } else {
fclose(YY_CURRENT_BUFFER->yy_input_file);
msyy_delete_buffer( YY_CURRENT_BUFFER );
msyy_switch_to_buffer(include_stack[include_stack_ptr]);
Author: dmorissette Date: 2007/08/01 - 22:59 Sorry, typo in the comment above. I meant:
"Then the second parse starts with include_stack_ptr=-1 and returns an "unexpected EOF" error."
Author: sdlime Date: 2007/08/15 - 06:39 For a second I thought you had applied the patch, but I see haven't. A test I did here didn't show the issue, but I was using Perl MapScript. I think you're right though, better to initialize so I updated the lexer initialization code for file and string parsing to set the include_stack_ptr to 0. Can you guys confirm this fixes the issue?
For the record, my test script (everything expands correctly when saved):
#!/usr/bin/perl
use mapscript;
$map1 = new mapscript::mapObj('test1.map') or die "Map 1: ". mapscript::msGetErrorString("\n");
$map2 = new mapscript::mapObj('test2.map') or die "Map 2: ". mapscript::msGetErrorString("\n");
print $map1->{name} ."\n";
print $map2->{name} ."\n";
$map1->save('test1.saved.map');
$map2->save('test2.saved.map');
Author: sdlime Date: 2007/08/15 - 06:41 Marking as fixed for 5.0. Any reason to backport to 4.10? If so, we can reopen...
Steve
Author: dmorissette Date: 2007/08/15 - 15:43 I have verified that the issue is gone with the fix in e4a950ca8bc069b86309c7dbff6fad45e098f983 (r6587).
Reporter: johan.vandewauw@gmail.com Date: 2007/02/01 - 14:24