Re: strftime updates

Jim Meyering wrote: > I suppose it's a good excuse for keeping the DO_MULTIBYTE code that > could otherwise be removed. Yes. And we never know what kinds of encodings will continue to be invented by people or governments... > Please push it. Done. Bruno

Re: strftime updates

Bruno Haible wrote: > How about the other small cleanups that I mentioned in > ? > Here is a proposed patch. The comment in glibc ("The GNU C Library uses UTF8 > multibyte encoding") is actually wrong, since glibc supports local

Re: strftime updates

Hi Jim, > > Also, the test for mempcpy is redundant since nothing uses it. Proposed > > patch: > > That looks fine, and you're welcome to apply it. Applied. How about the other small cleanups that I mentioned in ? Here is a

Re: strftime updates

Bruno Haible wrote: > Also, the test for mempcpy is redundant since nothing uses it. Proposed patch: That looks fine, and you're welcome to apply it. I'm generally in favor of clean-up changes in strftime.c, as long as they're not too invasive. Thinking of merge work, I see that there are some

Re: strftime updates (was: Conflicting types for mblen on Solaris 2.6)

Jim Meyering wrote: > Bottom line: now that we have mbrlen and mbsinit modules, > there's no point in testing HAVE_MBRLEN. > > diff --git a/lib/strftime.c b/lib/strftime.c > index 897aab7..3ade8cf 100644 > --- a/lib/strftime.c > +++ b/lib/strftime.c > @@ -50,14 +50,7 @@ extern char *tzname[]; > #