Date: Sun, 6 Aug 2006 12:15:17 +0200 From: "Ralf S. Engelschall" <rse@FreeBSD.org> To: Dmitry Morozovsky <marck@rinet.ru> Subject: Re: [head tinderbox] failure on amd64/amd64 Message-ID: <20060806101517.GA37482@engelschall.com> In-Reply-To: <20060806133029.N36363@woozle.rinet.ru> References: <20060805155548.EBE837302F@freebsd-current.sentex.ca> <20060805220746.U9314@woozle.rinet.ru> <20060805223658.X9314@woozle.rinet.ru> <20060806082927.GA17297@engelschall.com> <20060806133029.N36363@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 06, 2006, Dmitry Morozovsky wrote:
> On Sun, 6 Aug 2006, Ralf S. Engelschall wrote:
>
> RSE> > DM> It seems at least on amd64 size_t (strlen() result) is not int.
> RSE> >
> RSE> > Or, maybe, the following would be less ugly:
>
> RSE> > tdone_str = ctime(&tdone);
> RSE> > + tdone_str[(strlen(tdone_str) - 1)] = '\0';
>
> Well, next thought: ctime(3) described as POSIX.1 function having fixed length
> of 26 chars. Is it safe and standards-compliant to save strlen(3) call and just
> use tdone_str[24] = '\0' ?
This was my first thought also after reading the ctime(3) manual page.
But after quickly checking the sources it didn't looked to me that
the string is always really exactly 26 characters only. I think the
strlen(3) call is acceptable as this way we are really doing what we
want: we strip the trailing newline. If we hard-code a "26" here we
would just obfuscate the source even more as the reader certainly
doesn't understand at the first spot from where the magic "26" comes
from.
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060806101517.GA37482>