[00:01:00] --- kaj has left [02:07:30] --- haba has become available [02:11:31] --- Russ has left: Disconnected [02:19:06] --- haba has left [03:53:29] --- Jeffrey Altman has left: Replaced by new connection [03:53:30] --- Jeffrey Altman has become available [03:54:15] --- jaltman has left: Replaced by new connection [03:54:16] --- jaltman has become available [04:58:01] I was thinking about refactoring the strsafe.c file into separate files. Do you have any recommendation on how to divide the files? One function in each file? One type of function (Cat, Copy and so on) in each file or divide the files by character/byte count and char/wchar_t/TCHAR? [04:59:06] Also, should the functions be implemented in the header files for later inlining? Should this be done by including source code from other files or directly in strsafe.h? [04:59:35] You don't want to implement non-inlined functions in the header files - that's going to be really inefficient. [04:59:54] Bear in mind that we don't have support for 'static inline' on all of the platforms we ship. [05:00:50] The Microsoft library inlines the functions if #include is used, to avoid inlining all functions #define STRSAFE_LIB must be used before including the header file. [05:01:26] Personally, I don't think that we need to directly copy their inlining decisions. [05:01:57] Sounds reasonable. For now, I haven't done any inlining at all. [05:45:16] --- haba has become available [06:40:05] --- reuteras has left [06:55:52] --- deason has become available [07:13:02] --- matt has become available [08:22:17] --- jaltman has left: Disconnected [09:56:51] --- haba has left [10:11:07] --- Russ has become available [10:26:38] --- mattjsm has become available [10:49:07] --- _cclausen has become available [11:01:05] --- jaltman has become available [11:17:42] --- kaj has become available [11:18:23] --- kaj has left [13:28:58] --- Kevin Sumner has left [14:03:51] A document on writing TAP tests and API documentation for the C TAP library are now available at http://www.eyrie.org/~eagle/software/c-tap-harness/ [14:04:09] That document will be submitted for inclusion in the tests directory of openafs in a few. [14:04:36] cool [14:43:19] --- mattjsm has left [14:49:58] --- mmeffie has become available [15:06:33] mattjsm: kmutex stuff looks good [15:49:54] --- deason has left [17:20:25] er. except for MUTEX_EXIT [17:43:20] mattjsm: sent you a diff, looks like need to look at MUTEX_INIT argument list [17:43:22] ciao [17:49:36] --- matt has left [18:46:52] --- Kevin Sumner has become available [19:47:46] --- deason has become available [20:11:12] --- Born Fool has become available [21:03:56] --- Born Fool has left [21:49:26] When close() fails, what value(s) of errno do we set? [21:51:46] --- deason has left [22:04:36] the appropriate ones? ask a better question [22:04:54] "Is ECONNRESET one of them?" [22:05:33] seems unlikely [22:05:53] 54? [22:06:37] yeah. [22:06:52] no occurances that set it (tho if something generated it it would be translated for the wire, then back) [22:07:36] That's what it looked like, but I wanted to check (so that I can resist the temptation to contribute to a wankfest on a freebsd list). [22:08:06] I am still kind of curious which things might be set (or even approximately how many values would be valid), but it's not a big deal. [22:10:53] man 2 close? [22:11:15] (sadly we return more than that) [22:12:34] frex ENOSPC, EDQUOT, but those are legit [22:12:43] Right, my curiousity would be for {what we return}\setminus {what's in close(2)}. But if you don't know off the top of your head, don't worry about it. [22:12:48] We probably shouldn't, in an ideal world, and instead do some sort of error mapping, since it confuses some programs to get error codes back they don't recognize. Although part of that problem is that the close man page is usually crappy. [22:13:11] well, if you're overquota on close, it's not really EIO [22:13:17] Yup. [22:13:24] and most programs just ignore close()'s retrn anyway [22:13:28] "can't fail!" [22:13:28] That falls under the "the close man page is crappy" caveat. [22:13:30] > close man page is usually crappy Indeed. [22:13:58] The Linux version at least has a long warning telling people they had damn well better check the return status. [22:14:31] Still doesn't include ENOSPC or EDQUOT, though. [22:14:46] "patches welcome" [22:14:56] --- abo has left [22:15:02] Yeah, I should report a bug. [22:15:33] i should do the same for macos [22:15:42] --- abo has become available [22:15:58] hey wait, that's what gsoc students are for, right? where's kelli? ;) [22:16:13] I should do the same for fbsd as well. [22:16:51] my experience with bugs on fbsd has been poor. i'm going to wait until i have a quality submission to do another [22:16:52] --- Kevin Sumner has left [22:17:04] And probably also the patch that the committer rejected "because he wanted to have the english verified by a committer". [22:17:36] --- Kevin Sumner has become available [22:17:36] That's fine. Responsiveness to bug reports has varied quite a bit over time. [22:19:07] well, a sort of passively hostile reply, followed by bitbucketing the requested info as spam, then failing to handle the "doesn't crash anymore" patch i sent and still not removing the hardware from the HCL isn't exactly great. but i know we've done as badly, so i don't have a lot of room here. [22:19:24] i just wanted my damn router to work [22:20:08] Ah, someone already reported it in 2001 and the bug died in an attempt to document actual kernel source lines where other errors were returned. [22:20:16] http://bugs.debian.org/121701 [22:20:44] ... why would you want to document kernel source lines? They're just going to change. [22:20:58] I don't think the intention was to include that in the man page, just as justification that the change was correct. [22:21:24] Ah. [22:21:26] The bug discussion seems very confused. [22:22:42] the bug discussion seems... well, again, i should just shut up [22:23:09] Like a wanking exercise? :) [22:23:12] sure [22:23:24] Complete with an incorrect patch. [22:23:34] Since there are errnos for write() that make no sense at all for close(). [22:23:41] i don't really give a rat's ass what line generates it. here's a test program that generates it. if you don't think it should, patch the kernel. in the meantime, fix your manpage [22:24:14] I suspect that close() is not going to return EAGAIN or EINTR, although hm, maybe it could. [22:24:41] --- abo has left [22:24:42] if close() can force a write, why can't that write get EINTR or EAGAIN? [22:24:50] for systems where that might happen [22:24:55] Actually, the more I think about it, EFAULT may be the only code that's valid for write() that isn't going to work for close(). [22:24:56] --- abo has become available [22:25:13] Hm, phk submitted a fbsd bug report, but there is no wankery (or any discussion at all!) attached to it: http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/118214 [22:25:15] So that patch is correct. [22:26:12] state: open. ok, so at least everyone sucks. [22:26:47] You should file a bug with Apple so that they can tell you that they can't discuss when the bug might be fixed with anyone outside of Apple. :) [23:00:17] --- jaltman has left: Replaced by new connection [23:00:18] --- jaltman has become available