Changing the number type to int64_t is certainly a good idea. Two
questions, however:
1) Why do you remove the sys/modules/lua/inttypes.g file?
2) In sys/modules/lua/luaconf.h, lua_str2number is still #defined as
stroll(), which assumes long long. Shouldn't that be changed as well to
a
In article 52872b0c.5080...@msys.ch, Marc Balmer m...@msys.ch wrote:
Changing the number type to int64_t is certainly a good idea. Two
questions, however:
Why not intmax_t?
christos
On Sat, Nov 16, 2013 at 6:21 AM, Marc Balmer m...@msys.ch wrote:
Changing the number type to int64_t is certainly a good idea. Two
questions, however:
1) Why do you remove the sys/modules/lua/inttypes.g file?
Because this place holder is no long necessary. I have just replaced
that for
On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas chris...@astron.com wrote:
In article 52872b0c.5080...@msys.ch, Marc Balmer m...@msys.ch wrote:
Changing the number type to int64_t is certainly a good idea. Two
questions, however:
Why not intmax_t?
My only argument is that int64_t has a
Lourival Vieira Neto wrote:
On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas chris...@astron.com wrote:
In article 52872b0c.5080...@msys.ch, Marc Balmer m...@msys.ch wrote:
Changing the number type to int64_t is certainly a good idea. Two
questions, however:
Why not intmax_t?
My only
On Nov 16, 9:30pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas chris...@astron.com wrote:
| In article 52872b0c.5080...@msys.ch, Marc Balmer m...@msys.ch wrote:
| Changing the
Hi
NetBSD-current seems to lack posix_fallocate(2)
http://pubs.opengroup.org/onlinepubs/009695299/functions/posix_fallocate
.html
Is someone already working on it, or has thoughs about how it should be
implemented?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
It seems to me it would be more useful to do something like what
RLIMIT_CPU does, and generate SIGXFSZ for such operations, but fail
them only when the size exceeds the hard limit. [...]
Comments or other thoughts?
I don't think it is used too much so the behavior change should not
be a
In article 1lcgiu4.18zr2h51aac07zm%m...@netbsd.org,
Emmanuel Dreyfus m...@netbsd.org wrote:
Hi
NetBSD-current seems to lack posix_fallocate(2)
http://pubs.opengroup.org/onlinepubs/009695299/functions/posix_fallocate
.html
Is someone already working on it, or has thoughs about how it should be
On Sat, Nov 16, 2013 at 9:47 PM, Alexander Nasonov al...@yandex.ru wrote:
Lourival Vieira Neto wrote:
On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas chris...@astron.com wrote:
In article 52872b0c.5080...@msys.ch, Marc Balmer m...@msys.ch wrote:
Changing the number type to int64_t is
On Sat, Nov 16, 2013 at 10:44 PM, Christos Zoulas chris...@zoulas.com wrote:
On Nov 16, 9:30pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas chris...@astron.com
wrote:
| In
I believe that if you want the Lua scripts to be portable across NetBSD
deployments, you should choose a well-known fixed width.
Watch out, by the way, for compiled scripts; I have not checked Lua 5.x, but
you may find if not careful that the compiled binary is not loadable on
machines with
From: Lourival Vieira Neto [mailto:lourival.n...@gmail.com]
Watch out, by the way, for compiled scripts; I have not checked Lua 5.x,
but
you may find if not careful that the compiled binary is not loadable on
machines with different choices for LP64, ILP32, etc. This is somewhat
Date:Sun, 17 Nov 2013 03:18:56 + (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID: l69cj0$f0v$1...@ger.gmane.org
| In article 1lcgiu4.18zr2h51aac07zm%m...@netbsd.org,
| Emmanuel Dreyfus m...@netbsd.org wrote:
| NetBSD-current seems to lack
On Sun, Nov 17, 2013 at 3:30 AM, Terry Moore t...@mcci.com wrote:
From: Lourival Vieira Neto [mailto:lourival.n...@gmail.com]
Watch out, by the way, for compiled scripts; I have not checked Lua 5.x,
but
you may find if not careful that the compiled binary is not loadable on
machines with
[...] this opens a trivial DoS attack like
for (;;) {
ftruncate(fd);
posix_fallocate(fd, (off_t)0, huge);
}
How, exactly, is this any more of a DoS than doing the same thing but
using one or more write() calls instead of the posix_fallocate()?
16 matches
Mail list logo