This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][PATCH v8 06/16] Provide backward compatibility for strftime family (bug 10871).
- From: Rafal Luzynski <digitalfreak at lingonborough dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 28 Jun 2017 12:22:46 +0200 (CEST)
- Subject: Re: [RFC][PATCH v8 06/16] Provide backward compatibility for strftime family (bug 10871).
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org>
- Reply-to: Rafal Luzynski <digitalfreak at lingonborough dot com>
28.06.2017 12:10 Florian Weimer <email@example.com> wrote:
> On 06/28/2017 12:04 PM, Rafal Luzynski wrote:
> > As %OB format specifier has been added to strftime/wcsftime
> > family of functions backward compatibility implementation must be
> > provided for older binaries which assume that %B returns
> > a month name in the nominative case.
> I think this is a misuse of a compatibility symbols.
> Either the reinterpretation of %B is okay, and then it should apply to
> old binaries as well, or it is not, and then we should not do it and use
> %OB for the new variant (avoiding the backwards compatibility issue
I agree with that, especially I agree that the reinterpretation is okay
and should apply to old binaries as well. I already suggested that the
backward compatibility part should be skipped. I posted it only for
completeness, to avoid questions "where are the missing patches and please
post them" and because some people may have a different opinion.
> I still think that the reinterpretation %B is quite wrong, needlessly
> breaking backwards compatibility for most languages which benefit from
> the change, but I won't stay in the way of consensus on this matter.
Actually, most languages will not see any change at all. If you mean most
languages which benefit from the change I think that most of them will
also benefit from the reinterpretation in most of the applications. However,
I admit there will be a minority of applications and a minority (out of
the minority!) of languages where this will mean breaking the compatibility.
They will have to be fixed but since these are minorities the total sum
of changes will be smaller than the alternative solutions.
Also I keep in mind that this reinterpretation is the same as what BSD
family did about 20 years ago and what POSIX accepted as their future
> However, the compatibility symbol is wrong, and I'm sustaining my objection.
Again, I agree here.