Re: CVS commit: src/sys
Hi Mindaugas, On Sat, Jul 19, 2014 at 7:16 PM, Mindaugas Rasiukevicius rm...@netbsd.org wrote: Alex, Alexander Nasonov al...@yandex.ru wrote: Lourival Pereira Vieira Neto wrote: Module Name:src Committed By: lneto Date: Sat Jul 19 17:13:22 UTC 2014 Modified Files: src/sys/modules/lua: lua.c src/sys/sys: lua.h Log Message: lua(4): added support for running Lua scripts in intr context Please revert this. You can't make a mechanical change (s/kmem_/kmem_intr_/g and so on) to enable lua in softintr context. You need to design it. What if GC kicks-in in softintr? What if the code tries to load a chunk of new code in softintr? And there are other questions. I have explained to Lourival that softint context is a very constrained environment and he should seek for a better design, e.g. have per-CPU Lua state while keeping such Lua programs mostly stateless and sharing no global state. Ideally, we should have deterministic behaviour and memory pre-allocation with such programs (whether it is Lua or not). This is tricky with Lua, but I think he understands the implications and issues. The change is more of an initial step to (inefficiently) support the capability. Meanwhile, those interested can research and experiment with NPF+Lua. Such use of Lua is not really meant to be production-ready at this point. Yes, I think that I do understand the implications of running Lua in softint context. However, I don't think the best option is to have stateless Lua because we would lose functionality and it wouldn't be enough. For example, we could still have scripts performing infinite loops. We are circumventing this issue limiting the number of instructions executed by the Lua VM. Please also note that it is safe to Lua to fail to allocate memory. Moreover, I really prefer to finish its first use case and evaluate the issues before super-engineering it and stating that it is inefficient. Anyway, I think that we can continue discussing it and improving the design. I just don't think this is the case of reverting (especially, before trying to understand what is being done). Regards, -- Lourival Vieira Neto
Re: CVS commit: src
On Sun, Jul 20, 2014 at 5:14 AM, Alan Barrett a...@cequrux.com wrote: On Sat, 19 Jul 2014, Lourival Vieira Neto wrote: Also, if this doesn't get reverted for being rushed, then please import it on a vendor branch as per the usual practice. Did you mean moving it from -current to a specific branch? No, I mean using cvs import the way we usually do it. I'll explain in more detail in a private message. I get it now. Thanks. Regards, -- Lourival Vieira Neto
Re: CVS commit: src
Hi Christos, On Sun, Jul 20, 2014 at 6:11 PM, Christos Zoulas chris...@astron.com wrote: In article c1e460e2-036b-4604-8226-70e04af1e...@msys.ch, Marc Balmer m...@msys.ch wrote: Am 19.07.2014 um 21:54 schrieb Alexander Nasonov al...@yandex.ru: That's not how we update 3rd-party code in the tree. We use cvs import and resolve conflicts afterwards. Oh well.. Having recent Lua is more important than following a procedure that is difficult to follow. The procedure is not complicated; it is important for everyone to follow otherwise we'll end up with an unmaintainable tree. The lua import needs to be corrected if it was not done on a vendor branch. Without a vendor branch we cannot effectively maintain diffs. The procedure is also documented in the developers guide: google cvs netbsd howto. Alan has already sent me the procedure. I'll create the vendor branch. Sorry for the inconvenience. Regards, -- Lourival Vieira Neto
Re: CVS commit: src
Hi folks, On Sun, Jul 20, 2014 at 9:40 PM, matthew green m...@eterna.com.au wrote: Also, if this doesn't get reverted for being rushed, then please import it on a vendor branch as per the usual practice. Did you mean moving it from -current to a specific branch? No, I mean using cvs import the way we usually do it. I'll explain in more detail in a private message. it's not too late to perform the import so we have the original sources available as well via valid tags and branches. I've done the import. Please let me know if there is something wrong. Regards, -- Lourival Vieira Neto
Re: CVS commit: src/sys/modules/lua
Hi Alexander, On Sat, Jul 19, 2014 at 4:15 PM, Alexander Nasonov al...@yandex.ru wrote: Lourival Pereira Vieira Neto wrote: ... Index: src/sys/modules/lua/stdlib.h diff -u src/sys/modules/lua/stdlib.h:1.1 src/sys/modules/lua/stdlib.h:1.2 --- src/sys/modules/lua/stdlib.h:1.1 Wed Oct 16 19:44:57 2013 +++ src/sys/modules/lua/stdlib.h Sat Jul 19 17:10:02 2014 @@ -1,7 +1,7 @@ /* $NetBSD */ /* - * Copyright (c) 2011, Lourival Neto ln...@netbsd.org. + * Copyright (c) 2011-2014, Lourival Neto ln...@netbsd.org. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -36,11 +36,8 @@ #include sys/param.h #include sys/kmem.h -#ifndef _LUA_INCLUDE_STDLIB -#define _LUA_INCLUDE_STDLIB - -#define realloc(ptr, nsize) kmem_alloc(nsize, KM_SLEEP) -#define free(ptr)kmem_free(ptr, osize) +#ifndef _LUA_INCLUDE_STDLIB_ +#define _LUA_INCLUDE_STDLIB_ #define exit(EXIT_FAILURE) return Infamous hack is still in the tree. You can always provide a better hack. Regards, -- Lourival Vieira Neto
Re: CVS commit: src/sys
Hi Alexander, On Sat, Jul 19, 2014 at 4:39 PM, Alexander Nasonov al...@yandex.ru wrote: Lourival Pereira Vieira Neto wrote: Module Name: src Committed By: lneto Date: Sat Jul 19 17:13:22 UTC 2014 Modified Files: src/sys/modules/lua: lua.c src/sys/sys: lua.h Log Message: lua(4): added support for running Lua scripts in intr context Please revert this. Sure; if other developers want it too, I can revert this. BTW, rmind@ and mbalmer@ have OKed this. You can't make a mechanical change (s/kmem_/kmem_intr_/g and so on) to enable lua in softintr context. You need to design it. IMO, it is not a mechanical change. It is an incremental one. What if GC kicks-in in softintr? It will call kmem_intr_free(9). What if the code tries to load a chunk of new code in softintr? What if? Have you tried that already? And there are other questions. You can formulate these questions and help to improve this work. Regards, -- Lourival Vieira Neto
Re: CVS commit: src
On Sat, Jul 19, 2014 at 4:54 PM, Alexander Nasonov al...@yandex.ru wrote: Lourival Pereira Vieira Neto wrote: Module Name: src Committed By: lneto Date: Sat Jul 19 18:38:35 UTC 2014 Modified Files: src/distrib/sets/lists/base: ad.arm ad.mips ad.powerpc md.amd64 md.sparc64 mi shl.mi src/distrib/sets/lists/debug: ad.arm ad.mips ad.powerpc md.amd64 md.sparc64 shl.mi src/doc: CHANGES RESPONSIBLE src/etc/mtree: NetBSD.dist.base NetBSD.dist.earm NetBSD.dist.mips64eb NetBSD.dist.mips64el NetBSD.dist.powerpc64 NetBSD.dist.sparc64 NetBSD.dist.x86_64 src/external/mit/lua/dist: Makefile README src/external/mit/lua/dist/doc: contents.html lua.1 lua.css luac.1 manual.css manual.html readme.html src/external/mit/lua/dist/src: Makefile lapi.c lapi.h lauxlib.c lauxlib.h lbaselib.c lcode.c lcode.h ldblib.c ldebug.c ldebug.h ldo.c ldo.h ldump.c lfunc.c lfunc.h lgc.c lgc.h linit.c liolib.c llex.c llex.h llimits.h lmathlib.c lmem.c lmem.h loadlib.c lobject.c lobject.h lopcodes.c lopcodes.h loslib.c lparser.c lparser.h lstate.c lstate.h lstring.c lstring.h lstrlib.c ltable.c ltable.h ltablib.c ltm.c ltm.h lua.c lua.h luac.c luaconf.h lualib.h lundump.c lundump.h lvm.c lvm.h lzio.c lzio.h src/external/mit/lua/lib/liblua: Makefile shlib_version src/external/mit/lua/usr.bin/luac: Makefile src/lib/lua/gpio: gpio.c src/lib/lua/sqlite: sqlite.c src/libexec/httpd: lua-bozo.c src/share/examples/lua: gpio.lua sqlite.lua src/share/mk: bsd.lua.mk src/sys/external/bsd/acpica/dist/include/platform: acnetbsd.h src/sys/lib/libkern: Makefile.libkern libkern.h src/sys/modules/lua: Makefile lua.c test.lua src/sys/modules/luapmf: Makefile luapmf.c src/sys/modules/luasystm: Makefile luasystm.c test.lua Added Files: src/common/lib/libc/string: strcspn.c strpbrk.c strspn.c src/external/mit/lua/dist/doc: alert.png osi-certified-72x60.png src/external/mit/lua/dist/src: lbitlib.c lcorolib.c lctype.c lctype.h lua.hpp lutf8lib.c Removed Files: src/external/mit/lua/dist: COPYRIGHT HISTORY INSTALL src/external/mit/lua/dist/doc: cover.png lua.html luac.html src/external/mit/lua/dist/etc: Makefile README all.c lua.hpp lua.ico lua.pc luavs.bat min.c noparser.c strict.lua src/external/mit/lua/dist/src: print.c src/external/mit/lua/dist/test: README bisect.lua cf.lua echo.lua env.lua factorial.lua fib.lua fibfor.lua globals.lua hello.lua life.lua luac.lua printf.lua readonly.lua sieve.lua sort.lua table.lua trace-calls.lua trace-globals.lua xd.lua src/lib/libc/string: strcspn.c strpbrk.c strspn.c src/sys/modules/lua: assert.h ctype.h errno.h inttypes.h limits.h locale.h math.h setjmp.h signal.h stdarg.h stddef.h stdio.h stdlib.h string.h Log Message: lua: updated from 5.1 to 5.3 work3 That's not how we update 3rd-party code in the tree. We use cvs import and resolve conflicts afterwards. Are there some guide or policy available? Regards, -- Lourival Vieira Neto
Re: CVS commit: src
Hi Alan, On Sat, Jul 19, 2014 at 5:43 PM, Alan Barrett a...@cequrux.com wrote: On Sat, 19 Jul 2014, Lourival Pereira Vieira Neto wrote: lua: updated from 5.1 to 5.3 work3 Is this a well-planned and well-tested update, or does it feel rushed to get it done before the netbsd-7 branch? I think this was as planned and as tested as Lua 5.1 import. However, maybe, I'm missing something. I don't see any recent discussion in public mailing lists. It was discussed on tech-kern [1] and also on icb/irc. [1] http://mail-index.netbsd.org/tech-kern/2014/07/12/msg017341.html Also, if this doesn't get reverted for being rushed, then please import it on a vendor branch as per the usual practice. Did you mean moving it from -current to a specific branch? Regards, -- Lourival Vieira Neto
Re: CVS commit: src/sys
On Sat, Jul 19, 2014 at 5:45 PM, Alexander Nasonov al...@yandex.ru wrote: Lourival Vieira Neto wrote: Hi Alexander, On Sat, Jul 19, 2014 at 4:39 PM, Alexander Nasonov al...@yandex.ru wrote: ... What if GC kicks-in in softintr? It will call kmem_intr_free(9). How many times? It depends on your script. What if the code tries to load a chunk of new code in softintr? What if? Have you tried that already? Do I have to? See also my point below about documentation. No, you don't. You can formulate these questions and help to improve this work. Please document softintr interface in Lua (and other bits) so that I can write my first module and formulate my questions and report any problems. Sure, at the appropriate time I will. Regards, -- Lourival Vieira Neto
Re: CVS commit: src/sys
On Sat, Jul 19, 2014 at 6:34 PM, Alexander Nasonov al...@yandex.ru wrote: Lourival Vieira Neto wrote: On Sat, Jul 19, 2014 at 5:45 PM, Alexander Nasonov al...@yandex.ru wrote: What if GC kicks-in in softintr? It will call kmem_intr_free(9). How many times? It depends on your script. Ok, let me ask a more general question. Do you mix softintr Lua code and regular Lua kernel code in one Lua state? Yes, I do. If you do, are you aware that GC running in softintr context can collect objects you created outside of softintr context? Yes, I am. Have you thought of that? Yes, I have. Regards, -- Lourival Vieira Neto
Re: CVS commit: src/sys/sys
On Thu, Jul 17, 2014 at 3:14 PM, Marc Balmer m...@msys.ch wrote:
Am 17.07.2014 um 16:55 schrieb Taylor R Campbell riastr...@netbsd.org:
Module Name: src
Committed By: riastradh
Date: Thu Jul 17 14:55:32 UTC 2014
Modified Files:
src/sys/sys: systm.h
Log Message:
Expand null macros to `do {} while (0)', not to nothing.
Not that I object, but out of curiosity, what is this good for, or, why is
this need/a good thing?
Index: src/sys/sys/systm.h
diff -u src/sys/sys/systm.h:1.263 src/sys/sys/systm.h:1.264
--- src/sys/sys/systm.h:1.263 Thu Apr 3 15:22:57 2014
+++ src/sys/sys/systm.h Thu Jul 17 14:55:32 2014
@@ -1,4 +1,4 @@
-/* $NetBSD: systm.h,v 1.263 2014/04/03 15:22:57 christos Exp $ */
+/* $NetBSD: systm.h,v 1.264 2014/07/17 14:55:32 riastradh Exp $*/
/*-
* Copyright (c) 1982, 1988, 1991, 1993
@@ -527,7 +527,7 @@ void assert_sleepable(void);
#if defined(DEBUG)
#define ASSERT_SLEEPABLE() assert_sleepable()
#else /* defined(DEBUG) */
-#define ASSERT_SLEEPABLE() /* nothing */
+#define ASSERT_SLEEPABLE() do {} while (0)
#endif /* defined(DEBUG) */
vaddr_t calc_cache_size(vsize_t , int, int);
Wouldn't be '((void)0)' better?
Regards,
--
Lourival Vieira Neto
Re: CVS commit: src
If the Lua int type was 128 bit uint64_t would convert differently. More correctly even as it would remain unsigned rather than wrapping to signed. This means code will break as the kernel uses uint64_t. How would it break? Are you saying that the following code should break? lua_pushnumber(L, INTMAX_MAX); uint64_t x = (uint64_t) lua_tonumber(L, -1); Regards, -- Lourival Vieira Neto
Re: CVS commit: src
On Wed, Dec 4, 2013 at 6:36 PM, Alexander Nasonov al...@yandex.ru wrote: Lourival Vieira Neto wrote: On Tue, Dec 3, 2013 at 9:26 PM, Alexander Nasonov al...@yandex.ru wrote: Do you have a test to prove that 'return 2^3' doesn't break in the kernel? Yes; you can just load the script you've mentioned. There is no reason to break anything. It is just defined as the multiplication operator. Well, you can certainly do this or tweak something else in the language but you should stop calling your thing Lua. Because it's not Lua anymore. Are you aware that we have already changed the language number type? Thus, we have already changed the language itself? If you insist, we can call that Lua', kernel Lua, or whatever you like. Is there an issue with lua_error? I don't think that lua_error would work because lua_State isn't passed to luai_numpow(a,b). I wanted to say that you need a stub that breaks in a very noticeable way. I really miss your point here. Why lua_State should be passed to luai_numpow()? Anyway, I just checked and lua_error is working fine. What do you mean by working fine? By that I mean lua_error() function is working properly, AFAIK. Are you talking about this change: #define luai_numpow(a,b)lua_error(L, ) ? No. Why I should? I really don't understand why you want to do that. It can't work because luai_numpow is used inside constfolding (defined in lcode.c) where L is undefined. Yes. It wasn't designed to work in that way. Since you can't use lua_error, you may consider this #define luai_numpow(a,b) \ panic(I take this opportunity to say that I need a volunteer to implement luai_numpow in the kernel. ) ;-) But seriously, you can easily implement it. It doesn't even have to be in a Lua core file. You can create a new file in you lua module directory. Yes, we can (how Obama says =). However, I don't see this as a priority. Do you have an example that breaks it? If you want a verbose output, just push your error message (like, lua_pushstring(L, my error)) and call lua_error(L). If kern.lua.verbose is set, you will get my error printed. You guys keep adding sysctls. Why do you need kern.lua.verbose? I assume that all kernel Lua code should have a protected call at top-level. If they don't, you definitely want to see an error printed to the console. I didn't add any sysctl. Anyway, it can be discussed in tech-kern@. Regards, -- Lourival Vieira Neto
Re: CVS commit: src
On Wed, Dec 4, 2013 at 7:53 PM, Alexander Nasonov al...@yandex.ru wrote: Lourival Vieira Neto wrote: Are you aware that we have already changed the language number type? Thus, we have already changed the language itself? If you insist, we can call that Lua', kernel Lua, or whatever you like. It's documented: http://www.lua.org/manual/5.2/manual.html#lua_Number typedef double lua_Number; The type of numbers in Lua. By default, it is double, but that can be changed in luaconf.h. Through this configuration file you can change Lua to operate with another type for numbers (e.g., float or long). Yes, and so do the arithmetic operations. And yes it does change the language itself. Lua language ~= Lua interpreter. But seriously, you can easily implement it. It doesn't even have to be in a Lua core file. You can create a new file in you lua module directory. Yes, we can (how Obama says =). However, I don't see this as a priority. When I see something like this at work, I may set a reminder to follow-up after 6 months. I don't think mutt has this feature. Should I submit a PR instead? Really don't know how you should proceed. As you are also a dev, you could just implement this if you really miss exponentiation in kernel Lua. Regards, -- Lourival Vieira Neto
Re: CVS commit: src
Hi Martin, On Tue, Dec 3, 2013 at 6:26 AM, Martin Husemann mar...@duskware.de wrote: On Mon, Dec 02, 2013 at 10:33:05PM -0200, Lourival Vieira Neto wrote: I also have no problem to step back and use 'long long', if _we_ choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long long' is a good argument for that. I do prefer explicit width type, but my main argument is that 'long long' width could be lesser than 64 bit. Using long long is as arbitrary as using int64_t. I don't think so. If int64_t is defined, its width is 64 bit. The only reasonable other choice would be intmax_t (and I'm suprised Lua did not pick that). Maybe we should move to intmax_t. My argument to use int64_t instead of intmax_t was the Lua 5.3 manual (which states that integers have 64 bit width). However, the implementation uses 'long long' by default. I see no reason to do not use intmax_t anymore (even preferring fixed width, intmax_t looks like a better option). However, none of these make a difference with any of the currently supported architectures, so this argument is of cosmetic nature. I agree. However, I think we should choose the more coherent type, even that these types are the same in practice. Regards, -- Lourival Vieira Neto
Re: CVS commit: src
Hi Valery, On Tue, Dec 3, 2013 at 11:58 AM, Valery Ushakov u...@stderr.spb.ru wrote: On Tue, Dec 03, 2013 at 11:45:15 -0200, Lourival Vieira Neto wrote: Also, moving to intmax_t, would help in string library. It needs a length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no length modifier defined for int64_t. Using intmax_t we could just use j. There is: PRId64 c. I think PRI/SCNd64 are conversion specifiers. In practice, I think they will always expand to the same thing. But the standard differentiates these two kind of specifiers. Doesn't it? Regards, -- Lourival Vieira Neto
Re: CVS commit: src
Hi Justin, On Tue, Dec 3, 2013 at 8:04 PM, Justin Cormack jus...@specialbusservice.com wrote: On 3 Dec 2013 16:02, Christos Zoulas chris...@zoulas.com wrote: On Dec 3, 11:45am, ln...@netbsd.org (Lourival Vieira Neto) wrote: -- Subject: Re: CVS commit: src | Also, moving to intmax_t, would help in string library. It needs a | length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no | length modifier defined for int64_t. Using intmax_t we could just use | j. Yes, the other good side effect of intmax_t is that this is the best the machine can do in terms of integer range. No that is a bad side effect. It must always be 64 bits. In the kernel you have to deal with uint64_t which will behave differently if intmax_t is ever bigger than 64 bits, so code will break. So either use int64_t or what Lua uses and assert that that is 64 bits. What side effect? Why it must always be 64 bit? Also, I don't get the unsigned problem. What it will break? Moreover, if we don't have a 64-bit int type, what we should do? Disable Lua? Regards, -- Lourival Vieira Neto
Re: CVS commit: src
On Tue, Dec 3, 2013 at 8:15 PM, Lourival Vieira Neto ln...@netbsd.org wrote: Hi Justin, On Tue, Dec 3, 2013 at 8:04 PM, Justin Cormack jus...@specialbusservice.com wrote: On 3 Dec 2013 16:02, Christos Zoulas chris...@zoulas.com wrote: On Dec 3, 11:45am, ln...@netbsd.org (Lourival Vieira Neto) wrote: -- Subject: Re: CVS commit: src | Also, moving to intmax_t, would help in string library. It needs a | length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no | length modifier defined for int64_t. Using intmax_t we could just use | j. Yes, the other good side effect of intmax_t is that this is the best the machine can do in terms of integer range. No that is a bad side effect. It must always be 64 bits. In the kernel you have to deal with uint64_t which will behave differently if intmax_t is ever bigger than 64 bits, so code will break. So either use int64_t or what Lua uses and assert that that is 64 bits. What side effect? Why it must always be 64 bit? Also, I don't get the unsigned problem. What it will break? Moreover, if we don't have a 64-bit int type, what we should do? Disable Lua? just got the 'side effect' part.. =) -- Lourival Vieira Neto
Re: CVS commit: src
On Tue, Dec 3, 2013 at 9:26 PM, Alexander Nasonov al...@yandex.ru wrote: Lourival Vieira Neto wrote: I wasn't in that thread at that time. However, I'll carefully read it. If you haven't done so yet, it's a good idea to subscribe to source-changes-d@. Yes, I subscribed already =). I just hadn't at that time. Anyway, I think that the missing implementation of luai_numpow() doesn't break anything. Do you have a test to prove that 'return 2^3' doesn't break in the kernel? Yes; you can just load the script you've mentioned. There is no reason to break anything. It is just defined as the multiplication operator. Is there an issue with lua_error? I don't think that lua_error would work because lua_State isn't passed to luai_numpow(a,b). I wanted to say that you need a stub that breaks in a very noticeable way. I really miss your point here. Why lua_State should be passed to luai_numpow()? Anyway, I just checked and lua_error is working fine. Do you have an example that breaks it? If you want a verbose output, just push your error message (like, lua_pushstring(L, my error)) and call lua_error(L). If kern.lua.verbose is set, you will get my error printed. I don't think I've created a problem to myself. We discussed it on the list and _we_ come to a conclusion. Note, I don't think that this overflow is a huge problem. The worst that could happen is to have a truncation of a greater number instead of 0. Anyway, I think it must be fixed and that any of the two presented solutions is fine. However, I also have no problem to step back and use 'long long', if _we_ choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long long' is a good argument for that. I do prefer explicit width type, but my main argument is that 'long long' width could be lesser than 64 bit. Lua is external software and we should keep our copy close to the original. If this sense long long is the best choice. However, Lua 5.3 isn't released yet and Lua team may change their minds. They will have to go through similar problem with strtoll replacement, though. I agree, we should keep the implementation close to the original. However, the whole point about luaconf.h is to adapt Lua without changing its implementation. IMO, we should choose the best LUA_NUMBER type for us. In this case, I think it is intmax_t (as already stated by Christos), if we won't use a fixed width type. Regards, -- Lourival Vieira Neto
Re: CVS commit: src
Hi Alan, Log Message: changed lua_Number to int64_t This was actually two logical changes: * move strtoimax from the userland-only part of libc to the common part that's also usable by the kernel. * change lua_Number to int64_t for the kernel Lua implementation. I would have preferred to see two separate commits. Even with only one commit, the log message should have described both changes. Sorry for that. I posted the patch on tech-kern, and I thought that it was OK for single committing. Next time I'll separate it better. Regards, -- Lourival Vieira Neto
Re: CVS commit: src/common/lib/libc/stdlib
Module Name:src Committed By: joerg Date: Mon Dec 2 12:20:44 UTC 2013 Modified Files: src/common/lib/libc/stdlib: strtoimax.c Log Message: Fix aliases. Sorry about that.. my bad! Regards, -- Lourival Vieira Neto
Re: CVS commit: src
Hi Alexander, On Mon, Dec 2, 2013 at 8:38 PM, Alexander Nasonov al...@yandex.ru wrote: Lourival Vieira Neto wrote: Yes, it isn't. But, please note, I didn't change that now. I just merged it in one single file. Though I think we need implement integer exponentiation, I think that is not a priority. IMO, it is a TODO. Well, I assume that any raised issues should be resolved before moving broken stuff around. See the link to my review below. I wasn't in that thread at that time. However, I'll carefully read it. Anyway, I think that the missing implementation of luai_numpow() doesn't break anything. Yes, of course, a*b != pow(a,b); but, it was left in that way just for convenience. I don't see this as a main issue anyhow. If you wanted to keep this item in TODO list, you'd better picked lua_error rather than lua_mul ;-) Is there an issue with lua_error? Anyway, having two different luaconf.h was a real issue. I have problems including the wrong header with a little more complex Lua kmods (such as luadata). In fact, all Lua kmods were including the wrong luaconf.h file, because of the order of inclusion (-I's on Makefile). It didn't explode because they weren't using lua_Number, but I had a real hard time trying to debug this on luadata, once that compiling a kmod that uses a double type isn't raising an error on amd64 (don't know why). 2. If intmax_t is a greater type than int64_t, the below doesn't handle overflow: #define lua_str2number(s,p)((int64_t) strtoimax((s), (p), 10)) I'm considering two approaches: 1) creating an auxiliary function based on strtoimax(): ... 2) creating an auxiliary function based on strtol template I think you created some problems for yourself by using int64_t. I was going to tell you that Lua 5.3 uses long long for 64bit integers but I saw your question on lua-l about it. I didn't mind using long long in the kernel when we discussed that topic but some other people convinced you to use explicit width type ;-) I don't think I've created a problem to myself. We discussed it on the list and _we_ come to a conclusion. Note, I don't think that this overflow is a huge problem. The worst that could happen is to have a truncation of a greater number instead of 0. Anyway, I think it must be fixed and that any of the two presented solutions is fine. However, I also have no problem to step back and use 'long long', if _we_ choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long long' is a good argument for that. I do prefer explicit width type, but my main argument is that 'long long' width could be lesser than 64 bit. Regards, -- Lourival Vieira Neto
