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.129.124]) by sourceware.org (Postfix) with ESMTPS id 5FD8C3858C78 for ; Tue, 1 Mar 2022 11:04:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5FD8C3858C78 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=1646132642; 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=lgtRnJyBvwuy0kwIFMtbAzwHlQxpi/YayhqYVodD9bI=; b=hx/Vq6OLyNFSQECFT2xaJ26haLXJpYYDtzndVGQ7CMHJjIApzntL6r6XCLBw8syUISaNm+ AWBggnBJCV+HYqyJZ632Hj0fLEqxbeN/TPlkp8ssGkib4jaTcPl80Tw2P+LRbEKyM+rrNu 1BvLTIBryOeH7QZuSkrcDBzBUOygb7Q= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-623-khfdhsUaPOOwPmbwFSS88Q-1; Tue, 01 Mar 2022 06:04:01 -0500 X-MC-Unique: khfdhsUaPOOwPmbwFSS88Q-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4299F1091DA0 for ; Tue, 1 Mar 2022 11:03:59 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.36.112.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 12C787C0CA for ; Tue, 1 Mar 2022 11:03:59 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id 87AE3A80F58; Tue, 1 Mar 2022 12:03:57 +0100 (CET) Date: Tue, 1 Mar 2022 12:03:57 +0100 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: [PATCH 2/2] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): POSIX angle bracket <> support Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: <20220225163959.48753-1-Brian.Inglis@SystematicSW.ab.ca> <20220225163959.48753-3-Brian.Inglis@SystematicSW.ab.ca> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=vinschen@redhat.com 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=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2022 11:04:05 -0000 On Feb 28 11:55, Brian Inglis wrote: > On 2022-02-28 05:04, Corinna Vinschen wrote: > > On Feb 25 09:39, Brian Inglis wrote: > > > +#define TZNAME_MIN 3 /* POSIX specified minimum TZ abbr size */ > > Are you sure? > > Minimum is historical. It's no POSIX value, so the comment is misleading. The value of 3 is fine, after all it's part of the POSIX description for TZ. > > > +#elif defined(_SC_TZNAME_MAX) > > > +#define TZNAME_MAX sysconf(_SC_TZNAME_MAX) /* use sysconf value */ > > > > This is not a safe bet. _SC_TZNAME_MAX is defined in unistd.h > > unconditionally, even for targets not providing sysconf(). And > > Why define indices if they are unusable on that platform? They are never unusable! They have to be defined as minimum set of index values requested by POSIX. A platform can easily return -1 for all of them to indicate it doesn't care for limits. Or, by also setting errno to EINVAL, indicate that a value is entirly unavailable in the current environment (which may differ on the same system). > > The real problem is, you can't use sysconf(_SC_TZNAME_MAX) like this: > > - You don't know at compile time if the function is really supported. > > - You don't know if _SC_TZNAME_MAX returns a positive value or -1. > > The docs appeared unclear whether the index or return value could be -1. > POSIX sysconf(3p) man page says -1/EINVAL means invalid argument value which > should not apply if _SC_TZNAME_MAX is defined, otherwise -1/errno is > unchanged means no definite limit?! Right. The required usage of sysconf goes like this: #include #include #include errno = 0; int ret = sysconf (_SC_foo); if (ret != -1) printf ("We have a limit %d\n", ret); else if (errno) printf ("We have an error %d\n", errno); else printf ("We have no limit\n"); Incidentally, Cygwin sets errno for _SC_TZNAME_MAX, rather than just returning -1. I just fixed that. > I can just enclose it in HAVE_SYSCONF, Newlib configury does not run this kind of test macros. After all, they would only test if that function is available on the build system. If the function is available on the target system, it would be defined by newlib itself, or be part of libgloss. > > So, either the system defines TZNAME_MAX, or the system provides > > sysconf() *and* sysconf(_SC_TZNAME_MAX) returns a positive value. In > > these cases, a check against that value makes sense. In all other > > cases, there's just no limit to check for. > > So I may as well default to using the hardwired limit of 10, which is the > most sensible value allowing for five letters, sign, four digits. Yeah, we might keep it at that. Cygwin isn't affected anyway, since it runs its own tzset code, see tzparse() in winsup/cygwin/localtime.cc. So we're doing this mostely for small targets. 10 should be fine. Thanks, Corinna