tech-kern archive

[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 <> 
> Lourival Vieira Neto wrote:
>> On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas 
>> <> wrote:
>> > In article <>, Marc Balmer  
>> > <> 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

Home | Main Index | Thread Index | Old Index