Re: [ANN] Lua 5.2.0 (rc4) now available

[Patrick Rapin <toupie300@...>]

> All feedback welcome. Thanks.

I tried today to run the Lua test suite on my various Windows builds.
I managed to pass most tests, with some efforts.
The issues were:

0) Set _port and _noposix to true in all.lua. This is normal, because
they are for Linux system.

1) LUA_USE_LONGLONG is not defined on Windows. I think it should be,
with some caution.
Here is what I propose to place at the beginning of luaconf.h:

#if defined(LUA_WIN)
#define LUA_DL_DLL
#define LUA_USE_AFORMAT		/* assume 'printf' handles 'aA' specifiers */
+#define LUA_INTFRMLEN           "I64"
+#define LUA_INTFRM_T            long long
#endif

Or, maybe better (if we want to support MSVC 6.0):
#if defined(LUA_WIN)
#define LUA_DL_DLL
#define LUA_USE_AFORMAT		/* assume 'printf' handles 'aA' specifiers */
#define LUA_INTFRMLEN           "I64"
#ifdef _MSC_VER
#define LUA_INTFRM_T            __int64
#else
#define LUA_INTFRM_T            long long
#endif
#endif

The problem is that recent versions of MSVC support long long and "ll"
suffix to sprintf, but not older ones.
And the Windows system MSVCRT.DLL runtime library, used by MignGW and
WinDDK, does not support "ll", but "I64" works.

2) With the previous patch, assert() fail at the lines 167-169 in
strings.lua. It looks like Microsoft support for 64 bits in sprintf is
limited to *signed* values, so from -2^63 to 2^63-1 (this is not Lua
fault)

3) There is an assert() failure also at lines 178 and 180 of
strings.lua. This is because by default the %a format only outputs 5
digits on Windows. Replacing by "%.13a" or "%.13A" make the test work.

4) The assert at line 73 of big.lua fails when Lua is compiled for 64
bits. This is normal, because it actually *could* allocate the huge
string...

5) The check3 function failed at line 343 of api.lua. This can easily
be explained. The current directory "." cannot be opened on Windows.
As a work around, I tried to replace "." with "prn", the old DOS name
for the parallel printer. That device can be opened but cannot be read
on my machine. However, the error message is different ("Invalid
parameter"). I would suggest to tag that test as unportable, using the
_port flag.

6) io.tmpfile() of line 524 of files.lua failed to open the file on my
Windows 7 machine. This is a known issue: on Windows, tmpfile() always
tries to create the temporary file at the root of the current drive,
where typically, on recent OS, you don't have write access !
There is the same issue with tmpnam(), used in os.tmpname().
I suggest the following patches:

- Somewhere in luaconf.h, define lua_tmpnam like this:

#if defined(_WIN32)
#define LUA_TMPNAMBUFSIZE	_MAX_PATH
#define lua_tmpnam(b,e)	{ \
	char* r = _tempnam(NULL, "lua_"); \
	if(r) { strcpy(b, r); free(r); } \
	e = (r == NULL); }
#endif

This will cause os.tmpname() to return a path in the user's temporary directory.
For io.tmpfile(), this is more tricky. We need to use the previous
macro to obtain a writable path, and then use the _O_TEMPORARY
parameter to _open in order to have a file that automatically deletes
when closed. I have added the following code in liolib.c, before
io_tmpfile :

#ifdef _WIN32
#include <errno.h>
#include <fcntl.h>
#include <io.h>
#include <sys/stat.h>

FILE * tmpfile2 (void)
{
  int fd;
  char buff[LUA_TMPNAMBUFSIZE];
  int err;
  do
  {
	  lua_tmpnam(buff, err);
	  if (err)
		 return NULL;

      fd = _open (buff, _O_BINARY | _O_CREAT | _O_TEMPORARY | _O_EXCL | _O_RDWR,
                  _S_IREAD | _S_IWRITE);
  }
  while (fd < 0 && errno == EEXIST);

  return _fdopen (fd, "w+b");
}
#define tmpfile tmpfile2
#endif

End of tests report.