* Weekly reports - B @ 2011-06-09 20:20 Luka Marčetić 2011-06-12 23:13 ` Rich Felker ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Luka Marčetić @ 2011-06-09 20:20 UTC (permalink / raw) To: musl Anyway, here's something... *hangs head* https://github.com/paxcoder/cluts ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Weekly reports - B 2011-06-09 20:20 Weekly reports - B Luka Marčetić @ 2011-06-12 23:13 ` Rich Felker 2011-06-13 2:11 ` Solar Designer 2011-07-09 6:41 ` cluts repository (was: Weekly reports - B) Solar Designer 2 siblings, 0 replies; 20+ messages in thread From: Rich Felker @ 2011-06-12 23:13 UTC (permalink / raw) To: musl On Thu, Jun 09, 2011 at 10:20:45PM +0200, Luka Marčetić wrote: > Anyway, here's something... *hangs head* > https://github.com/paxcoder/cluts Is there a reason you're installing and uninstalling the SIGABRT handler on each free? I suspect that's taking a LOT of time, slowing down free by a factor of ~3x for large mmapped chunks and ~200x for small chunks. By the way, please don't feel like you need to do everything on your own writing cluts. You're welcome to discuss ideas, troubles you run into, get advice and code review, etc. both on the mailing list here and on irc. Best wishes, Rich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Weekly reports - B 2011-06-09 20:20 Weekly reports - B Luka Marčetić 2011-06-12 23:13 ` Rich Felker @ 2011-06-13 2:11 ` Solar Designer 2011-06-13 2:22 ` Rich Felker 2011-06-13 2:22 ` specification of cluts tests - code or/and data? (was: Weekly reports - B) Solar Designer 2011-07-09 6:41 ` cluts repository (was: Weekly reports - B) Solar Designer 2 siblings, 2 replies; 20+ messages in thread From: Solar Designer @ 2011-06-13 2:11 UTC (permalink / raw) To: musl Luka, Rich - On Thu, Jun 09, 2011 at 10:20:45PM +0200, Luka Mar??eti?? wrote: > Anyway, here's something... *hangs head* > https://github.com/paxcoder/cluts Thanks for posting this. I took a look. This is good for the start, but we obviously need a lot more. ;-) Sorry to remind you, but we need Luka's code placed under an Open Source license - and not only when cluts is "finished". Each week's update must be properly licensed. Can one or both of you please propose a license you're comfortable with? Some assorted comments on the code, in arbitrary order: For jumping out of a signal handler, you need to use sigjmp_buf, sigsetjmp(), and siglongjmp(). Even so, some failed libc functions might leave stdio (or something else) in an inconsistent state. This is probably irrelevant to simple string functions testing, but it will be relevant to some other tests. Thus, since we don't expect SIGSEGVs to be frequent, maybe it'd be better to switch to forking child processes (which must print something specific to fd 1 to indicate success)? Or we can use both approaches - in different cases, as appropriate. When you declare identifiers at the global scope in a file, but don't need them exported to other source files, please make them "static" to prevent inadvertent use from another source file. What do you mean by "#define _XOPEN_SOURCE 9001"? I think the highest value currently defined is 700, and going too high may actually prevent this from working (e.g., on Solaris). Please avoid assignments to errno. Use your own variable instead. Overall, I think the code could be made prettier. I'll post an idea (which you don't have to use, but you may) in another message. Luka - when I say that something could be written better, etc., please don't be discouraged. On the contrary, this indicates that you're doing something interesting, comment-worthy. :-) I am merely trying to provide constructive criticism and help the project in this way. Thanks again, Alexander ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Weekly reports - B 2011-06-13 2:11 ` Solar Designer @ 2011-06-13 2:22 ` Rich Felker 2011-06-13 2:56 ` Solar Designer 2011-06-26 21:05 ` Weekly reports - X Luka Marčetić 2011-06-13 2:22 ` specification of cluts tests - code or/and data? (was: Weekly reports - B) Solar Designer 1 sibling, 2 replies; 20+ messages in thread From: Rich Felker @ 2011-06-13 2:22 UTC (permalink / raw) To: musl On Mon, Jun 13, 2011 at 06:11:30AM +0400, Solar Designer wrote: > Luka, Rich - > > On Thu, Jun 09, 2011 at 10:20:45PM +0200, Luka Mar??eti?? wrote: > > Anyway, here's something... *hangs head* > > https://github.com/paxcoder/cluts > > Thanks for posting this. I took a look. This is good for the start, > but we obviously need a lot more. ;-) Yes. :) > Sorry to remind you, but we need Luka's code placed under an Open Source > license - and not only when cluts is "finished". Each week's update > must be properly licensed. Can one or both of you please propose a > license you're comfortable with? Let's make it (new) BSD. Is that okay? > Some assorted comments on the code, in arbitrary order: > > For jumping out of a signal handler, you need to use sigjmp_buf, > sigsetjmp(), and siglongjmp(). This only matters if you want the signal mask to be restored, which we DO want, but another way to achieve the same thing would be to install the signal handler with SA_NOMASK so the SIGSEGV never gets masked to begin with (another SIGSEGV should not happen inside the signal handler, and if it did while it was blocked, we'd be screwed anyway). BTW another way to restore the signal mask, especially if you want it to be restored to the mask at the time the signal was generated rather than at the time the jump buffer was created, is to use the SA_SIGINFO signal handler form and read the saved sigset_t from the ucontext_t argument and restore it yourself with sigprocmask. :-) > Even so, some failed libc functions > might leave stdio (or something else) in an inconsistent state. This is > probably irrelevant to simple string functions testing, but it will be > relevant to some other tests. Thus, since we don't expect SIGSEGVs to > be frequent, maybe it'd be better to switch to forking child processes > (which must print something specific to fd 1 to indicate success)? > Or we can use both approaches - in different cases, as appropriate. In the case of testing string functions, the test framework setup a very narrow class of "likely causes" for the SIGSEGV, and unless the functions are hopelessly broken, we can assume any SIGSEGV was caused by the condition that was being tested for. Therefore, in this case I don't think we have to worry about corrupt state and such. Note that POSIX does not require string functions to be async-signal-safe, for some odd reason, but as far as I know all real-world implementations including glibc guarantee that they are (I found a discussion of glibc strstr optimization where use of malloc was rejected because it would violate their requirement that they want it to be async-signal-safe). Thus they should not have any internal state that could get corrupted. > When you declare identifiers at the global scope in a file, but don't > need them exported to other source files, please make them "static" to > prevent inadvertent use from another source file. Agreed. > What do you mean by "#define _XOPEN_SOURCE 9001"? I think the highest > value currently defined is 700, and going too high may actually prevent > this from working (e.g., on Solaris). I noticed this too. Also you're defining it after including headers, which has no effect but invoking UB. To use feature test macros they must be defined before any system headers are included. > Please avoid assignments to errno. Use your own variable instead. Is this just a stylistic preference, or do you have a reason it could be problematic? Rich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Weekly reports - B 2011-06-13 2:22 ` Rich Felker @ 2011-06-13 2:56 ` Solar Designer 2011-06-13 4:54 ` Rich Felker 2011-06-26 21:05 ` Weekly reports - X Luka Marčetić 1 sibling, 1 reply; 20+ messages in thread From: Solar Designer @ 2011-06-13 2:56 UTC (permalink / raw) To: musl On Sun, Jun 12, 2011 at 10:22:21PM -0400, Rich Felker wrote: > On Mon, Jun 13, 2011 at 06:11:30AM +0400, Solar Designer wrote: > > Sorry to remind you, but we need Luka's code placed under an Open Source > > license - and not only when cluts is "finished". Each week's update > > must be properly licensed. Can one or both of you please propose a > > license you're comfortable with? > > Let's make it (new) BSD. Is that okay? Sounds fine. Thanks. (I had mentioned my very slightly different preference before. I won't repeat that.) > > Some assorted comments on the code, in arbitrary order: > > > > For jumping out of a signal handler, you need to use sigjmp_buf, > > sigsetjmp(), and siglongjmp(). > > This only matters if you want the signal mask to be restored, which we > DO want, Right, that's what I meant. > but another way to achieve the same thing would be to install > the signal handler with SA_NOMASK so the SIGSEGV never gets masked to > begin with (another SIGSEGV should not happen inside the signal > handler, and if it did while it was blocked, we'd be screwed anyway). > > BTW another way to restore the signal mask, especially if you want it > to be restored to the mask at the time the signal was generated rather > than at the time the jump buffer was created, is to use the SA_SIGINFO > signal handler form and read the saved sigset_t from the ucontext_t > argument and restore it yourself with sigprocmask. :-) Thank you for mentioning these. For cluts, I think it'd be best not to go for them, though - they might make cluts unnecessarily less portable. > > Even so, some failed libc functions > > might leave stdio (or something else) in an inconsistent state. This is > > probably irrelevant to simple string functions testing, but it will be > > relevant to some other tests. Thus, since we don't expect SIGSEGVs to > > be frequent, maybe it'd be better to switch to forking child processes > > (which must print something specific to fd 1 to indicate success)? > > Or we can use both approaches - in different cases, as appropriate. > > In the case of testing string functions, the test framework setup a > very narrow class of "likely causes" for the SIGSEGV, and unless the > functions are hopelessly broken, we can assume any SIGSEGV was caused > by the condition that was being tested for. Therefore, in this case I > don't think we have to worry about corrupt state and such. Right. I primarily wanted to bring the issue up early on, because Luka will need to arrive at an approach to use for cluts tests in general. > Note that > POSIX does not require string functions to be async-signal-safe, for > some odd reason, but as far as I know all real-world implementations > including glibc guarantee that they are (I found a discussion of glibc > strstr optimization where use of malloc was rejected because it would > violate their requirement that they want it to be async-signal-safe). > Thus they should not have any internal state that could get corrupted. That's curious. Thanks for sharing. > > What do you mean by "#define _XOPEN_SOURCE 9001"? I think the highest > > value currently defined is 700, and going too high may actually prevent > > this from working (e.g., on Solaris). > > I noticed this too. Also you're defining it after including headers, > which has no effect but invoking UB. To use feature test macros they > must be defined before any system headers are included. Sure. I overlooked that detail in Luka's source. > > Please avoid assignments to errno. Use your own variable instead. > > Is this just a stylistic preference, or do you have a reason it could > be problematic? Mostly a stylistic preference. errno is defined to have a specific kind of values assigned to it, by libc. Reusing a variable for something different than its original purpose makes the source code more difficult to understand (even if very slightly). As to actual potential issues: IIRC, some ancient versions of glibc didn't allow programs to assign to errno at all, because it was declared as a macro (not a variable). That was broken because there are in fact some cases when you need to zero out errno before making certain libc calls to be able to distinguish their different errors. For example, with strtol(). Also, there are cases when you need to save/restore errno (such as in a signal handler). (Hmm, maybe I recall only part of the story, and there was something enabling those things to work...) Is it guaranteed that errno is preserved across libc calls that complete without error? Maybe not. I don't really know, and I'd prefer not to depend on that. Generally, I think it is appropriate to limit uses of errno to checking it immediately after a failed libc call, to zeroing it right before certain libc calls, and to saving/restoring its value. Oh, there's one more: in portability functions, it is OK to set errno to specific -EXXX values as appropriate to implement whatever function is being replaced. Just an opinion. Alexander ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Weekly reports - B 2011-06-13 2:56 ` Solar Designer @ 2011-06-13 4:54 ` Rich Felker 2011-06-13 6:48 ` Solar Designer 2011-07-06 11:35 ` errno (was: Weekly reports - B) Solar Designer 0 siblings, 2 replies; 20+ messages in thread From: Rich Felker @ 2011-06-13 4:54 UTC (permalink / raw) To: musl On Mon, Jun 13, 2011 at 06:56:55AM +0400, Solar Designer wrote: > > but another way to achieve the same thing would be to install > > the signal handler with SA_NOMASK so the SIGSEGV never gets masked to > > [...] > > Thank you for mentioning these. > > For cluts, I think it'd be best not to go for them, though - they might > make cluts unnecessarily less portable. That's a good point. I seem to recall some systems (including older Linux) having broken SA_NOMASK. > > > Please avoid assignments to errno. Use your own variable instead. > > > > Is this just a stylistic preference, or do you have a reason it could > > be problematic? > > Mostly a stylistic preference. errno is defined to have a specific kind > of values assigned to it, by libc. Reusing a variable for something > different than its original purpose makes the source code more difficult > to understand (even if very slightly). > > As to actual potential issues: > > IIRC, some ancient versions of glibc didn't allow programs to assign to > errno at all, because it was declared as a macro (not a variable). That This sounds like an urban legend. errno is a macro and has been for a long time (ever since threads) on most systems. It's required by the standard to be an lvalue macro. > Is it guaranteed that errno is preserved across libc calls that complete > without error? Maybe not. I don't really know, and I'd prefer not to > depend on that. Unless it's documented that a particular function can't, libc functions can clobber errno all they like, whether or not they return failure. The only thing they can't do is set it to 0, unless they put some other nonzero (hopefully meaningful) value in it before returning. Note that even strerror and perror can clobber errno if they encounter an internal error, so if you want to portably print an error message before acting on the error, you really need to save the value of errno right away. This all makes using errno a little bit messy, but if libc functions were required not to change errno except when reporting an error, pretty much every libc function that uses other libc functions would be full of useless bloat and slowdowns saving and restoring errno values... Rich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Weekly reports - B 2011-06-13 4:54 ` Rich Felker @ 2011-06-13 6:48 ` Solar Designer 2011-07-06 11:35 ` errno (was: Weekly reports - B) Solar Designer 1 sibling, 0 replies; 20+ messages in thread From: Solar Designer @ 2011-06-13 6:48 UTC (permalink / raw) To: musl On Mon, Jun 13, 2011 at 12:54:18AM -0400, Rich Felker wrote: > On Mon, Jun 13, 2011 at 06:56:55AM +0400, Solar Designer wrote: > > IIRC, some ancient versions of glibc didn't allow programs to assign to > > errno at all, because it was declared as a macro (not a variable). That > > This sounds like an urban legend. errno is a macro and has been for a > long time (ever since threads) on most systems. It's required by the > standard to be an lvalue macro. Oh, of course I did not recall correctly. Here's what I think this was about: old programs such as qmail (not maintained upstream since 1998) used "extern int errno;" instead of including errno.h, and indeed this failed when errno became a macro (for threads, as you correctly remind me). So this was an entirely different issue. > > Is it guaranteed that errno is preserved across libc calls that complete > > without error? Maybe not. I don't really know, and I'd prefer not to > > depend on that. > > Unless it's documented that a particular function can't, libc > functions can clobber errno all they like, whether or not they return > failure. The only thing they can't do is set it to 0, unless they put > some other nonzero (hopefully meaningful) value in it before > returning. I went to: http://pubs.opengroup.org/onlinepubs/009695399/functions/errno.html and it does say "No function in this volume of IEEE Std 1003.1-2001 shall set errno to 0. The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified." Which not surprisingly matches what you wrote above. I was a bit puzzled why they decided to outlaw setting of errno to 0 by library functions, although this does make some sense to me (easy to achieve and preserves at least some recent error code for poorly written old programs). > This all makes using errno a little bit messy, but if libc functions > were required not to change errno except when reporting an error, > pretty much every libc function that uses other libc functions would > be full of useless bloat and slowdowns saving and restoring errno > values... Good point. I guess they'd resort to calling other than exported versions of the functions, though. But this could mean extra function call overhead for the exported versions... Alexander ^ permalink raw reply [flat|nested] 20+ messages in thread
* errno (was: Weekly reports - B) 2011-06-13 4:54 ` Rich Felker 2011-06-13 6:48 ` Solar Designer @ 2011-07-06 11:35 ` Solar Designer 2011-07-06 12:57 ` Szabolcs Nagy 2011-07-07 2:56 ` errno (was: Weekly reports - B) Rich Felker 1 sibling, 2 replies; 20+ messages in thread From: Solar Designer @ 2011-07-06 11:35 UTC (permalink / raw) To: musl Rich, On Mon, Jun 13, 2011 at 12:54:18AM -0400, Rich Felker wrote: > ... errno is a macro and has been for a > long time (ever since threads) on most systems. It's required by the > standard to be an lvalue macro. Any idea why glibc has __set_errno() internally instead of assigning to its errno directly, then? The implementation for __set_errno() does a direct assignment anyway. What did the glibc developers need __set_errno() for if errno is required to be an lvalue, and do they still need __set_errno() or is it legacy? Meanwhile, I continue to use __set_errno() in my glibc patches, at least for consistency with upstream's code. Thanks, Alexander ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: errno (was: Weekly reports - B) 2011-07-06 11:35 ` errno (was: Weekly reports - B) Solar Designer @ 2011-07-06 12:57 ` Szabolcs Nagy 2011-07-06 13:14 ` errno Solar Designer 2011-07-07 2:56 ` errno (was: Weekly reports - B) Rich Felker 1 sibling, 1 reply; 20+ messages in thread From: Szabolcs Nagy @ 2011-07-06 12:57 UTC (permalink / raw) To: musl * Solar Designer <solar@openwall.com> [2011-07-06 15:35:08 +0400]: > On Mon, Jun 13, 2011 at 12:54:18AM -0400, Rich Felker wrote: > > ... errno is a macro and has been for a > > long time (ever since threads) on most systems. It's required by the > > standard to be an lvalue macro. > > Any idea why glibc has __set_errno() internally instead of assigning to > its errno directly, then? The implementation for __set_errno() does a > direct assignment anyway. What did the glibc developers need it seems there was a different definition under sysdeps until 2002-07-19 Ulrich Drepper <drepper@redhat.com> * sysdeps/generic/bits/errno.h: Remove __set_errno definition. * ... and then 2002-11-25 Jakub Jelinek <jakub@redhat.com> * include/errno.h (__set_errno): Define as errno = val unconditionally. in older glibc eg sysdeps/unix/sysv/linux/bits/errno.h had code like #ifdef _ERRNO_H # undef EDOM # undef EILSEQ # undef ERANGE # include <linux/errno.h> /* Linux has no ENOTSUP error code. */ # define ENOTSUP EOPNOTSUPP /* Linux also has no ECANCELED error code. Since it is not used here we define it to an invalid value. */ # define ECANCELED 125 # ifndef __ASSEMBLER__ /* We now need a declaration of the `errno' variable. */ extern int errno; /* Function to get address of global `errno' variable. */ extern int *__errno_location __P ((void)) __attribute__ ((__const__)); # if defined _LIBC /* We wouldn't need a special macro anymore but it is history. */ # define __set_errno(val) (*__errno_location ()) = (val) # endif /* _LIBC */ # if !defined _LIBC || defined _LIBC_REENTRANT /* When using threads, errno is a per-thread value. */ # define errno (*__errno_location ()) # endif # endif /* !__ASSEMBLER__ */ #endif /* _ERRNO_H */ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: errno 2011-07-06 12:57 ` Szabolcs Nagy @ 2011-07-06 13:14 ` Solar Designer 0 siblings, 0 replies; 20+ messages in thread From: Solar Designer @ 2011-07-06 13:14 UTC (permalink / raw) To: musl On Wed, Jul 06, 2011 at 02:57:38PM +0200, Szabolcs Nagy wrote: > in older glibc eg sysdeps/unix/sysv/linux/bits/errno.h had code like ... > /* We wouldn't need a special macro anymore but it is history. */ It looks like we'd need to look at even older versions to find out why the macro was ever needed. Thanks! Alexander ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: errno (was: Weekly reports - B) 2011-07-06 11:35 ` errno (was: Weekly reports - B) Solar Designer 2011-07-06 12:57 ` Szabolcs Nagy @ 2011-07-07 2:56 ` Rich Felker 1 sibling, 0 replies; 20+ messages in thread From: Rich Felker @ 2011-07-07 2:56 UTC (permalink / raw) To: musl On Wed, Jul 06, 2011 at 03:35:08PM +0400, Solar Designer wrote: > Rich, > > On Mon, Jun 13, 2011 at 12:54:18AM -0400, Rich Felker wrote: > > ... errno is a macro and has been for a > > long time (ever since threads) on most systems. It's required by the > > standard to be an lvalue macro. > > Any idea why glibc has __set_errno() internally instead of assigning to > its errno directly, then? The implementation for __set_errno() does a > direct assignment anyway. What did the glibc developers need > __set_errno() for if errno is required to be an lvalue, and do they > still need __set_errno() or is it legacy? While this doesn't necessarily answer the historical question of whether or why it may have been needed, I think part of the reason for __set_errno (especiall in uclibc which uses a similar approach) might be keeping down code size or improving performance. Simple assignment to errno requires saving the value to be stored to errno in a non-call-clobbered register or on the stack, making a call to __errno_location, then reading back the saved error value and storing it at the address returned by __errno_location. On the other hand, with __set_errno, the process is just a single function call and the error value does not need to be saved for use after the call returns. Further, with NPTL's TLS model, it's possible to make __set_errno more efficient than using __errno_location would be. The latter is basically: mov %gs:0,%eax add $ERRNO_OFFSET,%eax ret while __set_errno can be purely: mov 4(%esp),%eax mov %eax,%gs:ERRNO_OFFSET ret And if you declare it regparm, you could even throw away the first instruction... Or you could just make it an inline function and get even bigger benefits (no actual call, on register spills, etc.) Personally, in musl I've avoided doing things like this in favor of simplicity. Presumably errno getting set should be a fairly uncommon occurrance anyway, so speed isn't all that important, and I like code that reads as plain C that could just as well be part of any implementation of the standard library rather than being full of implementation-specific tricks... Rich ^ permalink raw reply [flat|nested] 20+ messages in thread
* Weekly reports - X 2011-06-13 2:22 ` Rich Felker 2011-06-13 2:56 ` Solar Designer @ 2011-06-26 21:05 ` Luka Marčetić 2011-06-26 21:13 ` rich felker 1 sibling, 1 reply; 20+ messages in thread From: Luka Marčetić @ 2011-06-26 21:05 UTC (permalink / raw) To: musl Hi there. I'm sorry about falling behind so much. Good news though, summer brings me a free window that I'll be able to dedicate to cluts. This next week is the last one that I'll be busy with school until September. Next week, I'll finish format.c (and perhaps rename it to numerical.c or alike) and fix alloc.c(arrays instead of lists+implementing your suggestions-keep making them btw. i appreciate them). Things will finally pick up afterward. About the license: I've been quiet because I like copyleft. My preferred license is GPLv3+. But Solar I think said nobody is going to make their own proprietary version of the library, so why not just make the license permissive and let them use it however. Perhaps we could compromise and choose LGPL, the musl's license. I think the reasoning behind that particular license is clear. SUMMARY: 1) Serious work will start a week after this one. 2) How about LGPL as a compromise? Thanks. --Luka M. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Weekly reports - X 2011-06-26 21:05 ` Weekly reports - X Luka Marčetić @ 2011-06-26 21:13 ` rich felker 2011-06-27 22:18 ` Solar Designer 0 siblings, 1 reply; 20+ messages in thread From: rich felker @ 2011-06-26 21:13 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1926 bytes --] Luka, I would be happy enough with LGPL, but I believe Openwall's commitment to GSoC included terms that all the code developed under their projects would be under BSD license (or equally/more permissive). In any case I don't think the license matters at all for test case code. Anyone who wanted to improve it without releasing their improvements would almost surely be using it for internal use only (testing their implementation), not as a deployed product, so even if it were GPL they would not be obligated to release anything. Conversely, since it must be in source form to be useful for testing an implementation, even under BSD license, nobody could make a useful closed-source test product out of cluts - the source is essential to using it! Thus I think we should just put aside this bikeshed and BSD it. Rich On Sun, Jun 26, 2011 at 5:05 PM, Luka Marčetić <paxcoder@gmail.com> wrote: > Hi there. > I'm sorry about falling behind so much. Good news though, summer brings me > a free window that I'll be able to dedicate to cluts. This next week is the > last one that I'll be busy with school until September. Next week, I'll > finish format.c (and perhaps rename it to numerical.c or alike) and fix > alloc.c(arrays instead of lists+implementing your suggestions-keep making > them btw. i appreciate them). Things will finally pick up afterward. > About the license: I've been quiet because I like copyleft. My preferred > license is GPLv3+. But Solar I think said nobody is going to make their own > proprietary version of the library, so why not just make the license > permissive and let them use it however. Perhaps we could compromise and > choose LGPL, the musl's license. I think the reasoning behind that > particular license is clear. > > SUMMARY: 1) Serious work will start a week after this one. 2) How about > LGPL as a compromise? > Thanks. > --Luka M. > [-- Attachment #2: Type: text/html, Size: 2238 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Weekly reports - X 2011-06-26 21:13 ` rich felker @ 2011-06-27 22:18 ` Solar Designer 2011-07-04 19:30 ` Luka Marčetić 0 siblings, 1 reply; 20+ messages in thread From: Solar Designer @ 2011-06-27 22:18 UTC (permalink / raw) To: musl Luka, Rich - On Sun, Jun 26, 2011 at 05:13:42PM -0400, rich felker wrote: > I would be happy enough with LGPL, but I believe Openwall's commitment to > GSoC included terms that all the code developed under their projects would > be under BSD license (or equally/more permissive). This was mentioned, but it was not a commitment. Google is OK with any Open Source license. The ideas page for Openwall says: "With few exceptions (such as for changes to existing Linux kernel code, which is under GPLv2 anyway), we require any contributed code to be made available under a cut-down BSD license." "By applying to work on one of the ideas with us, you signify your acceptance of these terms and your intent to license your code contributions accordingly." So by applying to us under GSoC, Luka agreed to these terms. Yet I am willing to renegotiate to LGPL in this case, even though this makes me somewhat less willing to contribute to the project. (I realize that it may be the other way around for some other prospective contributors, though. Some people are more willing to contribute when they know that copyleft prevents their code from being used in proprietary products. In my case, I am happier to contribute when I know there won't be an artificial barrier to reuse of my code, especially to reuse by me. With copyleft, when I contribute to a source file that is not solely written by me, I then have difficulty reusing my own code contributions in differently-licensed projects.) Anyhow, the important thing now is for Luka to start placing his cluts code under any Open Source license. > In any case I don't think > the license matters at all for test case code. Anyone who wanted to improve > it without releasing their improvements would almost surely be using it for > internal use only (testing their implementation), not as a deployed product, > so even if it were GPL they would not be obligated to release anything. Right. But there might be reusable components - e.g., the framework may be reused for tests to be bundled with another library (not a libc). > Conversely, since it must be in source form to be useful for testing an > implementation, even under BSD license, nobody could make a useful > closed-source test product out of cluts - the source is essential to using > it! Thus I think we should just put aside this bikeshed and BSD it. Right. This sounds good to me. > On Sun, Jun 26, 2011 at 5:05 PM, Luka Mar??eti?? <paxcoder@gmail.com> wrote: > > I'm sorry about falling behind so much. Good news though, summer brings me > > a free window that I'll be able to dedicate to cluts. This next week is the > > last one that I'll be busy with school until September. Next week, I'll > > finish format.c (and perhaps rename it to numerical.c or alike) and fix > > alloc.c(arrays instead of lists+implementing your suggestions-keep making > > them btw. i appreciate them). Things will finally pick up afterward. Thank you for describing your nearest plans for work on cluts. When do you intend to start putting the tests into a framework? I think you should have started with that by now, but we were hoping you'd have more tests by now too... > > About the license: I've been quiet because I like copyleft. My preferred You should have stated so rather than remain quiet. > > license is GPLv3+. But Solar I think said nobody is going to make their own > > proprietary version of the library, so why not just make the license > > permissive and let them use it however. Perhaps we could compromise and > > choose LGPL, the musl's license. I think the reasoning behind that > > particular license is clear. > > > > SUMMARY: 1) Serious work will start a week after this one. That delay is really unfortunate, but we have to accept it I guess. > > 2) How about LGPL as a compromise? Please see above. Please commit your files with some Open Source license statements on them as soon as you reasonably can - perhaps tomorrow? If you choose cut-down BSD, it'd look like: /* * Copyright (c) 2011 Your Name <email addr> * * Redistribution and use in source and binary forms, with or without * modification, are permitted. * * There's ABSOLUTELY NO WARRANTY, express or implied. */ or you may use LGPL if this makes you more comfortable and thus results in more code from you. ;-) Thanks, Alexander ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Weekly reports - X 2011-06-27 22:18 ` Solar Designer @ 2011-07-04 19:30 ` Luka Marčetić 2011-07-04 19:39 ` Rich Felker 0 siblings, 1 reply; 20+ messages in thread From: Luka Marčetić @ 2011-07-04 19:30 UTC (permalink / raw) To: musl On 06/28/2011 12:18 AM, Solar Designer wrote: > > Please see above. > > Please commit your files with some Open Source license statements on > them as soon as you reasonably can - perhaps tomorrow? > > If you choose cut-down BSD, it'd look like: > > /* > * Copyright (c) 2011 Your Name<email addr> > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted. > * > * There's ABSOLUTELY NO WARRANTY, express or implied. > */ > > or you may use LGPL if this makes you more comfortable and thus results > in more code from you. ;-) > > Thanks, > > Alexander > Sorry for not responding, here I go now: I did push an Apache license to the repo (patent caluses etc. though really I'd like LGPL) before I saw this. But now that I see Openwall project requires a BSD license, I'll remove it. I guess I'll just add the above header to all the source files by Thursday. As I've mentioned to Alexander, I'm finishing up numeric.c today, and then I'll pick another task, and start writing a framework in parallel. In light of the discussion with Alex, I may also switch to daily reports this week. In any case, you'll be informed. -Luka ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Weekly reports - X 2011-07-04 19:30 ` Luka Marčetić @ 2011-07-04 19:39 ` Rich Felker 0 siblings, 0 replies; 20+ messages in thread From: Rich Felker @ 2011-07-04 19:39 UTC (permalink / raw) To: musl On Mon, Jul 04, 2011 at 09:30:47PM +0200, Luka Marčetić wrote: > mentioned to Alexander, I'm finishing up numeric.c today, and then > I'll pick another task, and start writing a framework in parallel. > In light of the discussion with Alex, I may also switch to daily > reports this week. In any case, you'll be informed. Daily reports would be great. Rich ^ permalink raw reply [flat|nested] 20+ messages in thread
* specification of cluts tests - code or/and data? (was: Weekly reports - B) 2011-06-13 2:11 ` Solar Designer 2011-06-13 2:22 ` Rich Felker @ 2011-06-13 2:22 ` Solar Designer 2011-06-13 9:19 ` specification of cluts tests - code or/and data? Solar Designer 1 sibling, 1 reply; 20+ messages in thread From: Solar Designer @ 2011-06-13 2:22 UTC (permalink / raw) To: musl Luka, Rich - On Mon, Jun 13, 2011 at 06:11:30AM +0400, Solar Designer wrote: > Overall, I think the code could be made prettier. I'll post an idea > (which you don't have to use, but you may) in another message. Here's what I meant: Rather than write a piece of code for testing every property of every function, we could consider implementing interpreters or wrapper functions for common tests, or tables (arrays of structs) listing similar tests. A problem here is that call to a string function via a function pointer might not invoke the same implementation that direct use would (there could be a macro or a C compiler builtin). On the other hand, this also means that whatever approach to program structure we choose, we could want to test both kinds of uses of string functions (direct and via function pointer), to test both implementations (which might be present). This is not directly relevant, but to illustrate the use of interpreter or data structure approach to a task where most people tend to write lots of code instead, see: http://openwall.info/wiki/people/solar/software/public-domain-source-code/intel-80186-disassembler This is a complete i80186 disassembler in only 164 bytes of code, plus some 2.5 KB of data (17 KB source). Other disassemblers I saw typically process the different instruction types, addressing modes, etc. in code, and are much larger (in terms of code+data, as well as their source code). Maybe this will give you some inspiration for coming up with suitable data structures to define some classes of tests. You do not have to take it to the same "extreme" level - very generic code, data structures that are tricky to specify in C. You'll need to find a balance that works well for cluts. And you do not have to use an approach like this at all. You may continue as you have started. I just thought I'd mention the option. Maybe this helps. Alexander ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: specification of cluts tests - code or/and data? 2011-06-13 2:22 ` specification of cluts tests - code or/and data? (was: Weekly reports - B) Solar Designer @ 2011-06-13 9:19 ` Solar Designer 0 siblings, 0 replies; 20+ messages in thread From: Solar Designer @ 2011-06-13 9:19 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1856 bytes --] Luka, Rich - On Mon, Jun 13, 2011 at 06:22:31AM +0400, Solar Designer wrote: > Rather than write a piece of code for testing every property of every > function, we could consider implementing interpreters or wrapper > functions for common tests, or tables (arrays of structs) listing similar > tests. A problem here is that call to a string function via a function > pointer might not invoke the same implementation that direct use would > (there could be a macro or a C compiler builtin). On the other hand, > this also means that whatever approach to program structure we choose, > we could want to test both kinds of uses of string functions (direct and > via function pointer), to test both implementations (which might be > present). I wrote some code to illustrate this. As written, it tests only some trivial properties of a handful of string functions, but it is extensible. Please see attached. Functions to test are specified like this: static void *i_memcpy(void *dst, const void *src, size_t n) { return memcpy(dst, src, n); /* might use inlined code */ } static fspec funcs[] = { {memcpy, {F_PTR | F_DST, F_DST, F_SRC, F_N}}, {i_memcpy, {F_PTR | F_DST, F_DST, F_SRC, F_N}}, {strcpy, {F_PTR | F_DST | F_NUL, F_DST, F_SRC}}, {strncpy, {F_PTR | F_DST | F_PAD, F_DST, F_SRC, F_N}}, {strcat, {F_PTR | F_DST | F_NUL, F_DST | F_SRC, F_SRC}}, {strncat, {F_PTR | F_DST | F_NUL, F_DST | F_SRC, F_SRC, F_N}}, {strchr, {F_PTR | F_IN_A1 | F_NUL, F_SRC, F_C}}, {strstr, {F_PTR | F_IN_A1 | F_NUL, F_SRC, F_SRC}}, {NULL} }; As written, arg_next() tries to test all values in a range, but it will need to be adjusted to skip ranges of string lengths for long strings. As you can see, deeply nested loops seen in Luka's code are avoided here. Even with 8-char tabs (my preference), everything comfortably fits in under 80 chars. Alexander [-- Attachment #2: str.c --] [-- Type: text/plain, Size: 3749 bytes --] /* * Copyright (c) 2011 Solar Designer <solar at openwall.com> * * Redistribution and use in source and binary forms, with or without * modification, are permitted. * * There's ABSOLUTELY NO WARRANTY, express or implied. */ #include <string.h> #include <stdlib.h> #include <stdio.h> #include <assert.h> #define STR_SIZE 100 #define MIN_C 'a' #define MAX_C 'z' #define F_DST 0x00000001 #define F_SRC 0x00000002 #define F_PTR 0x00000004 #define F_IS_PTR (F_DST | F_SRC | F_PTR) #define F_N 0x00000008 #define F_C 0x00000010 #define F_NUL 0x00000100 #define F_PAD 0x00000200 #define F_IN_A1 0x00000400 typedef struct { void *f; unsigned int a[4]; /* a0 = f(a1, a2, a3) */ } fspec; static void *i_memcpy(void *dst, const void *src, size_t n) { return memcpy(dst, src, n); /* might use inlined code */ } static fspec funcs[] = { {memcpy, {F_PTR | F_DST, F_DST, F_SRC, F_N}}, {i_memcpy, {F_PTR | F_DST, F_DST, F_SRC, F_N}}, {strcpy, {F_PTR | F_DST | F_NUL, F_DST, F_SRC}}, {strncpy, {F_PTR | F_DST | F_PAD, F_DST, F_SRC, F_N}}, {strcat, {F_PTR | F_DST | F_NUL, F_DST | F_SRC, F_SRC}}, {strncat, {F_PTR | F_DST | F_NUL, F_DST | F_SRC, F_SRC, F_N}}, {strchr, {F_PTR | F_IN_A1 | F_NUL, F_SRC, F_C}}, {strstr, {F_PTR | F_IN_A1 | F_NUL, F_SRC, F_SRC}}, {NULL} }; typedef struct { enum {A_DST, A_SRC, A_N, A_C} t; union { struct { char *s; size_t len; } s; size_t n; int c; } v; } arg; static void arg_reset(arg *a) { switch (a->t) { case A_DST: break; case A_SRC: a->v.s.s[0] = '\0'; a->v.s.len = 0; break; case A_N: a->v.n = 0; break; case A_C: a->v.c = MIN_C; break; default: abort(); } } static int arg_next(arg *a) { switch (a->t) { case A_DST: return 1; case A_SRC: a->v.s.s[a->v.s.len] = MIN_C + (a->v.s.len % (MAX_C - MIN_C + 1)); if (++a->v.s.len >= STR_SIZE) { arg_reset(a); return 1; } a->v.s.s[a->v.s.len] = '\0'; return 0; case A_N: if (++a->v.n >= STR_SIZE) { arg_reset(a); return 1; } return 0; case A_C: if (++a->v.c > MAX_C) { arg_reset(a); return 1; } return 0; default: abort(); } } static void arg_alloc(arg *a, unsigned int flags) { if (flags & F_IS_PTR) { a->t = (flags & F_SRC) ? A_SRC : A_DST; a->v.s.s = malloc(STR_SIZE * 2); /* consider strcat() */ assert(a->v.s.s != NULL); } else if (flags & F_N) a->t = A_N; else if (flags & F_C) a->t = A_C; else abort(); arg_reset(a); } static void arg_free(arg *a) { if (a->t == A_DST || a->t == A_SRC) free(a->v.s.s); } static void test_one(fspec *f) { arg a[3]; int ia, na; na = 1; while (f->a[na] && na < 4) na++; na--; for (ia = 0; ia < na; ia++) arg_alloc(&a[ia], f->a[ia + 1]); do { const char *r = NULL; /* (ptr, ptr, n) or (ptr, ptr) */ if ((f->a[1] & F_IS_PTR) && (f->a[2] & F_IS_PTR) && !(f->a[3] & ~F_N)) { r = ((char * (*)(char *, char *, size_t))f->f) (a[0].v.s.s, a[1].v.s.s, a[2].v.n); } else /* (ptr, c) */ if ((f->a[1] & F_IS_PTR) && (f->a[2] & F_C) && !f->a[3]) { r = ((char * (*)(char *, int))f->f) (a[0].v.s.s, a[1].v.c); } if (((f->a[0] & F_DST) && r != a[0].v.s.s) || ((f->a[0] & F_IN_A1) && r && (r < a[0].v.s.s || r > a[0].v.s.s + a[0].v.s.len))) fprintf(stderr, "Wrong return value: %p '%s'\n", r, r); /* * Should perform other checks here: for proper NUL termination or padding (as * indicated by F_NUL or F_PAD), etc. (need to add more flags). */ ia = 0; while (ia < na && arg_next(&a[ia])) ia++; } while (ia < na); for (ia = 0; ia < na; ia++) arg_free(&a[ia]); } static void test_all(void) { fspec *f; for (f = funcs; f->f; f++) test_one(f); } int main(void) { test_all(); return 0; } ^ permalink raw reply [flat|nested] 20+ messages in thread
* cluts repository (was: Weekly reports - B) 2011-06-09 20:20 Weekly reports - B Luka Marčetić 2011-06-12 23:13 ` Rich Felker 2011-06-13 2:11 ` Solar Designer @ 2011-07-09 6:41 ` Solar Designer 2011-07-09 11:31 ` cluts repository Solar Designer 2 siblings, 1 reply; 20+ messages in thread From: Solar Designer @ 2011-07-09 6:41 UTC (permalink / raw) To: musl Luka, On Thu, Jun 09, 2011 at 10:20:45PM +0200, Luka Mar??eti?? wrote: > Anyway, here's something... *hangs head* > https://github.com/paxcoder/cluts This gives error 404 today. Did you move the repository elsewhere or is it a github glitch? Alexander ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cluts repository 2011-07-09 6:41 ` cluts repository (was: Weekly reports - B) Solar Designer @ 2011-07-09 11:31 ` Solar Designer 0 siblings, 0 replies; 20+ messages in thread From: Solar Designer @ 2011-07-09 11:31 UTC (permalink / raw) To: musl Luka, On Sat, Jul 09, 2011 at 10:41:47AM +0400, Solar Designer wrote: > On Thu, Jun 09, 2011 at 10:20:45PM +0200, Luka Mar??eti?? wrote: > > Anyway, here's something... *hangs head* > > https://github.com/paxcoder/cluts > > This gives error 404 today. Did you move the repository elsewhere or is > it a github glitch? Oh, I just found (in another message) that you moved it to https://github.com/lmarcetic/cluts Alexander ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2011-07-09 11:31 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-06-09 20:20 Weekly reports - B Luka Marčetić 2011-06-12 23:13 ` Rich Felker 2011-06-13 2:11 ` Solar Designer 2011-06-13 2:22 ` Rich Felker 2011-06-13 2:56 ` Solar Designer 2011-06-13 4:54 ` Rich Felker 2011-06-13 6:48 ` Solar Designer 2011-07-06 11:35 ` errno (was: Weekly reports - B) Solar Designer 2011-07-06 12:57 ` Szabolcs Nagy 2011-07-06 13:14 ` errno Solar Designer 2011-07-07 2:56 ` errno (was: Weekly reports - B) Rich Felker 2011-06-26 21:05 ` Weekly reports - X Luka Marčetić 2011-06-26 21:13 ` rich felker 2011-06-27 22:18 ` Solar Designer 2011-07-04 19:30 ` Luka Marčetić 2011-07-04 19:39 ` Rich Felker 2011-06-13 2:22 ` specification of cluts tests - code or/and data? (was: Weekly reports - B) Solar Designer 2011-06-13 9:19 ` specification of cluts tests - code or/and data? Solar Designer 2011-07-09 6:41 ` cluts repository (was: Weekly reports - B) Solar Designer 2011-07-09 11:31 ` cluts repository Solar Designer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).