[PATCH v5 01/27] sequencer: use static initializers for replay_opts

This change is not completely faithful: instead of initializing all fields to 0, we choose to initialize command and subcommand to -1 (instead of defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically, it makes no difference at all, but future-proofs the code to require explicit

[PATCH v4 01/25] sequencer: use static initializers for replay_opts

This change is not completely faithful: instead of initializing all fields to 0, we choose to initialize command and subcommand to -1 (instead of defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically, it makes no difference at all, but future-proofs the code to require explicit

Re: [PATCH v3 01/25] sequencer: use static initializers for replay_opts

Johannes Schindelin writes: > This change is not completely faithful: instead of initializing all fields > to 0, we choose to initialize command and subcommand to -1 (instead of > defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically, > it makes no

[PATCH v3 01/25] sequencer: use static initializers for replay_opts

This change is not completely faithful: instead of initializing all fields to 0, we choose to initialize command and subcommand to -1 (instead of defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically, it makes no difference at all, but future-proofs the code to require explicit

Re: [PATCH v2 01/25] sequencer: use static initializers for replay_opts

Johannes Schindelin writes: > This change is not completely faithful: instead of initializing all fields > to 0, we choose to initialize command and subcommand to -1 (instead of > defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically, > it makes no

[PATCH v2 01/25] sequencer: use static initializers for replay_opts

This change is not completely faithful: instead of initializing all fields to 0, we choose to initialize command and subcommand to -1 (instead of defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically, it makes no difference at all, but future-proofs the code to require explicit

Re: [PATCH 01/22] sequencer: use static initializers for replay_opts

W dniu 29.08.2016 o 11:19, Dennis Kaarsemaker pisze: > On ma, 2016-08-29 at 10:03 +0200, Johannes Schindelin wrote: > >> +#define REPLAY_OPTS_INIT { -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, NULL, >> NULL, NULL, 0, 0, NULL } > > This looked off to me, as it replaces memset(..., 0, ...) so is not >

Re: [PATCH 01/22] sequencer: use static initializers for replay_opts

Hi Dennis, On Mon, 29 Aug 2016, Dennis Kaarsemaker wrote: > On ma, 2016-08-29 at 10:03 +0200, Johannes Schindelin wrote: > > > +#define REPLAY_OPTS_INIT { -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, NULL, > > NULL, NULL, 0, 0, NULL } > > This looked off to me, as it replaces memset(..., 0, ...) so

Re: [PATCH 01/22] sequencer: use static initializers for replay_opts

On ma, 2016-08-29 at 10:03 +0200, Johannes Schindelin wrote: > +#define REPLAY_OPTS_INIT { -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL, > NULL, 0, 0, NULL } This looked off to me, as it replaces memset(..., 0, ...) so is not 100% equivalent. But the changed functions both set opts.action

[PATCH 01/22] sequencer: use static initializers for replay_opts

Signed-off-by: Johannes Schindelin --- builtin/revert.c | 6 ++ sequencer.h | 1 + 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/builtin/revert.c b/builtin/revert.c index 4e69380..7365559 100644 --- a/builtin/revert.c +++ b/builtin/revert.c

static initializers

Howdy, Is there any policy on making static initializers thread-safe? I'm working on an experimental patch to introduce threading, but I'm running into a few non-thread-safe bits like this, in convert.c: static const char *conv_attr_name[] = { crlf, ident, filter, eol, text, }; #define

Re: [msysGit] Fwd: static initializers

On Mon, Jan 6, 2014 at 11:05 PM, Stefan Zager sza...@google.com wrote: Forwarding to msysgit for any guidance about win equivalents for PTHREAD_MUTEX_INITIALIZER or __attribute__((constructor)). As you've probably already guessed, PTHREAD_MUTEX_INITIALIZER isn't supported in our

IB/ehca: Lock renaming, static initializers

: Mon Jul 9 15:29:03 2007 +0200 Committer: Roland Dreier [EMAIL PROTECTED] CommitDate: Mon Jul 9 20:12:27 2007 -0700 IB/ehca: Lock renaming, static initializers - Rename all spinlock flags to flags, matching the vast majority of kernel code. - Move hcall_lock into the only file