All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "René Scharfe" <l.s.r@web.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/11] renaming argv_array
Date: Wed, 12 Aug 2020 11:06:11 -0400	[thread overview]
Message-ID: <20200812150611.GA33189@coredump.intra.peff.net> (raw)
In-Reply-To: <82991f30-fe37-d6d2-ffd5-8b0878f46c83@web.de>

On Tue, Aug 11, 2020 at 06:08:22PM +0200, René Scharfe wrote:

> > This has bugged me for a while, so I decided to finally fix it. It
> > wasn't _too_ painful, though I'm sure there will be a little fallout
> > with topics in flight.
> 
> Just as this landed in master now, https://lobste.rs/ decided to link to
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2493.pdf, which is a
> paper about reserved identifiers in C.  It contains a nice overview.
> 
> Anyway, 7.31 of C11 says: "All external names described below are
> reserved no matter what headers are included by the program."  And
> 7.31.13 goes on: "Function names that begin with str, mem, or wcs and a
> lowercase letter may be added to the declarations in the <string.h>
> header."  So the names of the strvec functions are reserved.

It was the same in C99. I think this is one of those cases where we need
to worry less about what the standard says and more about what the real
world does. As long as we're ready for C25 or whatever to add "strvec"
and we accept that we'll need to change the name then, I'm not
particularly concerned. A compiler that starts warning about "str"
functions in the meantime would be impractical I think (forget strbuf,
stuff like strip_extension() would be illegal).

> Also how about using Coccinelle and patience to reduce the impact of
> such a change next time?  I.e. adding the new thing, providing a
> semantic patch for converting old code, waiting a reasonable amount of
> time after the last conversion was necessary and then removing the
> old thing.

So I almost sent a rant about Coccinelle along with this series. :)

Debian unstable now ships coccinelle 1.0.8, and it's unbelievably slow
compared to 1.0.4. Running "make coccicheck" is currently at 80 minutes
of CPU time running each script in parallel, with none of them down.
They're also all consuming 6GB of RAM each, so I'm killing them all.

I got somewhere similar when I was working on this series, got fed up,
and then just did the whole thing with grep, which was easier. I'm open
to the idea that a slower transition might have helped topics in flight
catch up, but it also would have prolonged the pain. So I dunno.

-Peff

  parent reply	other threads:[~2020-08-12 15:06 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 20:21 Jeff King
2020-07-28 20:21 ` [PATCH 01/11] argv-array: use size_t for count and alloc Jeff King
2020-07-28 20:23 ` [PATCH 02/11] argv-array: rename to strvec Jeff King
2020-07-28 20:23 ` [PATCH 03/11] strvec: rename files from argv-array " Jeff King
2020-07-28 20:24 ` [PATCH 04/11] quote: rename sq_dequote_to_argv_array to mention strvec Jeff King
2020-07-28 20:24 ` [PATCH 05/11] strvec: convert builtin/ callers away from argv_array name Jeff King
2020-07-28 20:24 ` [PATCH 06/11] strvec: convert more " Jeff King
2020-07-28 20:25 ` [PATCH 07/11] strvec: convert remaining " Jeff King
2020-07-28 20:26 ` [PATCH 08/11] strvec: fix indentation in renamed calls Jeff King
2020-07-28 22:43   ` Jacob Keller
2020-07-28 23:31     ` Junio C Hamano
2020-07-28 20:26 ` [PATCH 09/11] strvec: update documention to avoid argv_array Jeff King
2020-07-28 20:27 ` [PATCH 10/11] strvec: drop argv_array compatibility layer Jeff King
2020-07-28 22:23   ` Junio C Hamano
2020-07-29  0:04     ` Jeff King
2020-07-29  0:37       ` Jeff King
2020-07-29  0:40         ` Jeff King
2020-07-29  0:47           ` Junio C Hamano
2020-07-29 16:54             ` Derrick Stolee
2020-07-29  0:44         ` Junio C Hamano
2020-07-29 16:22           ` Jeff King
2020-07-28 20:28 ` [PATCH 11/11] strvec: rename struct fields Jeff King
2020-07-28 21:16   ` Junio C Hamano
2020-07-28 21:18     ` Junio C Hamano
2020-07-29  6:55       ` Christian Couder
2020-07-29 16:34         ` Jeff King
2020-07-29 18:03           ` Junio C Hamano
2020-07-28 21:20     ` Jeff King
2020-07-28 22:45 ` [PATCH 0/11] renaming argv_array Jacob Keller
2020-07-29  0:06   ` Jeff King
2020-07-29  6:15 ` Christian Couder
2020-07-29  6:19   ` Christian Couder
2020-07-29 13:32   ` Eric Sunshine
2020-07-29 16:33   ` Jeff King
2020-08-11 16:08 ` René Scharfe
2020-08-11 18:28   ` Taylor Blau
2020-08-11 19:00   ` Junio C Hamano
2020-08-11 20:39     ` Jacob Keller
2020-08-11 21:03       ` Junio C Hamano
2020-08-12 12:42     ` Johannes Schindelin
2020-08-12 15:06   ` Jeff King [this message]
2020-08-12 15:10     ` Jeff King
2020-08-12 16:23       ` René Scharfe
2020-08-12 17:08         ` Jeff King
2020-08-12 18:18           ` René Scharfe
2020-08-12 19:57             ` 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=20200812150611.GA33189@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --subject='Re: [PATCH 0/11] renaming argv_array' \
    /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

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.