Re: fscanf and locale awareness

[Rik]

On 02/17/2012 04:58 AM, address@hidden wrote:
> Message: 5
> Date: Thu, 16 Feb 2012 21:06:12 -0500
> From: Jordi Guti?rrez Hermoso <address@hidden>
> To: CdeMills <address@hidden>
> Cc: address@hidden
> Subject: Re: F[fs]scanf: if requested, make it locale aware
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> On 5 February 2012 10:10, CdeMills <address@hidden> wrote:
>> > Hello,
>> >
>> > herewith enclosed a new version of my patch trying to add locale support in
>> > F[fs]scanf. The main differences are
>> > - it must be enabled by the "--use-localized-scanf' switch in configure
>> > - it not enabled, it won't produce any warning, error or test failure.
>> >
>> > Regards
> I was about to push this patch, but I noticed that you did it relative
> to an old version instead of incrementally relative to the changes
> that already exist in Savannah.
>
> I also noticed that your commit message isn't following our
> convention. We haven't really agreed on the proper way to do this, I
> guess, and we're still figuring out the rules to do this, but roughly,
> you should describe in broad terms the changes on each file and
> function, according to this example:
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/3e4350f09a55
>
> It's really supposed to be GNU style, described here:
>
> http://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
>
> except we have to sort of adapt them to hg and C++.
>
> I'm also hesitant to push this patch because jwe seems to be vetoing
> it... I think it's a good way to do things, but I don't want to push a
> patch that jwe doesn't like.
>
> - Jordi G. H.
2/18/12

Jordi,

One argument in its favor is that the current behavior is broken.  Right now there are a lot of users who report a failing test on the development branch because one of the %!tests depends on having the fr_FR locale installed.  See this bug report (https://savannah.gnu.org/bugs/?35364).  At least by applying the patch this would go away because the code would only be enabled by a configure option which should default to "off".  The other choice would be to remove the original changeset entirely (14210:238e499c5fea).

If the patch is to be applied, though, I agree that it needs to be rebased to reflect the current source tree.  I have corrected a spelling mistake (14365:a598273c9c3d) and a set of unbalanced parentheses (14374:d31156b96abe) in the docstring and I don't want those problems to re-appear.

--Rik