From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9300 Path: news.gmane.org!not-for-mail From: Max Ruttenberg Newsgroups: gmane.linux.lib.musl.general Subject: Re: Enforcing expected ordering of operations on stdout, stdin, and stderr Date: Wed, 10 Feb 2016 18:08:47 -0500 Message-ID: References: <1455141901.26335.95.camel@zhasha.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c301dc29e148052b72845e X-Trace: ger.gmane.org 1455145743 12061 80.91.229.3 (10 Feb 2016 23:09:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Feb 2016 23:09:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9313-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 11 00:09:03 2016 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 1aTdsc-0003GB-MV for gllmg-musl@m.gmane.org; Thu, 11 Feb 2016 00:09:02 +0100 Original-Received: (qmail 5889 invoked by uid 550); 10 Feb 2016 23:09:00 -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 5864 invoked from network); 10 Feb 2016 23:08:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emutechnology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dOLgLRbELedstmujQoBd3pKvthAHrT+06MHALEAv8n0=; b=eHCNrjZ7O2JGBloo3S5fcw4PtVA5FAr2+n35JVB/m4Ra26w1qO1IWtc598mu4TORmQ ikeY2e29L5efRo8hv2rq6iPyIHDdtYhJjBT+pbf2RCcjttUG69BXBBRkuEIHf3UcZl+A r5/taRIZQaJBD/lnCnVudCAjDsSGGI1gJbcGtOVmFhQdu7Kc66v57QThhrnduwF7GShh CDKiUsJ0TM2f309XpNjBONjN7nkypcSIN9EX6Khy/2mMQOnsrP1V9nfKCxmI2nfwarjB UuOR4S30GbUpzkG0DwwuIYuPVLZrb2B13baM6HAkMhGSnIFB/w1ebH/Ih+Ky2XiPnSGu j3Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dOLgLRbELedstmujQoBd3pKvthAHrT+06MHALEAv8n0=; b=eKmhFJQNXE05XTXpbGcKt9hSYeebTksjhpFR8Z7qh/Bufgl7336a2dgyE9GYwSDsqH UJCSCRKMl9djThGTb0ciBJccDWZmSfY2Hy2Fjs/58URLokGZWkxuohXAkoMcRyp0hbJk 1CpRveYOL/x+ne0jWL9d0p6K5qNR1X/JBzQm1+h25M01/CkUaApdR+/9+b3R4pvBz+P6 FwBXAXDMRbfeCSM+fKneDpxT3GZtdCY9ylM4deQB1LxvEHWG3SeVDnILdVfcCjCpHCTt vJzRBNoaX2ovpi2TMu5VMCk7CZhef1bZtK7wdYXeuqM1TBZZCf+jKp5hs5pMgWxV+RVV Zu7Q== X-Gm-Message-State: AG10YOQmyG4dBYn1up8eqO51nRFOvz3S80WQlGVrI4QUO8vT3s2awGJfKTyBM0a+NrnOB6WvlxJmpKp948kFJQ== X-Received: by 10.182.114.232 with SMTP id jj8mr40794364obb.19.1455145727148; Wed, 10 Feb 2016 15:08:47 -0800 (PST) In-Reply-To: <1455141901.26335.95.camel@zhasha.com> Xref: news.gmane.org gmane.linux.lib.musl.general:9300 Archived-At: --001a11c301dc29e148052b72845e Content-Type: text/plain; charset=UTF-8 > > fflush(stdout); > This is more of a basic C thing than a libc ml thing. You should > consider picking up a copy of The C Programming Language by Kernighan > and Ritchie. It will explain all of this. I know about fflush, thanks. Consider this program: int main() { char buff[2]; puts("enter a character"); buff[0] = getchar(); buff[1] = '\0'; puts(buff); return 0; } If I compile that on linux-amd64, with or without musl, I will see "enter a character" printed to my console and then be prompted for a character, as opposed to the other way around. I don't know if this is formally guaranteed by the C standard, but somehow that order seems to be maintained. But if I grep the source code in musl/src/stdio for "fflush" I don't see a bunch of calls to fflush. I see a call to it in fclose and freopen... but that's neither surprising nor helpful. If I do the same in musl/src/internal I also don't get anything. I've even tried just greping for "flush." And yet somehow the order is maintained within those calls to puts and getchar. So what I'm asking is: how? What part of the internal musl source even attempts to enforce that ordering? I know the calling application can do it with calls to fflush, but somehow that doesn't seem to be necessary short of a signal interrupting the expected flow of execution. Am I just getting lucky 100% of the time or is there some source in the stdio library that's enforcing this? On Wed, Feb 10, 2016 at 5:05 PM, Joakim Sindholt wrote: > On Wed, 2016-02-10 at 16:49 -0500, Max Ruttenberg wrote: > > All, > > > > > > I guess my question is more easily asked through an example. If I have > > code that makes a call to puts and then a call to getchar, what > > mechanism enforces that stdout gets flushed before blocking for stdin? > > Is there a such a mechanism? My gut says yes but I haven't been able > > to pinpoint it. > > > > > > Thanks, > > Max > > fflush(stdout); > > This is more of a basic C thing than a libc ml thing. You should > consider picking up a copy of The C Programming Language by Kernighan > and Ritchie. It will explain all of this. > > -- Max Ruttenberg, Member of the Technical Staff Emu *Technology* 1400 E Angela Blvd, Unit 101 South Bend, IN 46617 --001a11c301dc29e148052b72845e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
fflush(s= tdout);
This is more of a basic C thing than a libc ml thing. You should
consider picking up a copy of The C Pro= gramming Language by Kernighan
a= nd Ritchie. It will explain all of this.

