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
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
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
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
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
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
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
>
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
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
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
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
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
: 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
13 matches
Mail list logo