On Mon, 21 Dec 2015 09:45:25 +0100
"e_AT_bestmx.net" <e_AT_bestmx.net> wrote:
> > Now, what you did here is rip out this status code handling
>
> No, i didn't
My bad, I shouldn't look only at the diffs, might be confusing.
> > In sbase, we have this more or less "scheme" how function naming
> > works.
>
> how is it relevant to the topic?
venprintf is giving a false impression, because it neither exists now
nor does it take a status code as an argument.
I reworked eprintf.c to get rid of the duplicate code:
http://git.2f30.org/sbase/tree/libutil/eprintf.c
After further thoughts, I think we should keep this "usage"-check in.
Not only are we talking about error-functions here, we also already
apply a heuristic when the format-string ends with ':' to also print
the error-string afterwards.
I have got the feeling that if we go forward and start splitting up
eprintf into its individual subfunctionalities, we might as well
just write "fprintf(stderr, ...); exit(status)" everywhere in the
code, but we don't want that.
Also, who do you expect to add eprintu everywhere? I didn't see that
in your patch.
Additionally, next time, please take care of trailing whitespace.
If you miss it, highlight it in vim by adding to .vimrc:
highlight ExtraWhitespace ctermbg=red guibg=red
match ExtraWhitespace /\s\+$/
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Mon Dec 21 2015 - 10:10:35 CET