Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Jens Gustedt Newsgroups: comp.lang.c,comp.programming.threads Subject: Re: Trivial C11 threads.h wrapper (public domain) Date: Mon, 01 Oct 2012 00:37:55 +0200 Organization: A noiseless patient Spider Lines: 61 Message-ID: <5068C9C3.6090502@loria.fr> References: <5065EAFD.1050102@loria.fr> <5068B604.9020606@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="2590e4fa64e7931a8f955de6703c052f"; logging-data="12992"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/doMdlA78CVY2noBgOqidlRPnPgvAs5KE=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 In-Reply-To: Cancel-Lock: sha1:L3fI4phkxFBsWgGpgmKSSXy0Rlo= Xref: csiph.com comp.lang.c:26916 comp.programming.threads:1130 Am 30.09.2012 23:28, schrieb Keith Thompson: > Markus Elfring writes: >>> There is already an implementation of C11 threads as a wrapper around >>> POSIX threads that is publicly available. >> >> I would interpret source code like the following as an update candidate. > > I'm not sure what you mean by "update candidate". > >> http://p99.gforge.inria.fr/p99-html/p99__threads_8h_source.html : >> ... >> 00633 // 7.26.4 Mutex functions >> 00634 >> 00638 p99_inline >> 00639 void mtx_destroy(mtx_t *p00_mtx) { >> 00640 (void)pthread_mutex_destroy(&P99_ENCP(p00_mtx)); >> 00641 } >> ... >> >> >> How do think about to get rid of the cast to the return type "void" in >> such use cases? > > It doesn't matter much. The POSIX pthread_mutex_destroy() function > returns an int result; the C11 mtx_destroy() function returns void. > The (void) cast in this particular implementation is probably > there to silence a compiler warning about the result of the call > being discarded. The semantics are exactly the same with or without > the cast. Exactly, in particular there are some linux systems where the headers are annotated with gcc extensions that make it difficult to ignore the return of a system function. And if you (Markus) refer to the fact of "casting a return type", this is something completely different from "casting a function pointer to a function type with a different return type". In one case the compiler is supposed to convert the actual return type into something different (with well defined rules) and in the other case you would trick the compiler to believe that the return type would be of a certain type (live on the stack, in a certain hardware register). In the particular case of a cast with "(void)" has a special semantic in the standard (here C11), namely to ignore the value an to evaluate the expression just for its side effects: > 6.3.2.2 void ... If an expression of any other type is evaluated as > a void expression, its value or designator is discarded. (A void > expression is evaluated for its side effects.) and then in an example it even explains > If a function call is evaluated as an expression statement for its > side effects only, the discarding of its value may be made explicit by > converting the expression to a void expression by means of a cast And then, finally, the C11 standard leaves no way to get semantic of a failed call accros, here. Do you see a way to use the return value in some way? Jens