two changes I'd like to see in version 3.1

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

two changes I'd like to see in version 3.1

Norman Ramsey-3
There are two changes I'd like to see in Lua, both of which would make
it a little easier to connect C code to Lua.

I try to be careful in my code to use const char * when I know I'm
dealing with immutable strings.  Unfortunately, many Lua functions use
parameter types of char *, even when const char * would be correct, so
I get a slew of warning messages.  It would be nice if the signatures
were updated properly.  I believe that *all* strings are immutable in
Lua, so that all instances of char * could be replaced with const
char*.

The other change I'd like to see is minor: I'd like the C version of
lua_error to have the same signature as printf.  This should 
relatively easy to implement in ANSI C using <stdarg.h> and vsprintf.

Reply | Threaded
Open this post in threaded view
|

Re: two changes I'd like to see in version 3.1

David Jeske-2
On Mon, Jun 22, 1998 at 11:52:22PM -0300, Norman Ramsey wrote:
> The other change I'd like to see is minor: I'd like the C version of
> lua_error to have the same signature as printf.  This should 
> relatively easy to implement in ANSI C using <stdarg.h> and vsprintf.

Agreed 100% :)

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: two changes I'd like to see in version 3.1

Luiz Henrique de Figueiredo
In reply to this post by Norman Ramsey-3
>From [hidden email] Mon Jun 22 23:52:23 1998
>
>There are two changes I'd like to see in Lua, both of which would make
>it a little easier to connect C code to Lua.
>
>I try to be careful in my code to use const char * when I know I'm
>dealing with immutable strings.  Unfortunately, many Lua functions use
>parameter types of char *, even when const char * would be correct, so
>I get a slew of warning messages.  It would be nice if the signatures
>were updated properly.

We have talked about this once and somehow decided that it was more trouble
than benefit. But this was a while ago.

>I believe that *all* strings are immutable in
>Lua, so that all instances of char * could be replaced with const char*.

There maybe one or two cases where strings returned by Lua to C are mutable,
ie., strings inside Lua.
But Lua certainly does not need to change strings in host space.
In this sense, you're right.

>The other change I'd like to see is minor: I'd like the C version of
>lua_error to have the same signature as printf.  This should 
>relatively easy to implement in ANSI C using <stdarg.h> and vsprintf.

I'm glad to say that this is available in 3.1. It's called luaL_verror.
It's not part of the official API because it's a convenience function,
written enirely with the API, with no inside information. See lauxlib.c.
Just for reference -- or if you're using a previous version, here it is:

void luaL_verror (char *fmt, ...)
{
  char buff[500];
  va_list argp;
  va_start(argp, fmt);
  vsprintf(buff, fmt, argp);
  va_end(argp);
  lua_error(buff);
}

Unfortunately, until the new ANSI C is out, there is no way to avoid the
fixed size buffer and the danger for overflow in vsprintf.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: two changes I'd like to see in version 3.1

Steve Dekorte-2
In reply to this post by Norman Ramsey-3
>There are two changes I'd like to see in Lua, both of which would make
>it a little easier to connect C code to Lua.
>
>I try to be careful in my code to use const char * when I know I'm
>dealing with immutable strings.  Unfortunately, many Lua functions use
>parameter types of char *, even when const char * would be correct, so
>I get a slew of warning messages.  It would be nice if the signatures
>were updated properly.  I believe that *all* strings are immutable in
>Lua, so that all instances of char * could be replaced with const
>char*.

I agree. I've been bitten by that before.

>The other change I'd like to see is minor: I'd like the C version of
>lua_error to have the same signature as printf.  This should
>relatively easy to implement in ANSI C using <stdarg.h> and vsprintf.

Speaking of errors, I wish there was a seperate error reporting mechanism
and api for parse errors. Requiring the debugger to parse the parse error
makes for a fragile interface.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: two changes I'd like to see in version 3.1

Luiz Henrique de Figueiredo
In reply to this post by Norman Ramsey-3
>From [hidden email] Tue Jun 23 04:24:33 1998
>
>Speaking of errors, I wish there was a seperate error reporting mechanism
>and api for parse errors. Requiring the debugger to parse the parse error
>makes for a fragile interface.

I'm not sure what you mean here. What API would you suggest for parsing?

Our philosophy is of course keep-it-simple. In this case, we assume that a
parse error is an error. We even stop compiling at the first error.

