From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8619 Path: news.gmane.org!not-for-mail From: Maxim Storchak Newsgroups: gmane.linux.lib.musl.general Subject: open_memstream corner case Date: Tue, 6 Oct 2015 16:52:58 +0300 Message-ID: <5613D23A.3010707@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1444139617 24077 80.91.229.3 (6 Oct 2015 13:53:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Oct 2015 13:53:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8631-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 06 15:53:37 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZjSgO-0000Fe-5D for gllmg-musl@m.gmane.org; Tue, 06 Oct 2015 15:53:32 +0200 Original-Received: (qmail 17762 invoked by uid 550); 6 Oct 2015 13:53:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17628 invoked from network); 6 Oct 2015 13:53:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=8rlb6b3/eptK4ySMGa8kX9U7UA1v53rL8iGvoqtAqPE=; b=Rp7Ag12VQ8OBI54zwqFyxPeqjhh0MwZR/xFeoobt3Jz8mzqhFQAbca9VghfYpPPttx A8rMPkvWyq+7uPVkizxPmCpN8wgckOBIv4bQtlAYHxhzFqB6Um3OkeReAsxHi1AAO+6f sYQshTtpXMOu5zlvJ7sQGjXmXt29waXKq68t8cXoiaMJGuo/kIl2+bvaNupSTCRMEwni ReBOLc9up+PRjVZ+YJk+DAWYFrizv+7hqU5j06AbMKkMNMx48C5vM4q56r6+Z22r33Rh 3NNTgOiVjJMqzLWXCFaNx4Hf3isVZVaaNMZDjy4zzf/sr1Fh29MCZN+IrC21wuq3uTT1 mRGA== X-Received: by 10.112.131.8 with SMTP id oi8mr11323703lbb.99.1444139580186; Tue, 06 Oct 2015 06:53:00 -0700 (PDT) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 Xref: news.gmane.org gmane.linux.lib.musl.general:8619 Archived-At: Hi, I discovered something strange with memstream subsystem in musl: if a stream is opened for writing with open_memstream(3) but then closed without writing anything, neither buffer pointer, nor buffer size gets updated. I compared source code of glibc, uClibc and musl and discovered that both uClibc and musl update buffer size on write, while glibc does that on fclose or fsync, both of which is fine, according to memstream(3) man page. While both uClibc and musl behave the same if something is written to the buffer, they differ if no write happens. On initialization uClibc sets buffer size to 0, and musl leaves it intact. In case of no write it doesn't get updated and contains garbage. Here is my test case: #include #include int main() { FILE *f; size_t size=-42; /* garbage */ char *buf="garbage"; printf("Initially: size=%ld, buf=%s\n", size, buf); if ( (f=open_memstream(&buf, &size)) == NULL ) { perror("open_memstream"); exit(0); } fclose(f); printf("After writing nothing to buffer: size=%ld, buf=%s\n", size, buf); if ( (f=open_memstream(&buf, &size)) == NULL ) { perror("open_memstream"); exit(0); } fprintf(f, "something completely different"); fclose(f); printf("After writing something to buffer: size=%ld, buf=%s\n", size, buf); exit(0); } musl: Initially: size=-42, buf=garbage After writing nothing to buffer: size=-42, buf=garbage After writing something to buffer: size=30, buf=something completely different glibc: Initially: size=-42, buf=garbage After writing nothing to buffer: size=0, buf= After writing something to buffer: size=30, buf=something completely different (I'm sorry for providing no example for uClibc, but the program where I found that use case used to work with uClibc but not musl). Could anyone please comment if where's a bug in musl or in my test case? -- Best regards, Maxim Storchak mailto:m.storchak@gmail.com