| Message ID | 520da361-1b80-4ba3-87b2-86d6fdfc18b5@web.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] t-prio-queue: simplify using compound literals | expand |
René Scharfe <l.s.r@web.de> writes: > Test names like "basic" are mentioned seven times in the code (ignoring > case): Twice when defining the input and result macros, thrice when > defining the test function, and twice again when calling it. Reduce > that to a single time by using compound literals to pass the input and > result arrays via TEST_INPUT to test_prio_queue(). > > Signed-off-by: René Scharfe <l.s.r@web.de> > --- > C99 added compound literals. Are we ready to use them? We don't know. This might be a good weather-baloon, but I do not know if people skip t/unit-tests/ without telling us. After a few releases with this patch in, perhaps we can find a more central place to use them to deliberately break the build of these folks and have them complain, and revert it if it becomes needed?
On Tue, Apr 02, 2024 at 08:30:31PM +0200, René Scharfe wrote: > Test names like "basic" are mentioned seven times in the code (ignoring > case): Twice when defining the input and result macros, thrice when > defining the test function, and twice again when calling it. Reduce > that to a single time by using compound literals to pass the input and > result arrays via TEST_INPUT to test_prio_queue(). > > Signed-off-by: René Scharfe <l.s.r@web.de> > --- > C99 added compound literals. Are we ready to use them? > > Test definitions become more compact, but look busier due to the added > punctuation. We could hide some of it with a sugary macro like this: > #define INT_ARRAY(...) ((int []){ __VA_ARGS__ }) FWIW, I think the result is way more readable than the original, even without the INT_ARRAY (which I'm not sure adds much). I don't have a strong opinion on compound literals in general, but if we did allow them, we could clean up the horrible non-reentrant DATE_MODE(). -Peff
Am 02.04.24 um 22:41 schrieb Jeff King: > > I don't have a > strong opinion on compound literals in general, but if we did allow > them, we could clean up the horrible non-reentrant DATE_MODE(). We can easily make them reentrant without compound literals. It just requires simple changes to lots of places. Patch below. --- >8 --- Subject: [PATCH] date: make DATE_MODE thread-safe date_mode_from_type() modifies a static variable and returns a pointer to it. This is not thread-safe. Most callers of date_mode_from_type() use it via the macro DATE_MODE and pass its result on to functions like show_date(), which take a const pointer and don't modify the struct. Avoid the static storage by putting the variable on the stack and returning the whole struct date_mode. Change functions that take a constant pointer to expect the whole struct instead. Reduce the cost of passing struct date_mode around on 64-bit systems by reordering its members to close the hole between the 32-bit wide .type and the 64-bit aligned .strftime_fmt as well as the alignment hole at the end. sizeof reports 24 before and 16 with this change on x64. Keep .type at the top to still allow initialization without designator -- though that's only done in a single location, in builtin/blame.c. Signed-off-by: René Scharfe <l.s.r@web.de> --- builtin/blame.c | 4 ++-- date.c | 36 ++++++++++++++++++------------------ date.h | 6 +++--- gpg-interface.c | 2 +- log-tree.c | 2 +- oss-fuzz/fuzz-date.c | 6 +++--- pretty.c | 18 +++++++++--------- pretty.h | 2 +- ref-filter.c | 2 +- reflog-walk.c | 4 ++-- reflog-walk.h | 4 ++-- t/helper/test-date.c | 2 +- 12 files changed, 44 insertions(+), 44 deletions(-) diff --git a/builtin/blame.c b/builtin/blame.c index db1f56de61..9aa74680a3 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -316,7 +316,7 @@ static const char *format_time(timestamp_t time, const char *tz_str, size_t time_width; int tz; tz = atoi(tz_str); - time_str = show_date(time, tz, &blame_date_mode); + time_str = show_date(time, tz, blame_date_mode); strbuf_addstr(&time_buf, time_str); /* * Add space paddings to time_buf to display a fixed width @@ -1029,7 +1029,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix) blame_date_width = sizeof("Thu Oct 19 16:00:04 2006 -0700"); break; case DATE_STRFTIME: - blame_date_width = strlen(show_date(0, 0, &blame_date_mode)) + 1; /* add the null */ + blame_date_width = strlen(show_date(0, 0, blame_date_mode)) + 1; /* add the null */ break; } blame_date_width -= 1; /* strip the null */ diff --git a/date.c b/date.c index 44cf2221d8..7365a4ad24 100644 --- a/date.c +++ b/date.c @@ -207,13 +207,13 @@ void show_date_relative(timestamp_t time, struct strbuf *timebuf) (diff + 183) / 365); } -struct date_mode *date_mode_from_type(enum date_mode_type type) +struct date_mode date_mode_from_type(enum date_mode_type type) { - static struct date_mode mode = DATE_MODE_INIT; + struct date_mode mode = DATE_MODE_INIT; if (type == DATE_STRFTIME) BUG("cannot create anonymous strftime date_mode struct"); mode.type = type; - return &mode; + return mode; } static void show_date_normal(struct strbuf *buf, timestamp_t time, struct tm *tm, int tz, struct tm *human_tm, int human_tz, int local) @@ -283,7 +283,7 @@ static void show_date_normal(struct strbuf *buf, timestamp_t time, struct tm *tm strbuf_addf(buf, " %+05d", tz); } -const char *show_date(timestamp_t time, int tz, const struct date_mode *mode) +const char *show_date(timestamp_t time, int tz, struct date_mode mode) { struct tm *tm; struct tm tmbuf = { 0 }; @@ -291,13 +291,13 @@ const char *show_date(timestamp_t time, int tz, const struct date_mode *mode) int human_tz = -1; static struct strbuf timebuf = STRBUF_INIT; - if (mode->type == DATE_UNIX) { + if (mode.type == DATE_UNIX) { strbuf_reset(&timebuf); strbuf_addf(&timebuf, "%"PRItime, time); return timebuf.buf; } - if (mode->type == DATE_HUMAN) { + if (mode.type == DATE_HUMAN) { struct timeval now; get_time(&now); @@ -306,22 +306,22 @@ const char *show_date(timestamp_t time, int tz, const struct date_mode *mode) human_tz = local_time_tzoffset(now.tv_sec, &human_tm); } - if (mode->local) + if (mode.local) tz = local_tzoffset(time); - if (mode->type == DATE_RAW) { + if (mode.type == DATE_RAW) { strbuf_reset(&timebuf); strbuf_addf(&timebuf, "%"PRItime" %+05d", time, tz); return timebuf.buf; } - if (mode->type == DATE_RELATIVE) { + if (mode.type == DATE_RELATIVE) { strbuf_reset(&timebuf); show_date_relative(time, &timebuf); return timebuf.buf; } - if (mode->local) + if (mode.local) tm = time_to_tm_local(time, &tmbuf); else tm = time_to_tm(time, tz, &tmbuf); @@ -331,17 +331,17 @@ const char *show_date(timestamp_t time, int tz, const struct date_mode *mode) } strbuf_reset(&timebuf); - if (mode->type == DATE_SHORT) + if (mode.type == DATE_SHORT) strbuf_addf(&timebuf, "%04d-%02d-%02d", tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday); - else if (mode->type == DATE_ISO8601) + else if (mode.type == DATE_ISO8601) strbuf_addf(&timebuf, "%04d-%02d-%02d %02d:%02d:%02d %+05d", tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec, tz); - else if (mode->type == DATE_ISO8601_STRICT) { + else if (mode.type == DATE_ISO8601_STRICT) { strbuf_addf(&timebuf, "%04d-%02d-%02dT%02d:%02d:%02d", tm->tm_year + 1900, tm->tm_mon + 1, @@ -354,16 +354,16 @@ const char *show_date(timestamp_t time, int tz, const struct date_mode *mode) tz = abs(tz); strbuf_addf(&timebuf, "%02d:%02d", tz / 100, tz % 100); } - } else if (mode->type == DATE_RFC2822) + } else if (mode.type == DATE_RFC2822) strbuf_addf(&timebuf, "%.3s, %d %.3s %d %02d:%02d:%02d %+05d", weekday_names[tm->tm_wday], tm->tm_mday, month_names[tm->tm_mon], tm->tm_year + 1900, tm->tm_hour, tm->tm_min, tm->tm_sec, tz); - else if (mode->type == DATE_STRFTIME) - strbuf_addftime(&timebuf, mode->strftime_fmt, tm, tz, - !mode->local); + else if (mode.type == DATE_STRFTIME) + strbuf_addftime(&timebuf, mode.strftime_fmt, tm, tz, + !mode.local); else - show_date_normal(&timebuf, time, tm, tz, &human_tm, human_tz, mode->local); + show_date_normal(&timebuf, time, tm, tz, &human_tm, human_tz, mode.local); return timebuf.buf; } diff --git a/date.h b/date.h index 6136212a19..0747864fd7 100644 --- a/date.h +++ b/date.h @@ -22,8 +22,8 @@ enum date_mode_type { struct date_mode { enum date_mode_type type; - const char *strftime_fmt; int local; + const char *strftime_fmt; }; #define DATE_MODE_INIT { \ @@ -36,14 +36,14 @@ struct date_mode { * show_date(t, tz, DATE_MODE(NORMAL)); */ #define DATE_MODE(t) date_mode_from_type(DATE_##t) -struct date_mode *date_mode_from_type(enum date_mode_type type); +struct date_mode date_mode_from_type(enum date_mode_type type); /** * Format <'time', 'timezone'> into static memory according to 'mode' * and return it. The mode is an initialized "struct date_mode" * (usually from the DATE_MODE() macro). */ -const char *show_date(timestamp_t time, int timezone, const struct date_mode *mode); +const char *show_date(timestamp_t time, int timezone, struct date_mode mode); /** * Parse a date format for later use with show_date(). diff --git a/gpg-interface.c b/gpg-interface.c index 95e764acb1..1ee2c94a3b 100644 --- a/gpg-interface.c +++ b/gpg-interface.c @@ -483,7 +483,7 @@ static int verify_ssh_signed_buffer(struct signature_check *sigc, if (sigc->payload_timestamp) strbuf_addf(&verify_time, "-Overify-time=%s", - show_date(sigc->payload_timestamp, 0, &verify_date_mode)); + show_date(sigc->payload_timestamp, 0, verify_date_mode)); /* Find the principal from the signers */ strvec_pushl(&ssh_keygen.args, fmt->program, diff --git a/log-tree.c b/log-tree.c index 59eeaef1f7..16031b44e7 100644 --- a/log-tree.c +++ b/log-tree.c @@ -773,7 +773,7 @@ void show_log(struct rev_info *opt) */ show_reflog_message(opt->reflog_info, opt->commit_format == CMIT_FMT_ONELINE, - &opt->date_mode, + opt->date_mode, opt->date_mode_explicit); if (opt->commit_format == CMIT_FMT_ONELINE) return; diff --git a/oss-fuzz/fuzz-date.c b/oss-fuzz/fuzz-date.c index 036378b946..9619dae40e 100644 --- a/oss-fuzz/fuzz-date.c +++ b/oss-fuzz/fuzz-date.c @@ -11,7 +11,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) int16_t tz; timestamp_t ts; enum date_mode_type dmtype; - struct date_mode *dm; + struct date_mode dm; if (size <= 4) /* @@ -40,10 +40,10 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) free(str); dm = date_mode_from_type(dmtype); - dm->local = local; + dm.local = local; show_date(ts, (int)tz, dm); - date_mode_release(dm); + date_mode_release(&dm); return 0; } diff --git a/pretty.c b/pretty.c index 2faf651d3e..7ead078998 100644 --- a/pretty.c +++ b/pretty.c @@ -428,7 +428,7 @@ static void add_rfc2047(struct strbuf *sb, const char *line, size_t len, } const char *show_ident_date(const struct ident_split *ident, - const struct date_mode *mode) + struct date_mode mode) { timestamp_t date = 0; long tz = 0; @@ -592,7 +592,7 @@ void pp_user_info(struct pretty_print_context *pp, switch (pp->fmt) { case CMIT_FMT_MEDIUM: strbuf_addf(sb, "Date: %s\n", - show_ident_date(&ident, &pp->date_mode)); + show_ident_date(&ident, pp->date_mode)); break; case CMIT_FMT_EMAIL: case CMIT_FMT_MBOXRD: @@ -601,7 +601,7 @@ void pp_user_info(struct pretty_print_context *pp, break; case CMIT_FMT_FULLER: strbuf_addf(sb, "%sDate: %s\n", what, - show_ident_date(&ident, &pp->date_mode)); + show_ident_date(&ident, pp->date_mode)); break; default: /* notin' */ @@ -775,7 +775,7 @@ static int mailmap_name(const char **email, size_t *email_len, static size_t format_person_part(struct strbuf *sb, char part, const char *msg, int len, - const struct date_mode *dmode) + struct date_mode dmode) { /* currently all placeholders have same length */ const int placeholder_len = 2; @@ -1034,7 +1034,7 @@ static void rewrap_message_tail(struct strbuf *sb, static int format_reflog_person(struct strbuf *sb, char part, struct reflog_walk_info *log, - const struct date_mode *dmode) + struct date_mode dmode) { const char *ident; @@ -1602,7 +1602,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */ if (c->pretty_ctx->reflog_info) get_reflog_selector(sb, c->pretty_ctx->reflog_info, - &c->pretty_ctx->date_mode, + c->pretty_ctx->date_mode, c->pretty_ctx->date_mode_explicit, (placeholder[1] == 'd')); return 2; @@ -1617,7 +1617,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */ return format_reflog_person(sb, placeholder[1], c->pretty_ctx->reflog_info, - &c->pretty_ctx->date_mode); + c->pretty_ctx->date_mode); } return 0; /* unknown %g placeholder */ case 'N': @@ -1712,11 +1712,11 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */ case 'a': /* author ... */ return format_person_part(sb, placeholder[1], msg + c->author.off, c->author.len, - &c->pretty_ctx->date_mode); + c->pretty_ctx->date_mode); case 'c': /* committer ... */ return format_person_part(sb, placeholder[1], msg + c->committer.off, c->committer.len, - &c->pretty_ctx->date_mode); + c->pretty_ctx->date_mode); case 'e': /* encoding */ if (c->commit_encoding) strbuf_addstr(sb, c->commit_encoding); diff --git a/pretty.h b/pretty.h index 9cc9e5d42b..df267afe4a 100644 --- a/pretty.h +++ b/pretty.h @@ -167,7 +167,7 @@ int format_set_trailers_options(struct process_trailer_options *opts, * a well-known sentinel date if they appear bogus. */ const char *show_ident_date(const struct ident_split *id, - const struct date_mode *mode); + struct date_mode mode); #endif /* PRETTY_H */ diff --git a/ref-filter.c b/ref-filter.c index 03542d0236..59ad6f54dd 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -1627,7 +1627,7 @@ static void grab_date(const char *buf, struct atom_value *v, const char *atomnam tz = strtol(zone, NULL, 10); if ((tz == LONG_MIN || tz == LONG_MAX) && errno == ERANGE) goto bad; - v->s = xstrdup(show_date(timestamp, tz, &date_mode)); + v->s = xstrdup(show_date(timestamp, tz, date_mode)); v->value = timestamp; date_mode_release(&date_mode); return; diff --git a/reflog-walk.c b/reflog-walk.c index d216f6f966..66484f4f32 100644 --- a/reflog-walk.c +++ b/reflog-walk.c @@ -223,7 +223,7 @@ int add_reflog_for_walk(struct reflog_walk_info *info, void get_reflog_selector(struct strbuf *sb, struct reflog_walk_info *reflog_info, - const struct date_mode *dmode, int force_date, + struct date_mode dmode, int force_date, int shorten) { struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog; @@ -297,7 +297,7 @@ timestamp_t get_reflog_timestamp(struct reflog_walk_info *reflog_info) } void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline, - const struct date_mode *dmode, int force_date) + struct date_mode dmode, int force_date) { if (reflog_info && reflog_info->last_commit_reflog) { struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog; diff --git a/reflog-walk.h b/reflog-walk.h index 4d93a26957..989583dc55 100644 --- a/reflog-walk.h +++ b/reflog-walk.h @@ -10,14 +10,14 @@ void reflog_walk_info_release(struct reflog_walk_info *info); int add_reflog_for_walk(struct reflog_walk_info *info, struct commit *commit, const char *name); void show_reflog_message(struct reflog_walk_info *info, int, - const struct date_mode *, int force_date); + struct date_mode, int force_date); void get_reflog_message(struct strbuf *sb, struct reflog_walk_info *reflog_info); const char *get_reflog_ident(struct reflog_walk_info *reflog_info); timestamp_t get_reflog_timestamp(struct reflog_walk_info *reflog_info); void get_reflog_selector(struct strbuf *sb, struct reflog_walk_info *reflog_info, - const struct date_mode *dmode, int force_date, + struct date_mode dmode, int force_date, int shorten); int reflog_walk_empty(struct reflog_walk_info *walk); diff --git a/t/helper/test-date.c b/t/helper/test-date.c index 0683d46574..f25512de9a 100644 --- a/t/helper/test-date.c +++ b/t/helper/test-date.c @@ -52,7 +52,7 @@ static void show_dates(const char **argv, const char *format) arg++; tz = atoi(arg); - printf("%s -> %s\n", *argv, show_date(t, tz, &mode)); + printf("%s -> %s\n", *argv, show_date(t, tz, mode)); } date_mode_release(&mode); -- 2.44.0
On Fri, Apr 05, 2024 at 07:44:59PM +0200, René Scharfe wrote: > Am 02.04.24 um 22:41 schrieb Jeff King: > > > > I don't have a > > strong opinion on compound literals in general, but if we did allow > > them, we could clean up the horrible non-reentrant DATE_MODE(). > > We can easily make them reentrant without compound literals. It just > requires simple changes to lots of places. Patch below. > > --- >8 --- > Subject: [PATCH] date: make DATE_MODE thread-safe > > date_mode_from_type() modifies a static variable and returns a pointer > to it. This is not thread-safe. Most callers of date_mode_from_type() > use it via the macro DATE_MODE and pass its result on to functions like > show_date(), which take a const pointer and don't modify the struct. > > Avoid the static storage by putting the variable on the stack and > returning the whole struct date_mode. Change functions that take a > constant pointer to expect the whole struct instead. Yeah, this seems pretty reasonable. I think we've traditionally been hesitant to pass or return structs by value, but that's mostly superstition. IIRC it was illegal before C89, but that's long enough ago that we can presumably ignore it. -Peff
Jeff King <peff@peff.net> writes: > Yeah, this seems pretty reasonable. I think we've traditionally been > hesitant to pass or return structs by value, but that's mostly > superstition. We should still be hesitant against the practice to the same degree that we are hesitant against struct assignment, especially when the struct is of nontrivial size, or the struct has a pointer member whose memory ownership semantics goes against shallow copying of the struct. In this particular case, I do not know offhand if .strftime_fmt is safe to be shallowly copied, but I trust you two know and/or have already looked at the implications. Thanks.
Am 06.04.24 um 00:01 schrieb Junio C Hamano: > Jeff King <peff@peff.net> writes: > >> Yeah, this seems pretty reasonable. I think we've traditionally been >> hesitant to pass or return structs by value, but that's mostly >> superstition. > > We should still be hesitant against the practice to the same degree > that we are hesitant against struct assignment, especially when the > struct is of nontrivial size, or the struct has a pointer member > whose memory ownership semantics goes against shallow copying of the > struct. > > In this particular case, I do not know offhand if .strftime_fmt is > safe to be shallowly copied, but I trust you two know and/or have > already looked at the implications. date_mode_from_type() sets .strftime_fmt to NULL in the struct date_mode it creates and returns. Giving a reference to it to date_mode_release() is a safe NOOP. show_date() passes .strftime_fmt to strbuf_addftime() and does not retain a copy or change it. show_ident_date() only passes its struct date_mode parameter to show_date(). format_person_part() only passes its struct date_mode parameter to show_ident_date(). format_reflog_person() only passes its struct date_mode parameter to format_person_part(). get_reflog_selector() only passes its struct date_mode parameter to show_date(). show_reflog_message() only passes its struct date_mode parameter to get_reflog_selector(). The patch doesn't change any other function signatures. strbuf_addftime() scans the format string and passes it to strbuf_expand_step(), skip_prefix() and strftime(3). None of them change it or retain a copy of the pointer. In other words: This patch mostly affects the read-only side of struct date_mode handling, and the date_mode_from_type() part is benign as well. René
On Fri, Apr 05, 2024 at 03:01:44PM -0700, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > Yeah, this seems pretty reasonable. I think we've traditionally been > > hesitant to pass or return structs by value, but that's mostly > > superstition. > > We should still be hesitant against the practice to the same degree > that we are hesitant against struct assignment, especially when the > struct is of nontrivial size, or the struct has a pointer member > whose memory ownership semantics goes against shallow copying of the > struct. Good point. There are really two thresholds: is this something that should be totally forbidden, and is this something that is generally a good idea. I think the answers here are "no" and "yes" respectively. It is an OK solution for "plain old data" types like date_mode that are essentially just marshalling arguments, but not for more object-oriented code that might have ownership over pointers. > In this particular case, I do not know offhand if .strftime_fmt is > safe to be shallowly copied, but I trust you two know and/or have > already looked at the implications. René already went through each caller, but yeah, I think it is fine here. This whole thing is just a convenience over having callers pass around a separated (enum, strftime_fmt, local) triple. -Peff
Jeff King <peff@peff.net> writes: >> We should still be hesitant against the practice to the same degree >> that we are hesitant against struct assignment, especially when the >> struct is of nontrivial size, or the struct has a pointer member >> whose memory ownership semantics goes against shallow copying of the >> struct. > > Good point. There are really two thresholds: is this something that > should be totally forbidden, and is this something that is generally a > good idea. I think the answers here are "no" and "yes" respectively. I agree with your conclusion but I found the above a bit confusing. Between "totally horrible, do not even think about it" (0%) and "that is of course an excellent idea" (100%), you want to have two points "might have some merit but not acceptable" (33%) and something else that is less than "of course an excellent idea" but still acceptable (66%)? I would not phrase the last threshold "is generally a good idea", though. "It is not generally a good idea, but in this case, it is an adequate solution", maybe.
On Mon, Apr 08, 2024 at 09:57:41AM -0700, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > >> We should still be hesitant against the practice to the same degree > >> that we are hesitant against struct assignment, especially when the > >> struct is of nontrivial size, or the struct has a pointer member > >> whose memory ownership semantics goes against shallow copying of the > >> struct. > > > > Good point. There are really two thresholds: is this something that > > should be totally forbidden, and is this something that is generally a > > good idea. I think the answers here are "no" and "yes" respectively. > > I agree with your conclusion but I found the above a bit confusing. > > Between "totally horrible, do not even think about it" (0%) and > "that is of course an excellent idea" (100%), you want to have two > points "might have some merit but not acceptable" (33%) and > something else that is less than "of course an excellent idea" but > still acceptable (66%)? I would not phrase the last threshold "is > generally a good idea", though. "It is not generally a good idea, > but in this case, it is an adequate solution", maybe. Sorry, yes, I flipped the boolean on the second one. I should have said "is it forbidden" and "is it generally a bad idea", in which case the answers are "no" and "yes". Or if you prefer, as I stated it, the answers to both are "no". ;) I.e., it is OK to use here but it is not something we should be doing all the time. Sorry for the confusion. -Peff
On 2024.04.02 20:30, René Scharfe wrote: > Test names like "basic" are mentioned seven times in the code (ignoring > case): Twice when defining the input and result macros, thrice when > defining the test function, and twice again when calling it. Reduce > that to a single time by using compound literals to pass the input and > result arrays via TEST_INPUT to test_prio_queue(). > > Signed-off-by: René Scharfe <l.s.r@web.de> > --- > C99 added compound literals. Are we ready to use them? > > Test definitions become more compact, but look busier due to the added > punctuation. We could hide some of it with a sugary macro like this: > #define INT_ARRAY(...) ((int []){ __VA_ARGS__ }) I definitely like this approach. Reading the original test involved a lot of jumping around to see which TEST() checked which set of arguments, now they're all right there in the TEST() call. Agreed that an INT_ARRAY macro or similar would make it look a bit nicer, but even without that I think this is a good improvement. I am in favor of expanding our C99 usage, and ISTM that a unit test is a friendlier test balloon than production code (although perhaps one that is easier to miss).
diff --git a/t/unit-tests/t-prio-queue.c b/t/unit-tests/t-prio-queue.c index 5358346361..7a4e5780e1 100644 --- a/t/unit-tests/t-prio-queue.c +++ b/t/unit-tests/t-prio-queue.c @@ -66,43 +66,26 @@ static void test_prio_queue(int *input, size_t input_size, clear_prio_queue(&pq); } -#define BASIC_INPUT 2, 6, 3, 10, 9, 5, 7, 4, 5, 8, 1, DUMP -#define BASIC_RESULT 1, 2, 3, 4, 5, 5, 6, 7, 8, 9, 10 - -#define MIXED_PUT_GET_INPUT 6, 2, 4, GET, 5, 3, GET, GET, 1, DUMP -#define MIXED_PUT_GET_RESULT 2, 3, 4, 1, 5, 6 - -#define EMPTY_QUEUE_INPUT 1, 2, GET, GET, GET, 1, 2, GET, GET, GET -#define EMPTY_QUEUE_RESULT 1, 2, MISSING, 1, 2, MISSING - -#define STACK_INPUT STACK, 8, 1, 5, 4, 6, 2, 3, DUMP -#define STACK_RESULT 3, 2, 6, 4, 5, 1, 8 - -#define REVERSE_STACK_INPUT STACK, 1, 2, 3, 4, 5, 6, REVERSE, DUMP -#define REVERSE_STACK_RESULT 1, 2, 3, 4, 5, 6 - -#define TEST_INPUT(INPUT, RESULT, name) \ - static void test_##name(void) \ -{ \ - int input[] = {INPUT}; \ - int result[] = {RESULT}; \ - test_prio_queue(input, ARRAY_SIZE(input), \ - result, ARRAY_SIZE(result)); \ -} - -TEST_INPUT(BASIC_INPUT, BASIC_RESULT, basic) -TEST_INPUT(MIXED_PUT_GET_INPUT, MIXED_PUT_GET_RESULT, mixed) -TEST_INPUT(EMPTY_QUEUE_INPUT, EMPTY_QUEUE_RESULT, empty) -TEST_INPUT(STACK_INPUT, STACK_RESULT, stack) -TEST_INPUT(REVERSE_STACK_INPUT, REVERSE_STACK_RESULT, reverse) +#define TEST_INPUT(input, result) \ + test_prio_queue(input, ARRAY_SIZE(input), result, ARRAY_SIZE(result)) int cmd_main(int argc, const char **argv) { - TEST(test_basic(), "prio-queue works for basic input"); - TEST(test_mixed(), "prio-queue works for mixed put & get commands"); - TEST(test_empty(), "prio-queue works when queue is empty"); - TEST(test_stack(), "prio-queue works when used as a LIFO stack"); - TEST(test_reverse(), "prio-queue works when LIFO stack is reversed"); + TEST(TEST_INPUT(((int []){ 2, 6, 3, 10, 9, 5, 7, 4, 5, 8, 1, DUMP }), + ((int []){ 1, 2, 3, 4, 5, 5, 6, 7, 8, 9, 10 })), + "prio-queue works for basic input"); + TEST(TEST_INPUT(((int []){ 6, 2, 4, GET, 5, 3, GET, GET, 1, DUMP }), + ((int []){ 2, 3, 4, 1, 5, 6 })), + "prio-queue works for mixed put & get commands"); + TEST(TEST_INPUT(((int []){ 1, 2, GET, GET, GET, 1, 2, GET, GET, GET }), + ((int []){ 1, 2, MISSING, 1, 2, MISSING })), + "prio-queue works when queue is empty"); + TEST(TEST_INPUT(((int []){ STACK, 8, 1, 5, 4, 6, 2, 3, DUMP }), + ((int []){ 3, 2, 6, 4, 5, 1, 8 })), + "prio-queue works when used as a LIFO stack"); + TEST(TEST_INPUT(((int []){ STACK, 1, 2, 3, 4, 5, 6, REVERSE, DUMP }), + ((int []){ 1, 2, 3, 4, 5, 6 })), + "prio-queue works when LIFO stack is reversed"); return test_done(); }
Test names like "basic" are mentioned seven times in the code (ignoring case): Twice when defining the input and result macros, thrice when defining the test function, and twice again when calling it. Reduce that to a single time by using compound literals to pass the input and result arrays via TEST_INPUT to test_prio_queue(). Signed-off-by: René Scharfe <l.s.r@web.de> --- C99 added compound literals. Are we ready to use them? Test definitions become more compact, but look busier due to the added punctuation. We could hide some of it with a sugary macro like this: #define INT_ARRAY(...) ((int []){ __VA_ARGS__ }) t/unit-tests/t-prio-queue.c | 51 +++++++++++++------------------------ 1 file changed, 17 insertions(+), 34 deletions(-) -- 2.44.0