At Tue, 12 Oct 2021 13:25:01 +0900, Fujii Masao <masao.fu...@oss.nttdata.com> wrote in > > > On 2021/10/07 11:46, kuroda.hay...@fujitsu.com wrote: > > So now we can choose from followings: > >* ignore such differences and use isdigit() and strtol() > > * give up using them and implement two static support functions > >How do you think? Someone knows any other knowledge about locale? > > Replacing process_log_prefix_padding() with isdigit()+strtol() is > just refactoring and doesn't provide any new feature. So they > basically should work in the same way. If the behavior of > isdigit()+strtol() > can be different from process_log_prefix_padding(), I'd prefer to > the latter option you suggested, i.e., give up using > isdigit()+strtol(). > > OTOH, of course if the behaviors of them are the same, > I'm ok to use isdigit()+strtol(), though.
Hmm. It look like behaving a bit xdifferently. At least for example, for "%-X", current code treats it as 0 padding but the patch treats it as -1. By the way, the current code is already a kind of buggy. I think I showed an example like: "%4%5%6%7p" is converted to "57p". Do we need to imitate that bug with this patch? regards. -- Kyotaro Horiguchi NTT Open Source Software Center