From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org
Subject: Re: "#define precompose_argv(c,v) /* empty */" is evil
Date: Thu, 06 Aug 2020 21:03:37 -0700 [thread overview]
Message-ID: <xmqqlfirhzl2.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200807013230.GD8085@camp.crustytoothpaste.net> (brian m. carlson's message of "Fri, 7 Aug 2020 01:32:30 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
>> #ifdef NO_SETITIMER
>> -#define setitimer(which,value,ovalue)
>> +static inline int setitimer(int which, const struct itimerval *value, struct itimerval *newvalue) {
>
> The rest of the patch looks fine, but do we know that these structs will
> exist if NO_SETITIMER is defined? If not, we may need to use a void *
> here, which would provide us worse type checking, but would work on
> platforms that lack the interval timers at all, such as NonStop.
I thought about that and also making s/FILE/void/ for flockfile()
and funlockfile() for the same reason. Indeed my first draft used
"void *".
But because these no-op macros are designed to be used in the main
codepath WITHOUT surrounding #ifdef...#endif for readability, the
platforms that use NO_SETITIMER has to declare the variable that the
calling site of setitimer() passes as its parameters, so they must
have something called "struct itimerval". That is why I ended up
using the real type here
For example, builtin/log.c defines
static struct itimerval early_output_timer;
and makes an unconditional call OUTSIDE any #ifdef...#endif to
setitimer(), like so:
early_output_timer.it_value.tv_sec = 0;
early_output_timer.it_value.tv_usec = 500000;
setitimer(ITIMER_REAL, &early_output_timer, NULL);
I would expect that this is the use pattern any users of these
fallback definitions in git-compat-util.h should follow; those who
do not have "struct itimerval" natively indeed are using a fallback
definition from <git-compat-util.h>.
> That does kind of defeat the purpose of this patch, but I still think
> it's a win, since we end up with some type checking, even if it's not
> perfect, and almost every platform provides setitimer, so any errors
> will be caught quickly.
Yes, even if we loosen the type to "void *", it does catch certain
errors. One thing I wrote in the log message is that moving to
"static inline" allows us to catch not just type mismatches but also
missing variables (i.e. the original code used a variable that has
been renamed, and the instances of the variable used as parameters
to these no-op macros were left unmodified). That's not a type
mismatch but missing identifier. The motivating example was quite
similar; it was a field renamed but left unadjusted.
Thanks.
next prev parent reply other threads:[~2020-08-07 4:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-06 23:47 "#define precompose_argv(c,v) /* empty */" is evil Junio C Hamano
2020-08-07 0:01 ` brian m. carlson
2020-08-07 0:23 ` Junio C Hamano
2020-08-07 1:32 ` brian m. carlson
2020-08-07 4:03 ` Junio C Hamano [this message]
2020-08-07 3:27 ` Jeff King
2020-08-07 4:09 ` Junio C Hamano
2020-08-07 4:34 ` Jeff King
2020-08-07 6:42 ` Junio C Hamano
2020-08-07 7:56 ` Torsten Bögershausen
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqlfirhzl2.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=sandals@crustytoothpaste.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).