Duy Nguyen writes:
> I have a better plan: stop exposing parse-options loop to outside.
> What all these commands need is the ability to deal with unknown
> options (or non-options in update-index case). They could register
> callbacks to deal with those and keep calling parse_options() instead.
On Tue, Dec 11, 2018 at 3:13 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > The reason it's in parse_options_step() is because -h is also handled
> > in there. Although -h does not bury exit() deep in the call chain. So
> > how about this as a replacement?
>
> So just like -h returns PARSE
Duy Nguyen writes:
> The reason it's in parse_options_step() is because -h is also handled
> in there. Although -h does not bury exit() deep in the call chain. So
> how about this as a replacement?
So just like -h returns PARSE_OPT_HELP and causes the calling
parse_options() to exit(129), the ne
On Mon, Dec 10, 2018 at 03:36:54PM +0900, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > The compiler reports this because show_gitcomp() never actually
> > returns a value:
> >
> > "parse-options.c", line 520: warning: Function has no return
> > statement : show_gitcomp
> >
Nguyễn Thái Ngọc Duy writes:
> The compiler reports this because show_gitcomp() never actually
> returns a value:
>
> "parse-options.c", line 520: warning: Function has no return
> statement : show_gitcomp
>
> The function calls exit() and will never return. Update and mark it
> NORETURN
The compiler reports this because show_gitcomp() never actually
returns a value:
"parse-options.c", line 520: warning: Function has no return
statement : show_gitcomp
The function calls exit() and will never return. Update and mark it
NORETURN.
Reported-by: Ævar Arnfjörð Bjarmason
Signe
6 matches
Mail list logo
