From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 687BC3858C83 for ; Tue, 18 Oct 2022 14:03:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 687BC3858C83 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666101833; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=fQFs34IKpBHHVfBugZqBgGPujHGzqQskchAM8nFuTq0=; b=ZorshqsuoG+gOraRDWCOICGb2cNvkh5MdRwMXRmdUPGlhDdkuEnN/ohu4sFGZunsZCJIG4 +gyelIC6tnbkcd9aXBWU7FarCtm4Z16l/X6n3wQI1MPGYUDlgzFvmo9GebPq0r6B5j5Alf 402fd62a3jZSXeBE04II/+9xPBtKqQk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-52-Lqdt0gbtOqGQK7Pel4Iadg-1; Tue, 18 Oct 2022 10:03:50 -0400 X-MC-Unique: Lqdt0gbtOqGQK7Pel4Iadg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DD916886088; Tue, 18 Oct 2022 14:03:49 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.193.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9F7A140C2086; Tue, 18 Oct 2022 14:03:49 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id E0EFCA80706; Tue, 18 Oct 2022 16:03:47 +0200 (CEST) Date: Tue, 18 Oct 2022 16:03:47 +0200 From: Corinna Vinschen To: newlib@sourceware.org, Brian.Inglis@systematicsw.ab.ca Subject: Re: Fw: [PATCH 1/2] strftime.c(__strftime): add %i, %q, %v, tests; tweak %Z docs Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org, Brian.Inglis@systematicsw.ab.ca References: <20220917050005.5758-1-Brian.Inglis@SystematicSW.ab.ca> <20220917050005.5758-2-Brian.Inglis@SystematicSW.ab.ca> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sep 19 11:51, C Howland wrote: > > > > ------------------------------ > > *From:* Newlib on > > behalf of Brian Inglis > > *Sent:* Saturday, September 17, 2022 1:00 AM > > *To:* Newlib > > *Subject:* [PATCH 1/2] strftime.c(__strftime): add %i, %q, %v, tests; > > tweak %Z docs > > > > > > > > newlib/libc/time/strftime.c(__strftime): > > %i year in century [00..99] Synonym for "%y". Non-POSIX extension. > > [tm_year] > > %q GNU quarter of the year (from `<<1>>' to `<<4>>') [tm_mon] > > %v OSX/Ruby VMS/Oracle date "%d-%b-%Y". Non-POSIX extension. [tm_mday, > > tm_mon, tm_year] > > add %i %q %v tests > > %Z clarify current time zone *abbreviation* not "name" [tm_isdst] > > --- > > newlib/libc/time/strftime.c | 67 +++++++++++++++++++++++++++++++++++-- > > 1 file changed, 64 insertions(+), 3 deletions(-) > > > > > While the additions themselves nominally look good, all being extensions > they ought to be gated by the appropriate ifdefs, and the manual would best > mention what gates are needed to get them. %q would be __GNU_VISIBLE as > the gate You're misunderstanding how these foo_VISIBLE macros are supposed to be used. They guard definitions and prototypes in header files depending on the application layer environment in terms of portability. They are not supposed to be used inside newlib code to create conditionalized library code. Of course you can argue that the code should not go in unconditionalized based on target preferences, but that should use one of the documented macros for newlib builds, e. g., _ELIX_LEVEL, _GLIBC_EXTENSION, or whatever. You can also argue that they should not go in at all. I'm doing this now for the sake of discussion: - %i: Where is used and documented? I don't see this in glibc, not even in the latest from the glibc git repo. - %q: Ditto. For a GNU extension, it's surprisingly absent from the most recent glibc code, or do I miss something? - %v: OSX/Ruby? Isn't that already gone? Also, it introduces another ambiguous date format where %F or equivalent should be used instead. It's nice to add features, but it wouldn't hurt to have some clarification and justification if it's non-standard stuff. Availability in glibc or in the BSDs is typically justification enough, but I don't see this here. Thanks, Corinna