> Please disregard my concern about consistency, I was missing something,
> not you
Sorry if it came out as out of place. I just feel like starting to
introduce the macro
in places where the function name is outright wrong might be a good idea,
if the function was changed once it makes sense that it might be changed
Then, the macro usage would mitigate another potential error/source of
Ultimately, I'm not going to go around changing stuff unless I see
something like this
by accident so it's not my decision to make at all. I don't think
introducing this diff
would do any harm though.
On Tue, Mar 13, 2018 at 2:44 PM, Klemens Nanni <k...@openbsd.org> wrote:
> On Tue, Mar 13, 2018 at 12:33:36PM +0100, Klemens Nanni wrote:
> > On Tue, Mar 13, 2018 at 04:39:16PM +0800, Michael W. Bombardieri wrote:
> > > Some errors and warnings printed by ksh have the function name
> > > prefixed. __func__ could be used here instead of hard-coding
> > > the name. The names are wrong for tty_init(), j_set_async(),
> > > j_change(), x_file_glob() and c_ulimit() afaics.
> > Wrong error messages should definitely be corrected, although I'd either
> > fix them literally or use __func__ consistently. This diff would
> > introduce the macro for only a handful of functions while leaving the
> > vast majority names untouched.
> > Not sure if touching all error messages for __func__ is worth it or just
> > too much churn in the end.
> Please disregard my concern about consistency, I was missing someting,
> not you.