From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "H.Merijn Brand" <h.m.brand@xs4all.nl>, git@vger.kernel.org
Subject: Re: [PATCH 2/3] convert "enum date_mode" into a struct
Date: Tue, 7 Jul 2015 16:48:37 -0400 [thread overview]
Message-ID: <20150707204837.GA15483@peff.net> (raw)
In-Reply-To: <xmqqbnfn3dsb.fsf@gitster.dls.corp.google.com>
On Tue, Jul 07, 2015 at 01:37:08PM -0700, Junio C Hamano wrote:
> > 3. Provide a wrapper that generates the correct struct on
> > the fly. The big downside is that we end up pointing to
> > a single global, which makes our wrapper non-reentrant.
> > But show_date is already not reentrant, so it does not
> > matter.
> >
> > This patch implements 3, along with a minor macro to keep
> > the size of the callers sane.
>
> Another big downside is that DATE_NORMAL is defined to be "0".
>
> This makes it very cumbersome to merge a side branch that uses an
> outdated definition of show_date() and its friends and tell them
> to show date normally. The compiler does not help detecting
> places that need to be adjusted during merge and instead just pass
> a NULL pointer as a pointer to the new struct.
My assumption was that using the raw "0" is something we would frowned
upon in new code. There was a single historical instance that I fixed in
the series, but I wouldn't expect new ones (and actually, that instance
was "1", which would be caught by the compiler).
However, if you're concerned, I think we could have show_date massage a
NULL date, like:
diff --git a/date.c b/date.c
index 8f91569..a04d089 100644
--- a/date.c
+++ b/date.c
@@ -173,6 +173,10 @@ const char *show_date(unsigned long time, int tz, const struct date_mode *mode)
{
struct tm *tm;
static struct strbuf timebuf = STRBUF_INIT;
+ static const struct fallback_mode = { DATE_NORMAL };
+
+ if (!mode)
+ mode = &fallback_mode;
if (mode->type == DATE_RAW) {
strbuf_reset(&timebuf);
That would also allow people to explicitly call:
show_date(t, tz, NULL);
to get the default format, though I personally prefer spelling it out.
I guess we _could_ introduce:
#define DATE_MODE(x) ((struct date_mode *)(x))
and then take any numeric value, under the assumption that the first
page of memory will never be a valid pointer:
diff --git a/date.c b/date.c
index 8f91569..f388fee 100644
--- a/date.c
+++ b/date.c
@@ -173,6 +173,18 @@ const char *show_date(unsigned long time, int tz, const struct date_mode *mode)
{
struct tm *tm;
static struct strbuf timebuf = STRBUF_INIT;
+ struct date_mode fallback;
+
+ /* hysterical compatibility */
+ if (mode < 1024) {
+ if (mode == DATE_STRFTIME)
+ die("BUG: nice try");
+ fallback.type = mode;
+ mode = &fallback;
+ }
+
+ if (!mode)
+ mode = &fallback_mode;
if (mode->type == DATE_RAW) {
strbuf_reset(&timebuf);
That's kind of nasty, but at least it's hidden from the callers.
-Peff
next prev parent reply other threads:[~2015-07-07 20:48 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-25 11:19 several date related issues H.Merijn Brand
2015-06-25 12:44 ` Jeff King
2015-06-25 12:56 ` H.Merijn Brand
2015-06-25 16:53 ` [PATCH 0/3] localized date format Jeff King
2015-06-25 16:54 ` [PATCH 1/3] show-branch: use DATE_RELATIVE instead of magic number Jeff King
2015-06-25 16:55 ` [PATCH 2/3] convert "enum date_mode" into a struct Jeff King
2015-06-25 17:03 ` John Keeping
2015-06-25 17:22 ` Jeff King
2015-07-07 20:37 ` Junio C Hamano
2015-07-07 20:48 ` Jeff King [this message]
2015-07-07 21:05 ` Junio C Hamano
2015-07-07 21:13 ` Jeff King
2015-07-07 21:19 ` Junio C Hamano
2015-06-25 16:55 ` [PATCH 3/3] introduce "format" date-mode Jeff King
2015-06-29 22:22 ` Eric Sunshine
2015-06-30 10:20 ` Jeff King
2015-06-30 16:22 ` Junio C Hamano
2015-06-30 17:50 ` Jeff King
2015-06-30 19:23 ` Junio C Hamano
2015-06-30 19:33 ` Jeff King
2015-06-30 16:58 ` Eric Sunshine
2015-06-30 17:58 ` Jeff King
2015-06-30 18:13 ` Eric Sunshine
2015-06-30 19:22 ` Jeff King
2015-06-30 17:05 ` Junio C Hamano
2015-06-30 17:48 ` Eric Sunshine
2015-06-30 19:17 ` Jeff King
2015-06-30 13:26 ` Jeff King
2015-06-30 17:05 ` Eric Sunshine
2015-07-21 0:41 ` Eric Sunshine
2015-07-21 1:19 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150707204837.GA15483@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=h.m.brand@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.