On Mon, 21 Dec 2015 09:45:25 +0100 "e...@bestmx.net" <e...@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 <d...@frign.de>
