From owner-freebsd-threads@freebsd.org Thu Jan 21 13:27:28 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02884A8B771 for ; Thu, 21 Jan 2016 13:27:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DC05A137F for ; Thu, 21 Jan 2016 13:27:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id D8961A8B76E; Thu, 21 Jan 2016 13:27:27 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6C41A8B76C; Thu, 21 Jan 2016 13:27:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 989F1137C; Thu, 21 Jan 2016 13:27:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id C742B1044CE3; Fri, 22 Jan 2016 00:27:14 +1100 (AEDT) Date: Fri, 22 Jan 2016 00:27:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Boris Astardzhiev , threads@freebsd.org, Jilles Tjoelker , net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <20160121093509.GK3942@kib.kiev.ua> Message-ID: <20160121233040.E1864@besplex.bde.org> References: <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=cK4dyQqN c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=-W6hXtnpK6wFgIz_TycA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 13:27:28 -0000 On Thu, 21 Jan 2016, Konstantin Belousov wrote: > On Wed, Jan 20, 2016 at 10:29:47AM +0200, Boris Astardzhiev wrote: >> kb>Shouldn't i and rcvd be unsigned as well ? Shouldn't return value >> kb>also be unsigned ? >> I think i and rcvd should be unsigned whereas ret should not - after all >> if an error occurred we get -1. > I looked at the real signatures and man pages for the Linux functions, > finally. There is indeed the timeout arg, the MSG_WAITFORONE flag for > recvmmsg(3), and Linux uses ints for what would be naturally size_t. It knows better than POSIX, so has restored the v7 types :-). Probably not intentionally. FreeBSD-1 used the v7 types for recv* in FreeBSD-1, but this was changed in 4.4BSD-Lite1. >> kb>> + rcvd = 0; >> kb>> + for (i = 0; i < vlen; i++) { >> kb>> + errno = 0; >> kb>> + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); >> kb>> + if (ret < 0 || errno != 0) { >> kb>I do not see why do you need to clear errno before, and then do this >> test. >> kb>Just check ret == -1, in which case errno was set from the immediate >> syscall. >> kb> >> kb>> + if (rcvd != 0) { >> kb>> + /* We've received messages. Let caller >> know. */ >> kb>> + errno = 0; >> kb>This cleaning is not needed as well. For successfull functions returns, >> kb>errno value is undefined. >> >> Wouldn't I confuse apps if they check errno in the follow case - I want to >> receive two messages. The first __sys_recvmsg succeeds and then for the >> second __sys_recvmsg fails. Thus errno will be != 0 and I'm telling the app >> that I have received one message by returning 1 but errno will be != 0. >> Is this correct? > > errno value is only defined after the function explicitely returned error. > Apps which test for errno without testing for error are wrong. Mostly such tests find wrong implementations. Only low quality implmentations set error for non-errors. I checked some details: - both C99 and POSIX.1-2001 forbid setting errno to 0 in library functions - C99 and draft C11 explicitly say that errno may be clobbered for non-errors by functions that are not documented to set errno. It intends to also say that errno may not be clobbered for non-errors by functions are documented to set errno, but actually says nothing about this case (except in a footnote, it says "Thus [the usual method of setting errno before the call and checking it after ``should'' be used to check for errors]." Footnotes are not part of the standard, so this also says nothing. But it gives the intent. - C99 doesn't say anything specific about this for strtol. But strtol needs errno to not be set on non-error for its API. This gives the intent of the documentation for errno in the standard itself. - POSIX.1-2001 says that applications "should" only be examined when it is indicated to be valid by a function's return value. This is wrong for all functions where errno is part of the API (like strtol), and it would be inconsistent with C99 and C11 if these standards said what they intend to say, for many more functions. First, all of the C99 functions that are documented to set errno. Then, if POSIX follows the spirit of the intent of C99, then just about all POSIX functions must not clobber errno for non-errors, since (unlike in C99) just about all functions in POSIX are documented to set errno. - POSIX.1-2001 apparently agrees with me that C99 doesn't say what it intends to say. It explicitly says that strtol shall not change "t setting of" errno on success, and marks this as an extension of C99. - I couldn't find even a buggy generic clause in POSIX.1-2001 saying what C99 intends to say even for the C99 parts of POSIX. If there were such a clause, then strtol wouldn't need a special extension. This means that some other C99 functions need special clauses, and there are likely to be bugs in this since some don't really need them except to conform with C99's intentions. - not many C99 functions are specified to set errno. The main ones are the strtol family, math functions (most can set ERANGE or EDOM), and wide character functions (many can set EILSEQ). POSIX.1-2001 seems to be missing a special clause for the first wide character function that I looked at -- fputwc(). For math functions, it has special statements ad nauseum (about 20 lines per function for duplicated for 20-50 functions). Bruce