From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Zffb=5P=cs.ucla.edu=eggert@sourceware.org>
Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68])
	by sourceware.org (Postfix) with ESMTPS id D0A933858D35
	for <libc-alpha@sourceware.org>; Wed, 18 Jan 2023 22:12:30 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D0A933858D35
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu
Received: from localhost (localhost [127.0.0.1])
	by zimbra.cs.ucla.edu (Postfix) with ESMTP id B322016004F;
	Wed, 18 Jan 2023 14:12:29 -0800 (PST)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
	by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
	with ESMTP id YfXSVa0XE8GS; Wed, 18 Jan 2023 14:12:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0944C16006A;
	Wed, 18 Jan 2023 14:12:29 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 0944C16006A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu;
	s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1674079949;
	bh=tRBy6LKPzP3mYQPFMWqNR+G1osUlTUDGlk74sIt8PQM=;
	h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type:
	 Content-Transfer-Encoding;
	b=vF8J9qcku/bE9brZageT8Kh5ZhQhHhSvkTIDLDYx7MBwI18KIcKbu/Q8mlzpRI5Ng
	 8tWXUgS7Y1HQpQ53NK5Eg1idHfqi2H5mETNUQsC5fsDdlFkZkm7tnuGq80mxGnS/rX
	 Cc74hRH35bqROD8q2BafYPJ/gvMUc2pCIbsIfamY=
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
	by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 1F1GD1Hjhpi6; Wed, 18 Jan 2023 14:12:28 -0800 (PST)
Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200])
	by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id DE96816004F;
	Wed, 18 Jan 2023 14:12:28 -0800 (PST)
Message-ID: <3dc4be13-a454-3cd5-6a83-d9dfa4c3d7dd@cs.ucla.edu>
Date: Wed, 18 Jan 2023 14:12:28 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: mktime result may depend on previous calls
Content-Language: en-US
To: Max Nikulin <manikulin@gmail.com>
References: <tq93sc$p3$1@ciao.gmane.io>
Cc: libc-alpha@sourceware.org
From: Paul Eggert <eggert@cs.ucla.edu>
Organization: UCLA Computer Science Department
In-Reply-To: <tq93sc$p3$1@ciao.gmane.io>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <libc-alpha.sourceware.org>

On 1/18/23 07:39, Max Nikulin via Libc-alpha wrote:
> Is it intended that hidden state affects returned value?

I intended for it, yes. The behavior is allowed by POSIX and by the GNU 
spec, and it helps performance in the typical case.

If there's a faster way to implement mktime that doesn't involve a 
cache, that might be a good thing to implement.