Re: [PATCH 3/3] introduce "format" date-mode
- From
Jeff King <peff@peff.net>
- Date
- Jun 30, 2015, 17:58 UTC
- Message-ID
- <20150630175852.GB5349@peff.net>
- In-Reply-To
- <CAPig+cTXc_RXbOAOaF2MFjrg+DSet=g0XQMZY0ErMYAmNVSV+g@mail.gmail.com>
On Tue, Jun 30, 2015 at 12:58:33PM -0400, Eric Sunshine wrote:
Show 14 quoted lines
> > Basically I was trying to avoid making any assumptions about exactly how > > strftime works. But presumably "stick a space in the format" is a > > universally reasonable thing to do. It's a hack, but it's contained to > > the function. > > I don't think we're making any assumptions about strftime(). POSIX states: > > The format string consists of zero or more conversion > specifications and ordinary characters. [...] All ordinary > characters (including the terminating NUL character) are copied > unchanged into the array. > > So, we seem to be on solid footing with this approach (even though > it's a localized hack).
Yeah, sorry I wasn't more clear. I had originally been thinking of making assumptions like "well, %c cannot ever be blank". But your solution does not suffer from that level of knowledge. I think it is reasonably clever.
Show 7 quoted lines
> Yeah, I toyed with the idea of increasing the requested amount each > iteration but wanted to keep the example simple, thus left it out. > However, for some reason, I was thinking that strbuf_grow() was > unconditionally expanding the buffer by the requested amount rather > than merely ensuring that that amount was availabile, so the amount > clearly needs to be increased on each iteration. Thanks for pointing > that out.
FWIW, I had to look at it to double-check. I've often made the same mistake.
> Beyond the extra allocation, I was also concerned about the > sledgehammer approach of "%s " to append a single character when there > are much less expensive ways to do so.
I don't think there's any other way. We have to feed a contiguous buffer to strftime, and we don't own the buffer, so we have to make a new copy.
-Peff