git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "René Scharfe" <l.s.r@web.de>
Cc: Git List <git@vger.kernel.org>,
	Chandra Pratap <chandrapratap3519@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [RFC][PATCH] t-prio-queue: simplify using compound literals
Date: Fri, 5 Apr 2024 15:17:14 -0400	[thread overview]
Message-ID: <20240405191714.GA2561807@coredump.intra.peff.net> (raw)
In-Reply-To: <c6cb255a-72f0-4ac2-81a2-1d8e95570a81@web.de>

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


  reply	other threads:[~2024-04-05 19:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02 18:30 [RFC][PATCH] t-prio-queue: simplify using compound literals René Scharfe
2024-04-02 20:31 ` Junio C Hamano
2024-04-02 20:41 ` Jeff King
2024-04-05 17:44   ` René Scharfe
2024-04-05 19:17     ` Jeff King [this message]
2024-04-05 22:01       ` Junio C Hamano
2024-04-06  7:06         ` René Scharfe
2024-04-07  1:28         ` Jeff King
2024-04-08 16:57           ` Junio C Hamano
2024-04-08 17:09             ` Jeff King
2024-04-11 21:23 ` Josh Steadmon

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=20240405191714.GA2561807@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=chandrapratap3519@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    /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).