From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13486 Path: news.gmane.org!.POSTED!not-for-mail From: Xan Phung Newsgroups: gmane.linux.lib.musl.general Subject: stdio glitch & questions Date: Fri, 30 Nov 2018 21:51:39 +1100 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000af67e7057bdf973a" X-Trace: blaine.gmane.org 1543575026 14297 195.159.176.226 (30 Nov 2018 10:50:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Nov 2018 10:50:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-13502-gllmg-musl=m.gmane.org@lists.openwall.com Fri Nov 30 11:50:22 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gSgNJ-0003bR-R3 for gllmg-musl@m.gmane.org; Fri, 30 Nov 2018 11:50:21 +0100 Original-Received: (qmail 26038 invoked by uid 550); 30 Nov 2018 10:52:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 26000 invoked from network); 30 Nov 2018 10:52:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9ppPFsUYFArFd5IJffVKpH5vRYx5ouMtmkK7wjzsN8Q=; b=ai/lrwDxd8YvJnSK5LG0NigX/4Vk/gaLPuDnxIdosd0qzdx6ZEKpTSaBR1rz9X91IP weVUpBG6Fd9AE5ozf3sq7k8BRKx654qruU4i0QTkPlC1IY/vuwK4BsaLBxWISI+qjTPA RmxA0vyc22Yo5EPphnUmbgvcP41EZZUn4uiiqDImEaePsdAIMcWzflFMQyqtFQZ6sZ2n vJ5yUr9wefyKs7JGSiRwdfHfRb9UlGOYjs1l5to3HChGNJe4MJGT4lhIjGFEvMSS6G/R s/hSTUvmuZi4sU9IuR/qIf12bmJ6hJRUPz4PSC8ENB8IuvHe0JtIDirb61gh/ysICLqz 2SUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9ppPFsUYFArFd5IJffVKpH5vRYx5ouMtmkK7wjzsN8Q=; b=ihvNpK7+QOECOvClzZX9cs0AoQ1wjsW1zVLFbNw2jwKESAecezzUo7z7LpbKp6WdFq iZBgJtkPJRU9/aG7s+edQ1VLZ4Cy0E1n/7XCjhtpWRlXc4R30cxcaKsLFGnhBzGSTysG UafpALEz4b7uZdWnXGk8DkcIl5yPfSXhAmpwzRLUETQRoOy9TlIxvlI/IwW+wYjI7EL7 hk4CCsBGqk/PnJZqfrTWAZSQ3sw7IgpQwJrNAn6+OWDxwptAiIvYCiPBHehuRuzrEPmo hP+npAsgpuAdWGEdauzzlrEI3OEIssKxi9q8witBrvV7GeQjAy0RzeIyy1+//AtOWEho hkLA== X-Gm-Message-State: AA+aEWaH137zNPsk+YdrW1l37YWSDhhoLgMtAAI5ksnRnjtwQySt+W46 a5MmZflFSCCmpv+13Ip+IQJyHjLr/Sccq5C+jQxnen6f X-Google-Smtp-Source: AFSGD/WcJU+SY1A+YVVzBLyfVi+5aTMl0PjsCgpaQN8FqamvtKQ1090pPRBDwVWv8l62HAhOEs4zl8+CHsyT48NMIO0= X-Received: by 2002:a9f:314c:: with SMTP id n12mr2297702uab.33.1543575136330; Fri, 30 Nov 2018 02:52:16 -0800 (PST) Xref: news.gmane.org gmane.linux.lib.musl.general:13486 Archived-At: --000000000000af67e7057bdf973a Content-Type: text/plain; charset="UTF-8" Hi, A few questions about stdio: (1) I notice __toread.c uses angular quotes for whereas all other source files use "stdio_impl.h". I assume the latter is correct and __toread.c's use of angular quotes was a glitch & it should really be double quotes... is that correct? (2) I notice vfprintf first tries to call printf_core with f=0 (line 667) then calls printf_core again with f set to the actual file to receive output (line 682). Why is printf_core called twice? I struggle to understand the purpose of the first call with f=0. (3) When I do a step thru the __fwritex function to understand how printf works, I notice the resulting writev system calls pass on the output data as a two element iovec array, with the 1st element comprising all line buffered text up to & including the last variable data item, and then the 2nd element comprising the residual format string trailing the last variable data item (more often than not just a single '\n'). For example, printf("error: %s\n", msg) would put all text up to & including %s text in first iovec and the second iovec contains only '\n'. I understand the rationale of this is to avoid copying the final '\n' to the buffer at f->wpos. (There is actually guaranteed space in the buffer itself due to a check at line 10 of fwrite.c). The use the array of 2x iovec's presumably then relies on Linux kernel scatter-gather I/O to then optimally handle the iovec array, ie: that the writev() of 2x iovec is more efficient than avoiding the copy of a few additional bytes (often a single '\n' byte) into f->wpos, and then using a single write() syscall. Isn't this a big assumption? With Linux itself, can we really know that Linux device drivers are smart enough to do writev() optimally? Also, there is a lot of interest in porting musl to non-Linux os's, many of which do not have writev(). (I am porting musl to WebAssembly and to Plan 9). I can prepare a patch of a version using write() instead of writev() if there is interest in this... regards Xan Phung --000000000000af67e7057bdf973a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

A few questions ab= out stdio:

(1) I notice __toread.c uses angular qu= otes for <stdio_impl.h> whereas all other source files use "stdi= o_impl.h".=C2=A0 I assume the latter is correct and __toread.c's u= se of angular quotes was a glitch & it should really be double quotes..= . is that correct?

(2) I notice vfprintf first tri= es to call printf_core with f=3D0 (line 667) then calls printf_core again w= ith f set to the actual file to receive output (line 682).=C2=A0 Why is pri= ntf_core called twice?=C2=A0 I struggle to understand the purpose of the fi= rst call with f=3D0.

(3) When I do a step thru the= __fwritex function to understand how printf works, I notice the resulting = writev system calls pass on the output data as a two element iovec array, w= ith the 1st element comprising all line buffered text up to & including= the last variable data item, and then the 2nd element comprising the resid= ual format string trailing the last variable data item (more often than not= just a single '\n').

For example, printf(= "error: %s\n", msg) would put all text up to & including %s t= ext in first iovec and the second iovec contains only '\n'.=C2=A0 I= understand the rationale of this is to avoid copying the final '\n'= ; to the buffer at f->wpos.=C2=A0 (There is actually guaranteed space in= the buffer itself due to a check at line 10 of fwrite.c).=C2=A0 The use th= e array of 2x iovec's presumably then relies on Linux kernel scatter-ga= ther I/O to then optimally handle the iovec array, ie: that the writev() of= 2x iovec is more efficient than avoiding the copy of a few additional byte= s (often a single '\n' byte) into f->wpos, and then using a sing= le write() syscall.

Isn't this a big assumptio= n?=C2=A0 With Linux itself, can we really know that Linux device drivers ar= e smart enough to do writev() optimally?=C2=A0 Also, there is a lot of inte= rest in porting musl to non-Linux os's, many of which do not have write= v().=C2=A0 (I am porting musl to WebAssembly and to Plan 9).

=
I can prepare a patch of a version using write() instead of writ= ev() if there is interest in this...

regards
=
Xan Phung


--000000000000af67e7057bdf973a--