Re: [PATCH v2] credential: new attribute password_expiry_utc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 01, 2023 at 09:12:01AM -0800, Junio C Hamano wrote:

> Jeff King <peff@xxxxxxxx> writes:
> 
> >> diff --git a/builtin/credential-cache--daemon.c b/builtin/credential-cache--daemon.c
> >> index f3c89831d4a..338058be7f9 100644
> >> --- a/builtin/credential-cache--daemon.c
> >> +++ b/builtin/credential-cache--daemon.c
> >> @@ -127,6 +127,9 @@ static void serve_one_client(FILE *in, FILE *out)
> >>  		if (e) {
> >>  			fprintf(out, "username=%s\n", e->item.username);
> >>  			fprintf(out, "password=%s\n", e->item.password);
> >> +			if (e->item.password_expiry_utc != TIME_MAX)
> >> +				fprintf(out, "password_expiry_utc=%"PRItime"\n",
> >> +					e->item.password_expiry_utc);
> >>  		}
> >
> > Is there a particular reason to use TIME_MAX as the sentinel value here,
> > and not just "0"? It's not that big a deal either way, but it's more
> > usual in our code base to use "0" if there's no reason not to (and it
> > seems like nothing should be expiring in 1970 these days).
> 
> This is my fault ;-).  Here, there is no difference between 0 and
> TIME_MAX, but elsewhere the code needed
> 
> 	if (expiry != 0 && expiry < time(NULL))
> 
> to see if the entry has expired.  If the sentinel for an entry that
> will never expire were TIME_MAX, you do not need the first half of
> the expression.
> 
> I am OK either way.

Ah. That at least is a compelling reason to use TIME_MAX. I'm OK with
it.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux