Am 17.11.13 00:47, schrieb Alexander Nasonov:
PS Why do you still use a shadow copy of luaconf.h? Please add your
changes to the main luaconf.h. If you guard your kernel changes properly
with _KERNEL, they will not affect userspace.
I totally agree. It was probably just an oversight when I
Am 17.11.13 06:30, schrieb 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,
I agree that bigger is better and %jd is much better then %
PRI/SCN. But don't you think that to know the exact width is even
better?
You can always use sizeof if the need to know the size arises.
sizeof returns the number of bytes used to store an object. This is
only loosely related to
Am 17.11.13 11:18, schrieb Alexander Nasonov:
Lourival Vieira Neto wrote:
I don't think that keeping compatibility with userspace Lua is the
right argument. We already have lost this kind of compatibility by
using an integer type for lua_Number. Expecting that kernel lua_Number
works just
Mouse wrote:
Also, using an exact-width type assumes that the hardware/compiler in
question _has_ such a type.
It's possible that lua, NetBSD, or the combination of the two is
willing to write off portability to machines where one or both of those
potential portability issues becomes
On Sun, Nov 17, 2013 at 11:30 AM, Alexander Nasonov al...@yandex.ru wrote:
Mouse wrote:
Also, using an exact-width type assumes that the hardware/compiler in
question _has_ such a type.
It's possible that lua, NetBSD, or the combination of the two is
willing to write off portability to
On Sun, 17 Nov 2013, Mouse wrote:
sizeof returns the number of bytes used to store an object.
This is only loosely related to the number of data bits in the
object; the latter is no more than sizeof the object times
CHAR_BIT, but it may be lower.
Also, using an exact-width type assumes that
] 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 number type to int64_t is certainly a good idea. Two
| questions, however:
|
| Why
On Sun, Nov 17, 2013 at 7:37 AM, Marc Balmer m...@msys.ch wrote:
Am 17.11.13 04:49, schrieb 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.
I don't see this as very important. Lua scripts will
On Sun, Nov 17, 2013 at 8:52 AM, Alexander Nasonov al...@yandex.ru wrote:
Marc Balmer wrote:
The basic issue here is that Lua has only _one_ numerical data type,
which is an integral type in kernel, but a floating point type in userspace.
Right, not everyone here knows this I guess. Thanks
On Sun, Nov 17, 2013 at 9:30 AM, Alexander Nasonov al...@yandex.ru wrote:
Mouse wrote:
Also, using an exact-width type assumes that the hardware/compiler in
question _has_ such a type.
It's possible that lua, NetBSD, or the combination of the two is
willing to write off portability to
On Sun, Nov 17, 2013 at 12:58 PM, Christos Zoulas chris...@zoulas.com wrote:
On Nov 17, 1:36am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| Bigger is better. And you can use %jd to print which is a big win.
|
| I agree
On Nov 17, 10:36am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| I mean know it as a script programmer. I think that would be helpful
| to know the exact lua_Number width when you are writing a script.
| AFAIK, you don't have
On Nov 17, 10:46am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| On Sun, Nov 17, 2013 at 7:37 AM, Marc Balmer m...@msys.ch wrote:
| Am 17.11.13 04:49, schrieb Terry Moore:
| I believe that if you want the Lua scripts
On Sun, Nov 17, 2013 at 2:02 PM, Christos Zoulas chris...@zoulas.com wrote:
On Nov 17, 10:46am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| On Sun, Nov 17, 2013 at 7:37 AM, Marc Balmer m...@msys.ch wrote:
| Am 17.11.13 04:49
On Sun, Nov 17, 2013 at 4:52 PM, Lourival Vieira Neto
lourival.n...@gmail.com wrote:
On Sun, Nov 17, 2013 at 2:02 PM, Christos Zoulas chris...@zoulas.com wrote:
On Nov 17, 10:46am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
(Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| On Sun, Nov 17, 2013 at 7:37 AM, Marc Balmer m...@msys.ch wrote:
| Am 17.11.13 04:49, schrieb Terry Moore:
| I believe that if you want the Lua scripts to be portable across NetBSD
| deployments, you should
On Sat, Nov 16, 2013 at 9:25 PM, Lourival Vieira Neto
lourival.n...@gmail.com wrote:
(...) I moved strtoimax.c to common/libc. Don't know if
someone sees a problem on that.
BTW, is it OK? Could someone review this?
Regards,
--
Lourival Vieira Neto
On Nov 17, 3:36pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| 1. Lua 5.3 will have 64 bit integer support as standard, which will
| make interop and reuse between kernel and userspace code much easier,
| iff we use int64_t
On Sun, Nov 17, 2013 at 7:56 PM, Christos Zoulas chris...@zoulas.com wrote:
On Nov 17, 3:36pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| 1. Lua 5.3 will have 64 bit integer support as standard, which will
| make interop
On Sun, Nov 17, 2013 at 6:13 PM, Justin Cormack
jus...@specialbusservice.com wrote:
On Sun, Nov 17, 2013 at 7:56 PM, Christos Zoulas chris...@zoulas.com wrote:
On Nov 17, 3:36pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| 1
On Sun, Nov 17, 2013 at 8:39 PM, Lourival Vieira Neto
lourival.n...@gmail.com wrote:
Well, I don't think I fully understood that; mainly because I'm not
aware about Lua 5.3. It will provide two number types for the scripts?
Or you are just talking about lua_Integer type on the C-side. Lua 5.1
From: Marc Balmer [mailto:m...@msys.ch]
It's not *much* less safe than compiling and executing a string in the
kernel. The only additional attack surfaces are that you can write
things
that the compiler wouldn't write. This can (1) cause a crash at load
time,
or it can (2) cause
On Sun, Nov 17, 2013 at 6:45 PM, Justin Cormack
jus...@specialbusservice.com wrote:
On Sun, Nov 17, 2013 at 8:39 PM, Lourival Vieira Neto
lourival.n...@gmail.com wrote:
Well, I don't think I fully understood that; mainly because I'm not
aware about Lua 5.3. It will provide two number types for
On Nov 17, 7:14pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| Humm.. I think that =A72.1 brings a good argument: Standard Lua uses
| 64-bit integers and double-precision floats, (...). I think that
| would not hurt to stick
Am 17.11.13 22:03, schrieb Terry Moore:
From: Marc Balmer [mailto:m...@msys.ch]
It's not *much* less safe than compiling and executing a string in the
kernel. The only additional attack surfaces are that you can write
things
that the compiler wouldn't write. This can (1) cause a crash at
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
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
Zoulas
Cc: tech-kern@netbsd.org
Subject: Re: [patch] changing lua_Number to int64_t
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
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
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
Hi Folks,
Here are a patch that changes lua_Number from 'long long' to 'int64_t'.
Regards,
--
Lourival Vieira Neto
lua_kernel_int64_t.patch
Description: Binary data
*is
On Sat, Nov 16, 2013 at 12:53 AM, Lourival Vieira Neto
lourival.n...@gmail.com wrote:
Hi Folks,
Here are a patch that changes lua_Number from 'long long' to 'int64_t'.
Regards,
--
Lourival Vieira Neto
--
Lourival Vieira Neto
fixed a little issue.. (s/LUA_NUMBER_SCAN %PRId64/LUA_NUMBER_SCAN
%SCNd64).. sorry about that.. =/
On Sat, Nov 16, 2013 at 12:55 AM, Lourival Vieira Neto
lourival.n...@gmail.com wrote:
*is
On Sat, Nov 16, 2013 at 12:53 AM, Lourival Vieira Neto
lourival.n...@gmail.com wrote:
Hi Folks,
Here
40 matches
Mail list logo
