Re: Problem with string.format in lua 5.0 & 5.1

["Todor Totev" <umbra.tenebris@...>]

Hello all,
to continue my previous post,
in str_format_helper(lua 5.0.2) the code
case 'c':  case 'd':  case 'i': {
  sprintf(buff, form, luaL_checkint(L, arg));
uses checkint macro, which typecast to int which is bad for me - I loose
the most significant 32 bits.

Hope this helps,
Todor


On Wed, 14 Dec 2005 15:15:28 +0200, Todor Totev <umbra.tenebris@list.ru>  
wrote:

> Hello all,
> I found a problem with string.format function which exists in both 5.0 &  
> 5.1.
> I'm building Lua using 64-bit integers as lua_Number. My platform is  
> Win32 with
> Microsoft VisualStudio 2003 (VisualC v13.10)
>
> The problem is that str_format_helper(in 5.0) and scan_format(in 5.1)
> firmly believe that lua_Number is double.
> The first problem is that when they encounter %x and %d they generate
> %x or %d in 'form' argument as format specifiers for sprintf.
> In my case these must be converted to %I64x or %I64d.
>
> Second problem is that str_format function
> typecasts lua_Numbers impropertly:
> when integer number representation is requested, the upper 32 bits are  
> lost:
>
>    case 'o':  case 'u':  case 'x':  case 'X': {
>      sprintf(buff, form, (unsigned int)(luaL_checknumber(L, arg)));
>
> Note the (unsigned int) typecast. In my case ommiting the typecast will  
> fix the problem.
> Also, when the user request floating point representation, the code does  
> NOT have a typecast:
>
>    case 'e':  case 'E': case 'f':
>    case 'g': case 'G': {
>      sprintf(buff, form, luaL_checknumber(L, arg));
>
> This also is problem for my setup. As a patch I added a typecast to  
> double.
>
> I'm not experienced with programming portable C code so I cannot suggest  
> a proper patch.
> For first problem I think it is best to generate LUA_NUMBER_FMT in  
> 'form' argument of
> str_format_helper/scan_format.
> But I cannot suggest a nice solution to the casting issue.
>
> Best regards,
> Todor Totev