From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88689 invoked by alias); 8 Nov 2019 14:09:02 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 88681 invoked by uid 89); 8 Nov 2019 14:09:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT autolearn=ham version=3.3.1 spammy=gnulib's, gnulibs, html_node, localtime_r X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Nov 2019 14:09:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573222139; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SiyU17sIltQo83rNG8R6nqIamQQ4i38notmEoSts8XU=; b=NXtLFCFl7TAfWGjH4KxlUHbmqnyXRHz2dL3u1aOpliV/9414vnFMceLRToxjTWgk3CyUBc Vs/fGuoZxgmKEFLz+cd91usx5KScowDv4WBsXlgTkeApAOQPaBvGDA3f/DQM+phhNWLgdV sQRs5PnFL9QdoTv8e3ydqg6zfCoM6aI= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-340-bu1jQh6xOGqIAaWq6QngSg-1; Fri, 08 Nov 2019 09:08:57 -0500 Received: by mail-wm1-f70.google.com with SMTP id 2so3068773wmd.3 for ; Fri, 08 Nov 2019 06:08:57 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id j10sm448623wrx.30.2019.11.08.06.08.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Nov 2019 06:08:55 -0800 (PST) Subject: Re: [review v3] Use ctime_r and localtime_r if available To: gnutoolchain-gerrit@osci.io, Christian Biesinger , gdb-patches@sourceware.org References: <20191106203040.5207B25B28@gnutoolchain-gerrit.osci.io> From: Pedro Alves Message-ID: <00713bff-8560-e51f-f193-8845af83251e@redhat.com> Date: Fri, 08 Nov 2019 14:09:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20191106203040.5207B25B28@gnutoolchain-gerrit.osci.io> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-11/txt/msg00229.txt.bz2 On 11/6/19 8:30 PM, Christian Biesinger (Code Review) wrote: > Patch Set 3: >=20 > I looked at gnulib's time_r module but it turns out that its localtime_r = implementation is not in any way threadsafe. It does seemingly look that way: struct tm * localtime_r (time_t const * restrict t, struct tm * restrict tp) { return copy_tm_result (tp, localtime (t)); } But that doesn't seem worse than the #ifdef fallback that you're leaving in place. I'd argue that it'd be better to use the gnulib version. But read on, please. Looking at: https://www.gnu.org/software/gnulib/manual/html_node/localtime_005fr.html Of the problems that are relevant on our supported hosts, we see: Portability problems fixed by Gnulib: This function is missing on some platforms: mingw, MSVC 14.=20 And, note that localtime, like other C functions that use global state, are thread safe on Windows, because the C run time stores the global buffers in thread local storage. So the gnulib implementation ends up being thread safe there, even though it doesn't look like it is. Thanks, Pedro Alves