If you really want to tell parse errors from run time errors, then you may
use the call hook: it receives line=0 at the start of a chunk.
Thus, errors that happen before this hook is called are parse errors.
Alternatively, you can look at luac.c and see how to parse without running.
In this way, you may set different error handlers for parsing and for running.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: two changes I'd like to see in version 3.1

Alan Watson-2
In reply to this post by Luiz Henrique de Figueiredo
> void luaL_verror (char *fmt, ...)
> {
>   char buff[500];
>   va_list argp;
>   va_start(argp, fmt);
>   vsprintf(buff, fmt, argp);
>   va_end(argp);
>   lua_error(buff);
> }
> 
> Unfortunately, until the new ANSI C is out, there is no way to avoid the
> fixed size buffer and the danger for overflow in vsprintf.

Right, which is why lua_error should have the same arguments
as printf.

Alan
-- 
Dr Alan Watson
Instituto de Astronomía UNAM

Reply | Threaded
Open this post in threaded view
|

Re: two changes I'd like to see in version 3.1

Norman Ramsey-3
In reply to this post by Luiz Henrique de Figueiredo
 > I'm glad to say that this is available in 3.1. It's called luaL_verror.
 > It's not part of the official API because it's a convenience function,
 > written enirely with the API, with no inside information. See lauxlib.c.
 > Just for reference -- or if you're using a previous version, here it is:
 > 
 > void luaL_verror (char *fmt, ...)
 > {
 >   char buff[500];
 >   va_list argp;
 >   va_start(argp, fmt);
 >   vsprintf(buff, fmt, argp);
 >   va_end(argp);
 >   lua_error(buff);
 > }
 > 
 > Unfortunately, until the new ANSI C is out, there is no way to avoid the
 > fixed size buffer and the danger for overflow in vsprintf.

This I have written myself.  It would be more useful to walk the
printf string, find the maximum size of the output, and allocate the
buffer dynamically.  It's not clear to me, however, how to ask Lua for
a dynamic buffer that I intend to write with a string.  Another
alternative would be to use Dave Hanson's Fmt code from
http://www.cs.princeton.edu/software/cii; this is not quite as
powerful as printf but is extensible.

Reply | Threaded
Open this post in threaded view
|

Re: two changes I'd like to see in version 3.1

Steve Dekorte-2
In reply to this post by Luiz Henrique de Figueiredo
>From [hidden email] Tue Jun 23 04:24:33 1998
>
>Speaking of errors, I wish there was a seperate error reporting mechanism
>and api for parse errors. Requiring the debugger to parse the parse error
>makes for a fragile interface.
>
>I'm not sure what you mean here. What API would you suggest for parsing?

Something that gives me the line number and other info in a structured form -
similiar to the info your can get about calls on the Lua stack.
Right now, I have to parse that info out of the error string - and I think the
error string format changed with 3.1 which then broke my error string
parsing mechanism.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: two changes I'd like to see in version 3.1

Roberto Ierusalimschy
In reply to this post by Norman Ramsey-3
> There are two changes I'd like to see in Lua, both of which would make
> it a little easier to connect C code to Lua.
> 
> I try to be careful in my code to use const char * when I know I'm
> dealing with immutable strings.  Unfortunately, many Lua functions use
> parameter types of char *, even when const char * would be correct, so
> I get a slew of warning messages.  It would be nice if the signatures
> were updated properly.  I believe that *all* strings are immutable in
> Lua, so that all instances of char * could be replaced with const
> char*.

In fact, all strings in Lua are immutable, and the addition of "const" 
could make things clearer. But that change is not that easy; we would have 
to change all Lua to use "const", otherwise we sould only change the 
position of the warnings. Besides the work, this has two difficulties: 

- some machines do not have correct "const"s in their header files; when
we use const on those machines we get a lot of warnings when calling strcmp,
strcpy, etc.

- once we changed all Lua to use const. I know this is unbelievable, but in
our machine this change made Lua bigger and slower (we double-checked that)!!
After that we gave up using const.

  For now, you may use some macros to do a "polite" typecast from "const
char *" to "char *" around Lua API.


> The other change I'd like to see is minor: I'd like the C version of
> lua_error to have the same signature as printf.  This should
> relatively easy to implement in ANSI C using <stdarg.h> and vsprintf.

Unfortunately, this is not a minor change. The error method is a Lua 
function, not a C one. When you call lua_error, the error method is called 
through Lua calling conventions, and there is no way in ANSI C to 
dynamically build the "arg list" from Lua parameters. On the other hand, we 
cannot use Lua's "format" in the default error method, because "format" is 
not part of Lua: It's in a library. 


-- Roberto