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
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 like userspace lua_Numbers could lead to misunderstandings.
Portability with userspace will arise as soon as you decide to import
some Lua library to kernel space. If kernel number type is wide enough
to represent all exactly representable integers from userspace, you have
less worries.
Also, some libraries work in both spaces. Lua binding for proplib(3) is
a good example.
> > 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?
See above. If they switch to long double, they will extend integer
arithmetic range.
> > 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?
I'm not sure why. It may be related to user-defined literals:
http://akrzemi1.wordpress.com/2012/08/12/user-defined-literals-part-i/
Alex
Home |
Main Index |
Thread Index |
Old Index