[ANN] Lua 5.3.6 (rc1) now available

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

[ANN] Lua 5.3.6 (rc1) now available

Luiz Henrique de Figueiredo
Lua 5.3.6 (rc1) is now available at
        http://www.lua.org/work/lua-5.3.6-rc1.tar.gz

The checksums are
        MD5 e14be0c3cd4be4bb0996f8959bd391df  -
        SHA1 194575efd2ce25dfb8637f4423bba4ef5e53e64f  -

Lua 5.3.6 fixes all bugs listed in http://www.lua.org/bugs.html#5.3.5 .

Like all minor releases, this is strictly a bug-fix release: no new
features or improvements have been added.

This is probably the last release of Lua 5.3. Now is the time to
report glitches and to try to fix any remaining bugs.

The complete diffs from  are available at
        http://www.lua.org/work/diffs-lua-5.3.5-lua-5.3.6.html
        http://www.lua.org/work/diffu-lua-5.3.5-lua-5.3.6.html

We thank everyone for their feedback on Lua 5.3 till now.

All feedback welcome. Thanks.
--lhf
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Viacheslav Usov
On Tue, Jul 14, 2020 at 4:49 PM Luiz Henrique de Figueiredo
<[hidden email]> wrote:

> Lua 5.3.6 fixes all bugs listed in http://www.lua.org/bugs.html#5.3.5 .

I reported a bug in io.popen() a week ago. It is not listed and
apparently not fixed in RC1. Are there plans to fix it?

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Roberto Ierusalimschy
> I reported a bug in io.popen() a week ago. It is not listed and
> apparently not fixed in RC1. Are there plans to fix it?

Thanks for the reminder. Do you know what are the valid modes for
MSVS? The documentation in [1] does not seem to be correct. (I would
deduce that mode must match "[rw][bt]?", but the page says it matches
"[rwbt]".)