=
I know about fflush, thanks.

Consider this pr= ogram:

int main()
{
=C2=A0 =C2= =A0char buff[2];
=C2=A0 =C2=A0puts("enter a character")= ;
=C2=A0 =C2=A0buff[0] =3D getchar();
=C2=A0 =C2=A0buff= [1] =3D '\0';
=C2=A0 =C2=A0puts(buff);
=C2=A0 = =C2=A0return 0;
}

If I compile that on l= inux-amd64, with or without musl, I will see "enter a character" = printed to my console and then be prompted for a character, as opposed to t= he other way around. I don't know if this is formally guaranteed by the= C standard, but somehow that order seems to be maintained.=C2=A0

But if I grep the source code in musl/src/stdio for "f= flush" I don't see a bunch of calls to fflush. I see a call to it = in fclose and freopen... but that's neither surprising nor helpful. If = I do the same in musl/src/internal I also don't get anything. I've = even tried just greping for "flush."

And= yet somehow the order is maintained within those calls to puts and getchar= . So what I'm asking is: how? What part of the internal musl source eve= n attempts to enforce that ordering? I know the calling application can do = it with calls to fflush, but somehow that doesn't seem to be necessary = short of a signal interrupting the expected flow of execution. Am I just ge= tting lucky 100% of the time or is there some source in the stdio library t= hat's enforcing this?

On Wed, Feb 10, 2016 at 5:05 PM, Joakim Sindholt <= opensource@zhasha.com> wrote:
On Wed, 2016-02-10 at 16:49 -050= 0, Max Ruttenberg wrote:
> All,
>
>
> I guess my question is more easily asked through an example. If I have=
> code that makes a call to puts and then a call to getchar, what
> mechanism enforces that stdout gets flushed before blocking for stdin?=
> Is there a such a mechanism? My gut says yes but I haven't been ab= le
> to pinpoint it.
>
>
> Thanks,
> Max

fflush(stdout);

This is more of a basic C thing than a libc ml thing. You should
consider picking up a copy of The C Programming Language by Kernighan
and Ritchie. It will explain all of this.




--
Max Ruttenberg,=
Member of the Technical Staff
Emu=C2=A0Technology
1400 E= Angela Blvd, Unit 101
South Bend, IN 46617
--001a11c301dc29e148052b72845e--