Re: [patch] changing lua_Number to int64_t

2013-11-16 Thread Marc Balmer
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

Re: [patch] changing lua_Number to int64_t

2013-11-16 Thread Christos Zoulas
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

Re: [patch] changing lua_Number to int64_t

2013-11-16 Thread Lourival Vieira Neto
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

Re: [patch] changing lua_Number to int64_t

2013-11-16 Thread Lourival Vieira Neto
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

Re: [patch] changing lua_Number to int64_t

2013-11-16 Thread Alexander Nasonov
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

Re: [patch] changing lua_Number to int64_t

2013-11-16 Thread Christos Zoulas
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

posix_fallocate

2013-11-16 Thread Emmanuel Dreyfus
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

Re: RLIMIT_FSIZE and SIGXFSZ

2013-11-16 Thread Mouse
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

Re: posix_fallocate

2013-11-16 Thread Christos Zoulas
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

Re: [patch] changing lua_Number to int64_t

2013-11-16 Thread Lourival Vieira Neto
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

Re: [patch] changing lua_Number to int64_t

2013-11-16 Thread Lourival Vieira Neto
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

RE: [patch] changing lua_Number to int64_t

2013-11-16 Thread Terry Moore
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

RE: [patch] changing lua_Number to int64_t

2013-11-16 Thread Terry Moore
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

Re: posix_fallocate

2013-11-16 Thread Robert Elz
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

Re: [patch] changing lua_Number to int64_t

2013-11-16 Thread Lourival Vieira Neto
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

Re: posix_fallocate

2013-11-16 Thread Mouse
[...] 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()?