> 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, since if the function was changed once it makes sense that it might be changed again. Then, the macro usage would mitigate another potential error/source of confusion. 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. > > -- Best Regards, Bobby