RE: calling script with dobuffer doesnt work

[Luiz Henrique de Figueiredo <lhf@...>]

>> I was checking my file for this EOF marker, but there was none. Next, I
>> removed the CR (0x0D), and this worked fine. I never thought this
>> could be a
>> problem, so it took some time until I finally tried what first seemed
>> improbable to me. Is this a bug, or a feature?!
>
>I would put that in the bug list... A really portable application should
>handle EOL as CR, LF or CR+LF.

This is not a bug. See below.
To me, it's still not clear what happened, but here are some facts:

- The lexer simply ignores CR. It uses LF for signalling change of line (and
  thus for keeping track of line numbers) but otherwise, LF is just whitespace.
  So, the problem is not the presence or absence of CR.

- If the string contains a DOS EOF marker (control-Z), then you'll get an
  syntax error. This is correct: control-Z has no meaning for Lua because it
  has no meaning for ANSI C.

- It is possible that the same file works ok when run with lua_dofile and not
  work ok when run with lua_dobuffer after it's read into a buffer: stdio takes
  care of CR+LF and control-Z before Lua sees it. So, if you open the file 
  in BINARY mode, read it into a buffer and then call lua_dobuffer, anything
  can happen... (probably a control-Z will be read and sent to Lua).
  So, make sure you open the file in TEXT mode.

Someone suggested that the fault is probably in how lua_dobuffer was called:
the length of the buffer was probably wrong: if buffer is declared as
	char buffer[MAXB]
the correct code is NOT lua_dobuffer(L,buffer,MAXB,"a name"); it's likely that
what you want is lua_dobuffer(L,buffer,strlen(buffer),"a name"), in which case
it's easier to use lua_dostring instead.

I think this was the problem, but we'd have to see the code to be sure.
--lhf