delta/git.git/usage.c, branch sk/gitweb-highlight-encoding

Merge branch 'jk/a-thread-only-dies-once'

2013-04-19T20:45:05+00:00

A regression fix for the logic to detect die() handler triggering
itself recursively.

* jk/a-thread-only-dies-once:
  run-command: use thread-aware die_is_recursing routine
  usage: allow pluggable die-recursion checks

usage: allow pluggable die-recursion checks

2013-04-16T22:02:46+00:00

When any git code calls die or die_errno, we use a counter
to detect recursion into the die functions from any of the
helper functions. However, such a simple counter is not good
enough for threaded programs, which may call die from a
sub-thread, killing only the sub-thread (but incrementing
the counter for everyone).

Rather than try to deal with threads ourselves here, let's
just allow callers to plug in their own recursion-detection
function. This is similar to how we handle the die routine
(the caller plugs in a die routine which may kill only the
sub-thread).

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

make error()'s constant return value more visible

2012-12-15T18:45:58+00:00

When git is compiled with "gcc -Wuninitialized -O3", some
inlined calls provide an additional opportunity for the
compiler to do static analysis on variable initialization.
For example, with two functions like this:

  int get_foo(int *foo)
  {
	if (something_that_might_fail() < 0)
		return error("unable to get foo");
	*foo = 0;
	return 0;
  }

  void some_fun(void)
  {
	  int foo;
	  if (get_foo(&foo) < 0)
		  return -1;
	  printf("foo is %d\n", foo);
  }

If get_foo() is not inlined, then when compiling some_fun,
gcc sees only that a pointer to the local variable is
passed, and must assume that it is an out parameter that
is initialized after get_foo returns.

However, when get_foo() is inlined, the compiler may look at
all of the code together and see that some code paths in
get_foo() do not initialize the variable. As a result, it
prints a warning. But what the compiler can't see is that
error() always returns -1, and therefore we know that either
we return early from some_fun, or foo ends up initialized,
and the code is safe.  The warning is a false positive.

If we can make the compiler aware that error() will always
return -1, it can do a better job of analysis. The simplest
method would be to inline the error() function. However,
this doesn't work, because gcc will not inline a variadc
function. We can work around this by defining a macro. This
relies on two gcc extensions:

  1. Variadic macros (these are present in C99, but we do
     not rely on that).

  2. Gcc treats the "##" paste operator specially between a
     comma and __VA_ARGS__, which lets our variadic macro
     work even if no format parameters are passed to
     error().

Since we are using these extra features, we hide the macro
behind an #ifdef. This is OK, though, because our goal was
just to help gcc.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

usage.c: detect recursion in die routines and bail out immediately

2012-11-16T02:04:54+00:00

It is theoretically possible for a die handler to get into a state of
infinite recursion.  For example, if a die handler called another function
which itself called die().  Let's at least detect this situation, inform the
user, and call exit.

Signed-off-by: Brandon Casey 
Signed-off-by: Junio C Hamano

error_routine: use parent's stderr if exec fails

2011-08-01T01:27:07+00:00

The new process's error output may be redirected elsewhere, but if
the exec fails, output should still go to the parent's stderr. This
has already been done for the die_routine. Do the same for
error_routine.

Signed-off-by: Clemens Buchacher 
Signed-off-by: Junio C Hamano

Fix sparse warnings

2011-03-22T17:16:54+00:00

Fix warnings from 'make check'.

 - These files don't include 'builtin.h' causing sparse to complain that
   cmd_* isn't declared:

   builtin/clone.c:364, builtin/fetch-pack.c:797,
   builtin/fmt-merge-msg.c:34, builtin/hash-object.c:78,
   builtin/merge-index.c:69, builtin/merge-recursive.c:22
   builtin/merge-tree.c:341, builtin/mktag.c:156, builtin/notes.c:426
   builtin/notes.c:822, builtin/pack-redundant.c:596,
   builtin/pack-refs.c:10, builtin/patch-id.c:60, builtin/patch-id.c:149,
   builtin/remote.c:1512, builtin/remote-ext.c:240,
   builtin/remote-fd.c:53, builtin/reset.c:236, builtin/send-pack.c:384,
   builtin/unpack-file.c:25, builtin/var.c:75

 - These files have symbols which should be marked static since they're
   only file scope:

   submodule.c:12, diff.c:631, replace_object.c:92, submodule.c:13,
   submodule.c:14, trace.c:78, transport.c:195, transport-helper.c:79,
   unpack-trees.c:19, url.c:3, url.c:18, url.c:104, url.c:117, url.c:123,
   url.c:129, url.c:136, thread-utils.c:21, thread-utils.c:48

 - These files redeclare symbols to be different types:

   builtin/index-pack.c:210, parse-options.c:564, parse-options.c:571,
   usage.c:49, usage.c:58, usage.c:63, usage.c:72

 - These files use a literal integer 0 when they really should use a NULL
   pointer:

   daemon.c:663, fast-import.c:2942, imap-send.c:1072, notes-merge.c:362

While we're in the area, clean up some unused #includes in builtin files
(mostly exec_cmd.h).

Signed-off-by: Stephen Boyd 
Signed-off-by: Junio C Hamano

Make report() from usage.c public as vreportf() and use it.

2010-03-07T08:37:35+00:00

There exist already a number of static functions named 'report', therefore,
the function name was changed.

Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano

Fix truncated usage messages

2009-11-23T00:14:48+00:00

The usage messages for some commands (such as 'git diff-tree')
are truncated because they don't fit in a fixed buffer of
1024 bytes.

It would be tempting to eliminate the buffer and the problem once
and for all by doing the output in three steps, but doing so could
(according to commit d048a96e) increase the likelyhood of messing
up the display.

So we just increase the size of the buffer.

Signed-off-by: Björn Gustavsson 
Signed-off-by: Junio C Hamano

Introduce usagef() that takes a printf-style format

2009-11-10T20:00:21+00:00

Some new callers would want to use printf-like formatting, when issuing
their usage messages.  An option is to change usage() itself also be like
printf(), which would make it similar to die() and warn().

But usage() is typically fixed, as opposed to die() and warn() that gives
diagnostics depending on the situation.  Indeed, the majority of strings
given by existing callsites to usage() are fixed strings.  If we were to
make usage() take printf-style format, they all need to be changed to have
"%s" as their first argument.

So instead, introduce usagef() so that limited number of callers can use
it.

Signed-off-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

add NORETURN_PTR for function pointers

2009-10-01T08:12:21+00:00

Some compilers (including at least MSVC and ARM RVDS) supports
NORETURN on function declarations, but not on function pointers.

This patch makes it possible to define NORETURN for these compilers,
by splitting the NORETURN macro into two - one for function
declarations and one for function pointers.

Signed-off-by: Erik Faye-Lund 
Signed-off-by: Jeff King