[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [patch] changing lua_Number to int64_t
On Sat, Nov 16, 2013 at 9:47 PM, Alexander Nasonov <alnsn%yandex.ru@localhost>
> Lourival Vieira Neto wrote:
>> On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas
>> <christos%astron.com@localhost> wrote:
>> > In article <52872B0C.5080309%msys.ch@localhost>, Marc Balmer
>> > <marc%msys.ch@localhost> 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 well-defined width and, AFAIK,
>> intmax_t could vary. But I have no strong feelings about this. Do you
>> think intmax_t would be better?
> int64_t should be enough to cover a range of exactly representable
> integers in userspace Lua program where lua_Number is double.
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 like userspace lua_Numbers could lead to misunderstandings.
> I don't see a need for bigger type unless mainstream Lua switches to
> long double. I don't expect it to happen any time soon.
Why it should bother if Lua switches to a bigger floating-point type?
> PS Why do you still use a shadow copy of luaconf.h? Please add your
> changes to the main luaconf.h.
Only because it is the way that it was committed. I didn't take time
yet to unify that. But you are right, I'll try to do that in the
> If you guard your kernel changes properly
> with _KERNEL, they will not affect userspace.
Yes, I know. I think the guards are just fine.
> PPS "%"PRId64 may break in C++11, space between the literals should fix it.
I don't think that are plans to change kernel language to C++ ;-),
however doesn't hurt to write it in "clean" C.
Just for curiosity.. do you know why it is not allowed in C++11?
Lourival Vieira Neto
Main Index |
Thread Index |