[1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/popen-wpopen?view=vs-2019

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Viacheslav Usov
On Tue, Jul 14, 2020 at 7:51 PM Roberto Ierusalimschy
<[hidden email]> wrote:

> Do you know what are the valid modes for MSVS?

We have deduced that the mode parameter is a one or two letter string,
with the first letter 'r' or 'w', and the second, if present, 'b' or
't'. The latter chooses the binary or text mode, respectively. In a
single-letter mode string, the binary/text decision seems to be
controlled by a global variable or another API function.

In our private patch, we have decided to stick with Lua's
specification of io.popen(), which only supports "r" and "w", and make
it always select the binary mode. So our patch translates "r" and "w"
into "rb" and "wb", respectively, and raises a Lua error for other
inputs.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Andrew Gierth
>>>>> "Viacheslav" == Viacheslav Usov <[hidden email]> writes:

 Viacheslav> In our private patch, we have decided to stick with Lua's
 Viacheslav> specification of io.popen(), which only supports "r" and
 Viacheslav> "w", and make it always select the binary mode.

Wouldn't binary mode be almost always the wrong choice, though?

--
Andrew.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Robert Burke
> Wouldn't binary mode be almost always the wrong choice, though?

"Text mode" means "you won't actually get the bytes in the file when
you read, and you won't actually write the bytes you tried to write to
the file when you write." So probably not?
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Viacheslav Usov
In reply to this post by Andrew Gierth
On Wed, Jul 15, 2020 at 11:25 AM Andrew Gierth
<[hidden email]> wrote:

> Wouldn't binary mode be almost always the wrong choice, though?

We are talking about Lua's "standard library" io.popen(), whose
official documentation says nothing about binary or text modes. The
documentation only mentions "r" and "w" as possible modes. So the
first choice is whether you want your users to refer just to the Lua
docs, or look elsewhere. It is a fairly straight-forward choice in my
opinion. Once you decide to go with the Lua docs, there is no way (for
the user) to choose a text/binary sub-mode. Then the choice (for you)
is whether the use of "r" or "w" yields consistent results across
invocations - i.e., whether it is always binary or always text, or
sometimes binary and sometimes text. I find this pretty
straight-forward to answer, too. Then your choice is between always
binary and always text. Always text means that there is always a lossy
transformation acting on the pipe, which, again, makes the choice
straight-forward.

So, unless we see in the Lua docs on io.popen() a way to specify
binary or text modes, I'd say "binary" is the only really sensible
option.

On a slightly different tangent, popen() originally is a POSIX API. In
POSIX, there are no "binary" or "text" stream modes; or, rather, every
stream - and pipe - is a "binary" mode. They explicitly say that "b"
in fopen() has no effect. So it is hard to see how "binary" would be
"almost always wrong", when there might just be nothing else.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Andrew Gierth
In reply to this post by Luiz Henrique de Figueiredo
>>>>> "Luiz" == Luiz Henrique de Figueiredo <[hidden email]> writes:

 Luiz> Lua 5.3.6 fixes all bugs listed in http://www.lua.org/bugs.html#5.3.5 .

Has it been checked whether the 5.4 bug regarding shrinking a just-grown
stack also exists in 5.3, because my superficial reading of the code
suggests that it does?

--
Andrew.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Stefan Ginsberg-2
In reply to this post by Luiz Henrique de Figueiredo
I am wondering about the unreported issue of lua_rawlen returning size_t while
luaH_getn used by it returns lua_Unsigned (this is also the only warning when
compiling with /W3). This was fixed in 5.4.0 but will it be so for 5.3.X?

On Tue, Jul 14, 2020 at 4:49 PM Luiz Henrique de Figueiredo <[hidden email]> wrote:
Lua 5.3.6 (rc1) is now available at
        http://www.lua.org/work/lua-5.3.6-rc1.tar.gz

The checksums are
        MD5     e14be0c3cd4be4bb0996f8959bd391df  -
        SHA1    194575efd2ce25dfb8637f4423bba4ef5e53e64f  -

Lua 5.3.6 fixes all bugs listed in http://www.lua.org/bugs.html#5.3.5 .

Like all minor releases, this is strictly a bug-fix release: no new
features or improvements have been added.

This is probably the last release of Lua 5.3. Now is the time to
report glitches and to try to fix any remaining bugs.

The complete diffs from  are available at
        http://www.lua.org/work/diffs-lua-5.3.5-lua-5.3.6.html
        http://www.lua.org/work/diffu-lua-5.3.5-lua-5.3.6.html

We thank everyone for their feedback on Lua 5.3 till now.

All feedback welcome. Thanks.
--lhf
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Roberto Ierusalimschy
In reply to this post by Andrew Gierth
> >>>>> "Luiz" == Luiz Henrique de Figueiredo <[hidden email]> writes:
>
>  Luiz> Lua 5.3.6 fixes all bugs listed in http://www.lua.org/bugs.html#5.3.5 .
>
> Has it been checked whether the 5.4 bug regarding shrinking a just-grown
> stack also exists in 5.3, because my superficial reading of the code
> suggests that it does?

I guess you are talking about this macro:

    #define checkstackp(L,n,p)  \
      luaD_checkstackaux(L, n, \
        ptrdiff_t t__ = savestack(L, p);  /* save 'p' */ \
        luaC_checkGC(L),  /* stack grow uses memory */ \
        p = restorestack(L, t__))  /* 'pos' part: restore 'p' */

What separates the macro arguments is the comma, not the semicolon.
So, the call to luaC_checkGC is done before the stack reallocation.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Andrew Gierth
>>>>> "Roberto" == Roberto Ierusalimschy <[hidden email]> writes:

 >> Has it been checked whether the 5.4 bug regarding shrinking a
 >> just-grown stack also exists in 5.3, because my superficial reading
 >> of the code suggests that it does?

 Roberto> I guess you are talking about this macro:

 Roberto>     #define checkstackp(L,n,p)  \
 Roberto>       luaD_checkstackaux(L, n, \
 Roberto>         ptrdiff_t t__ = savestack(L, p);  /* save 'p' */ \
 Roberto>         luaC_checkGC(L),  /* stack grow uses memory */ \
 Roberto>         p = restorestack(L, t__))  /* 'pos' part: restore 'p' */

 Roberto> What separates the macro arguments is the comma, not the
 Roberto> semicolon. So, the call to luaC_checkGC is done before the
 Roberto> stack reallocation.

Aha. Yes, that explains it.

--
Andrew.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Roberto Ierusalimschy
>  Roberto> I guess you are talking about this macro:
>
>  Roberto>     #define checkstackp(L,n,p)  \
>  Roberto>       luaD_checkstackaux(L, n, \
>  Roberto>         ptrdiff_t t__ = savestack(L, p);  /* save 'p' */ \
>  Roberto>         luaC_checkGC(L),  /* stack grow uses memory */ \
>  Roberto>         p = restorestack(L, t__))  /* 'pos' part: restore 'p' */
>
>  Roberto> What separates the macro arguments is the comma, not the
>  Roberto> semicolon. So, the call to luaC_checkGC is done before the
>  Roberto> stack reallocation.
>
> Aha. Yes, that explains it.

We cannot put the 'pre' code inside braces because of the scope of 't__'.

I think that's what got me when I wrote the macro checkstackGC :-)

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Roberto Ierusalimschy
In reply to this post by Stefan Ginsberg-2
> I am wondering about the unreported issue of lua_rawlen returning size_t
> while
> luaH_getn used by it returns lua_Unsigned (this is also the only warning
> when
> compiling with /W3). This was fixed in 5.4.0 but will it be so for 5.3.X?

Could you share with us what is this unreported issue? What is exactly
the bug?

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.6 (rc1) now available

Andrew Gierth
>>>>> "Roberto" == Roberto Ierusalimschy <[hidden email]> writes:

 >> I am wondering about the unreported issue of lua_rawlen returning
 >> size_t while luaH_getn used by it returns lua_Unsigned (this is also
 >> the only warning when compiling with /W3). This was fixed in 5.4.0
 >> but will it be so for 5.3.X?

 Roberto> Could you share with us what is this unreported issue? What is
 Roberto> exactly the bug?

I guess it's the fact that size_t might (e.g. on 32-bit systems) be a
smaller type than lua_Unsigned, so the compiler might warn about the
truncation. But the value can't overflow a size_t, so there's no real
issue here other than the compiler warning.

In 5.4 lua_rawlen seems to return lua_Unsigned rather than size_t.
Obviously that can't be changed in 5.3.x.

--
Andrew.