[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170615173109.GS1627@brightrain.aerifal.cx>
Date: Thu, 15 Jun 2017 13:31:09 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Handle localtime errors in ctime
On Thu, Jun 15, 2017 at 01:26:18PM -0400, Rich Felker wrote:
> On Thu, Jun 15, 2017 at 08:19:29PM +0300, Alexander Monakov wrote:
> > On Thu, 15 Jun 2017, Rich Felker wrote:
> > > > Um, the previous time an opposite direction was taken:
> > > > http://www.openwall.com/lists/musl/2014/09/05/17
> > >
> > > I found this in POSIX while reviewing the new patch:
> > >
> > > [CX] [Option Start] Upon successful completion, ctime_r() shall return
> > > a pointer to the string pointed to by buf. When an error is
> > > encountered, a null pointer shall be returned. [Option End]
> > >
> > > So while ISO C may not have anything to say about it (i.e. it's UB in
> > > plain C), POSIX does seem to require handling the error. I forgot we'd
> > > looked at this before but it seems we missed what POSIX had to say.
> >
> > .... even though the quoted POSIX spec specifically mentions ctime_r, not ctime?
> > (musl implementation of ctime_r does appear to miss that, though)
>
> Doh, I misread. Sorry. I'll go fix that now...
Look ok?
diff --git a/src/time/ctime_r.c b/src/time/ctime_r.c
index d2260a1..05699ca 100644
--- a/src/time/ctime_r.c
+++ b/src/time/ctime_r.c
@@ -3,6 +3,5 @@
char *ctime_r(const time_t *t, char *buf)
{
struct tm tm;
- localtime_r(t, &tm);
- return asctime_r(&tm, buf);
+ return localtime_r(t, &tm) ? asctime_r(&tm, buf) : 0;
}
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
