Wrong wcsnrtombs return value and positive NaNs printing

Wrong wcsnrtombs return value and positive NaNs printing

[Oleg Ranevskyy]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

Hello musl community,

I encountered two problems with musl when running the LLVM libc++ tests
linked against it.

1. The wcsnrtombs function returns the number of converted wide chars
instead of the dst length in bytes. "cnt++;" at the of the function should
actually be "cnt += l;".

2. If a NaN value is printed by vfprintf and the MARK_POS flag is set to
add '+' to positive values, musl doesn't add '+'. I found the following
statement on the musl web page: "Quiet nans are treated equally (there is
only one logical nan value, it is printed as "nan", the library does not
care about the sign and payload of nan)". However, Linux libc adds '+',
boost also has special support for this. Absence of the sign breaks one of
the LLVM libc++ tests. Is this a subject for change?

Would you be able to kindly review these findings and share your opinion
please?

Thanks in advance.
Warm regards,
Oleg

[-- Attachment #2: Type: text/html, Size: 1236 bytes --]

Re: Wrong wcsnrtombs return value and positive NaNs printing

[Rich Felker]

On Thu, Dec 18, 2014 at 08:20:00PM +0300, Oleg Ranevskyy wrote:
> Hello musl community,
> 
> I encountered two problems with musl when running the LLVM libc++ tests
> linked against it.
> 
> 1. The wcsnrtombs function returns the number of converted wide chars
> instead of the dst length in bytes. "cnt++;" at the of the function should
> actually be "cnt += l;".

This looks like you're correct, especially considering it's cnt+=l in
the first loop. I'll recheck it and fix if I confirm. Thanks.

> 2. If a NaN value is printed by vfprintf and the MARK_POS flag is set to
> add '+' to positive values, musl doesn't add '+'. I found the following
> statement on the musl web page: "Quiet nans are treated equally (there is
> only one logical nan value, it is printed as "nan", the library does not
> care about the sign and payload of nan)". However, Linux libc adds '+',
> boost also has special support for this. Absence of the sign breaks one of
> the LLVM libc++ tests. Is this a subject for change?

Based on my reading of the spec I think you're right that it should be
there. I can fix this.

Rich

Re: Wrong wcsnrtombs return value and positive NaNs printing

[Rich Felker]

On Thu, Dec 18, 2014 at 02:12:52PM -0500, Rich Felker wrote:
> On Thu, Dec 18, 2014 at 08:20:00PM +0300, Oleg Ranevskyy wrote:
> > Hello musl community,
> > 
> > I encountered two problems with musl when running the LLVM libc++ tests
> > linked against it.
> > 
> > 1. The wcsnrtombs function returns the number of converted wide chars
> > instead of the dst length in bytes. "cnt++;" at the of the function should
> > actually be "cnt += l;".
> 
> This looks like you're correct, especially considering it's cnt+=l in
> the first loop. I'll recheck it and fix if I confirm. Thanks.

Fixed.

> > 2. If a NaN value is printed by vfprintf and the MARK_POS flag is set to
> > add '+' to positive values, musl doesn't add '+'. I found the following
> > statement on the musl web page: "Quiet nans are treated equally (there is
> > only one logical nan value, it is printed as "nan", the library does not
> > care about the sign and payload of nan)". However, Linux libc adds '+',
> > boost also has special support for this. Absence of the sign breaks one of
> > the LLVM libc++ tests. Is this a subject for change?
> 
> Based on my reading of the spec I think you're right that it should be
> there. I can fix this.

Fixed.

Rich

Re: Wrong wcsnrtombs return value and positive NaNs printing

[Szabolcs Nagy]

* Oleg Ranevskyy <llvm.mail.list@gmail.com> [2014-12-18 20:20:00 +0300]:
> I encountered two problems with musl when running the LLVM libc++ tests
> linked against it.
> 
> 1. The wcsnrtombs function returns the number of converted wide chars
> instead of the dst length in bytes. "cnt++;" at the of the function should
> actually be "cnt += l;".
> 

seems like a bug, yes

> 2. If a NaN value is printed by vfprintf and the MARK_POS flag is set to
> add '+' to positive values, musl doesn't add '+'. I found the following
> statement on the musl web page: "Quiet nans are treated equally (there is
> only one logical nan value, it is printed as "nan", the library does not
> care about the sign and payload of nan)". However, Linux libc adds '+',
> boost also has special support for this. Absence of the sign breaks one of
> the LLVM libc++ tests. Is this a subject for change?
> 

this is a bug, the printf spec requires the sign printed even for nan
(it will be always + in musl i guess)