From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124946 invoked by alias); 14 Jun 2016 19:07:33 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 124931 invoked by uid 89); 14 Jun 2016 19:07:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=nss, among X-HELO: mx1.redhat.com Message-ID: <1465931244.19633.120.camel@localhost.localdomain> Subject: Re: [PATCH] New condvar implementation that provides stronger ordering guarantees. From: Torvald Riegel To: Florian Weimer Cc: GLIBC Devel , "Carlos O'Donell" , David Miller , Darren Hart Date: Tue, 14 Jun 2016 19:07:00 -0000 In-Reply-To: <3a0380b8-d958-6af6-28ca-d228353d9ef8@redhat.com> References: <1464268895.17104.14.camel@localhost.localdomain> <9ba4528e-6c48-f832-825a-bdc68c37eb47@redhat.com> <1465928107.19633.109.camel@localhost.localdomain> <3a0380b8-d958-6af6-28ca-d228353d9ef8@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00548.txt.bz2 On Tue, 2016-06-14 at 20:27 +0200, Florian Weimer wrote: > On 06/14/2016 08:15 PM, Torvald Riegel wrote: > >> One small nit: GNU style does not > >> use a parenthesis at the end of a line, as in (among others): > >> > >> + uint64_t r = __condvar_fetch_add_64_relaxed ( > >> > >> + return __condvar_load_64_relaxed ( > > > > What's the expected solution, parenthesis on the next line? > > Exactly, like this: > > return long_function name > (some_long expression_on_the_next_line_in_the_input_file); I'll change that. > >> There are some magic numbers 2/4/8, which might better use symbolic > >> constants. > > > > I considered this, but kind of preferred the short numbers. If we > > prefer constants with names, I'll change that. > > I prefer them in the code I'm working on. But I understand that > preferences differ. > > >> pthread_cond_common.c should be a header file (pthread_cond_common.h). > > > > There are many cases of C files being included across all of glibc. Are > > there precise rules for when to pick .h vs. .c? pthread_cond_common.c > > doesn't have just declarations or small helper functions, so .c seemd to > > be the right choice. > > As far as I can tell, we use .c only if the file is *also* compiled as a > C source file. In such cases, there are some preprocessor macros you > can define to alter the behavior, before including the file. In other > cases, it's used to create test cases with different compiler/linker > flags (e.g., static linking). Or it's an override for the sysdeps > mechanism. For example, have a look at these: posix/regex_internal.c nss/nss_files/files-parse.c nss/getXXbyYY.c I believe pthread_cond_common.c is similar. It doesn't use the preprocessor to alter any behavior, but just uses C to provide commonly used functionality. It doesn't provide any functions that are just declarations, so something a C header would typically do.