> 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  does not seem to be correct. (I would
deduce that mode must match "[rw][bt]?", but the page says it matches
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
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
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
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.
> >>>>> "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?
> 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 :-)
> I am wondering about the unreported issue of lua_rawlen returning size_t
> luaH_getn used by it returns lua_Unsigned (this is also the only warning
> 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
>> 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.