Re: musl 1.1.13 released

[Rich Felker <dalias@libc.org>]

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

On Mon, Feb 15, 2016 at 11:35:28PM -0500, Rich Felker wrote:
> This release adds support for out-of-tree builds, search domains in
> resolv.conf, VDSO-accelerated clock_gettime on MIPS, and building
> SMP-safe/ready SH binaries for the open-hardware J2. Performance of
> atomics and synchronization primitives has been greatly improved on
> most "ll/sc model" RISC archs. Regex BRE now supports the widely-used
> extensions \|, \+, and \? and larger regular expressions are now
> supported. A number of minor application and toolchain compatibility
> improvements have also been made, including changes which reduce the
> risk of assembler and linker bugs leading to malfunctioning binaries.
> 
> Two potentially dangerous bugs have been fixed: a single-byte heap
> overflow in getdelim and a pointer indexing error in dynamic TLS
> allocation. Other bugs fixed include various issues in parsing and
> error handling for resolv.conf and related files, incorrect error
> return values for some functions, and failures to accept null pointer
> arguments in some functions for which they have defined behavior. Some
> arch-specific bugs affecting ARM, MIPS, and SH/FDPIC have also been
> fixed.
> 
> http://www.musl-libc.org/releases/musl-1.1.13.tar.gz
> http://www.musl-libc.org/releases/musl-1.1.13.tar.gz.asc

It's been found that this release has a fairly significant regression
caused by fixing a bug in fwrite's return value. Users should apply
the attached patch to avoid problems with puts("") and fputs("",f)
malfunctioning.

Rich

[-- Attachment #2: 0001-fix-assumption-in-fputs-that-fwrite-returning-0-impl.patch --]
[-- Type: text/plain, Size: 1136 bytes --]

From 10a17dfbad2c267d885817abc9c7589fc7ff630b Mon Sep 17 00:00:00 2001
From: Rich Felker <dalias@aerifal.cx>
Date: Tue, 16 Feb 2016 13:26:16 -0500
Subject: [PATCH] fix assumption in fputs that fwrite returning 0 implies an
 error

internally, the idiom of passing nmemb=1 to fwrite and interpreting
the return value of fwrite (which is necessarily 0 or 1) as
failure/success is fairly widely used. this is not correct, however,
when the size argument is unknown and may be zero, since C requires
fwrite to return 0 in that special case. previously fwrite always
returned nmemb on success, but this was changed for conformance with
ISO C by commit 500c6886c654fd45e4926990fee2c61d816be197.
---
 src/stdio/fputs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/stdio/fputs.c b/src/stdio/fputs.c
index 4737f44..1cf344f 100644
--- a/src/stdio/fputs.c
+++ b/src/stdio/fputs.c
@@ -3,7 +3,8 @@
 
 int fputs(const char *restrict s, FILE *restrict f)
 {
-	return (int)fwrite(s, strlen(s), 1, f) - 1;
+	size_t l = strlen(s);
+	return (fwrite(s, 1, l, f)==l) - 1;
 }
 
 weak_alias(fputs, fputs_unlocked);
-- 
1.8.1.rc1