From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out03.hibox.biz (out03.hibox.biz [210.71.195.45]) by mx.groups.io with SMTP id smtpd.web11.1886.1571433210007209646 for ; Fri, 18 Oct 2019 14:13:30 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: insyde.com, ip: 210.71.195.45, mailfrom: tim.lewis@insyde.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2A8BQAPKKpd/w00GKxlHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBHIEsRHQSKo0oiC8BhxKDbINDEYQWiAoJAQEBAQEBAQEBCCM?= =?us-ascii?q?JAQIBAYN7PwSDNTgTAgwBAQUBAQEBAQUEbYRrQgyFWgIjKTAFBhBSPwEEHgW?= =?us-ascii?q?DE4F5fg+yRBoChB0BgRSEdAaBNoFljEGBEYYyA4IthR8EljFElmAHgimHC44?= =?us-ascii?q?XG44mA4shlleRQ4FpIoFYcIM8EywREIFwF4hkhV8kMAGBIAgVAZBmAQE?= X-IronPort-AV: E=Sophos;i="5.67,313,1566835200"; d="scan'208,217";a="24932819" Received: from unknown (HELO hb3-BKT203.hibox.biz) ([172.24.52.13]) by out03.hibox.biz with ESMTP; 19 Oct 2019 05:13:28 +0800 Received: from unknown (HELO hb3-BKT101.hibox.biz) ([172.24.51.11]) by hb3-BKT203.hibox.biz with ESMTP; 19 Oct 2019 05:13:27 +0800 Received: from unknown (HELO hb3-IN03.hibox.biz) ([172.24.12.13]) by hb3-BKT101.hibox.biz with ESMTP; 19 Oct 2019 05:13:27 +0800 X-Remote-IP: 73.116.1.175 X-Remote-Host: c-73-116-1-175.hsd1.ca.comcast.net X-SBRS: -10.0 X-MID: 30651268 X-Auth-ID: tim.lewis@insyde.com X-EnvelopeFrom: tim.lewis@insyde.com hiBox-Sender: 1 Received: from c-73-116-1-175.hsd1.ca.comcast.net (HELO DESKTOPHG9V3E8) ([73.116.1.175]) by hb3-IN03.hibox.biz with ESMTP/TLS/AES256-SHA; 19 Oct 2019 05:13:26 +0800 From: "Tim Lewis" To: Subject: Flush on main exit? Date: Fri, 18 Oct 2019 14:13:24 -0700 Message-ID: <07be01d585f8$e27c05a0$a77410e0$@insyde.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdWF95NxWcfYLrJERhGabFuuIdDdqw== Content-Type: multipart/alternative; boundary="----=_NextPart_000_07BF_01D585BE.361E1800" Content-Language: en-us ------=_NextPart_000_07BF_01D585BE.361E1800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have noticed recently, when porting BSD applications, that if main exits normally, the buffers are not flushed. This is most obvious when using StdLib along with printf or fprintf to stdout. Has anyone else noticed this? If there is a \n in the output, it gets flushed to stdout, but if the string does not contain a \n then often nothing happens. This is most obvious with 1-line help or logo strings that never show up. Of course, most BSD apps use stderr for their usage, but even this doesn't go anywhere static void usage(void) { (void)fprintf(stderr, "usage: which [-as] program ...\n"); exit(EXIT_FAILURE); } Per the posix standard: OpenGroup says: https://pubs.opengroup.org/onlinepubs/009695399/functions/exit.html The exit() function shall then flush all open streams with unwritten buffered data, close all open streams, and remove all files created by tmpfile(). Finally, control shall be terminated with the consequences described below. I have seen similar behavior with CURL and printf. Any thoughts here? Tim ------=_NextPart_000_07BF_01D585BE.361E1800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have noticed recently, when porting BSD = applications, that if main exits normally, the buffers are not flushed. = This is most obvious when using StdLib along with printf or fprintf to = stdout.

 

Has anyone else noticed this? If there is a \n in the = output, it gets flushed to stdout, but if the string does not contain a = \n then often nothing happens. This is most obvious with 1-line help or = logo strings that never show up. Of course, most BSD apps use stderr for = their usage, but even this doesn’t go anywhere

 

static = void

usage(void)

{

 

         &= nbsp;     (void)fprintf(stderr, "usage: which = [-as] program ...\n");

         &= nbsp;     exit(EXIT_FAILURE);

}

 

Per the = posix standard:

 

OpenGroup = says:

https://pubs.opengroup.org/onlinepubs/009695399/functions/exit.html

 

The exit() function shall then flush all = open streams with unwritten buffered data, close all open streams, and = remove all files created by tmpfile(). Finally, control shall be terminated with the = consequences described below.

 

I have seen = similar behavior with CURL and printf.

 

Any thoughts = here?

 

Tim

 

------=_NextPart_000_07BF_01D585BE.361E1800-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mx.groups.io with SMTP id smtpd.web10.700.1571449773206119381 for ; Fri, 18 Oct 2019 18:49:33 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.126, mailfrom: mark.doran@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2019 18:49:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,313,1566889200"; d="scan'208,217";a="199893481" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by orsmga003.jf.intel.com with ESMTP; 18 Oct 2019 18:49:32 -0700 Received: from orsmsx160.amr.corp.intel.com (10.22.226.43) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 18 Oct 2019 18:49:32 -0700 Received: from orsmsx109.amr.corp.intel.com ([169.254.11.239]) by ORSMSX160.amr.corp.intel.com ([169.254.13.29]) with mapi id 14.03.0439.000; Fri, 18 Oct 2019 18:49:31 -0700 From: "Doran, Mark" To: "devel@edk2.groups.io" , "tim.lewis@insyde.com" Subject: Re: [edk2-devel] Flush on main exit? Thread-Topic: [edk2-devel] Flush on main exit? Thread-Index: AdWF95NxWcfYLrJERhGabFuuIdDdqwAJqEwA Date: Sat, 19 Oct 2019 01:49:30 +0000 Message-ID: References: <07be01d585f8$e27c05a0$a77410e0$@insyde.com> In-Reply-To: <07be01d585f8$e27c05a0$a77410e0$@insyde.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.139] MIME-Version: 1.0 Return-Path: mark.doran@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DFF7383D242A84439AD17BCBA41787FE9F4793A3ORSMSX109amrcor_" --_000_DFF7383D242A84439AD17BCBA41787FE9F4793A3ORSMSX109amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the ISO C standard is actually the governing spec for exit() now. = However, it more or less says the same thing as POSIX.1. I actually recall some of the early input to POSIX discussions about exit(= ) and flushing behavior (fflush() got lumped in to the same conversation). = It was somewhat of a hot topic with the X/Open work group especially becau= se ICL mainframes were "virtual" enough that the meaning of flushing was so= mewhat in question (for files at any rate) when there weren't actual disks = to receive the flush. In any case the C standard now seems quite clear to my eye: you ought to g= et your message on standard out or error regardless of newline or not. Tha= t should apply as I read the spec whether you have code that does an explic= it exit() from main(), or a return or even if execution just reaches the cl= osing brace on the main() function. Not knowing anything else, I'd say you= are seeing a bug in the implementation. -- Cheers, Mark. From: devel@edk2.groups.io On Behalf Of Tim Lewis Sent: Friday, October 18, 2019 2:13 PM To: devel@edk2.groups.io Subject: [edk2-devel] Flush on main exit? I have noticed recently, when porting BSD applications, that if main exits= normally, the buffers are not flushed. This is most obvious when using Std= Lib along with printf or fprintf to stdout. Has anyone else noticed this? If there is a \n in the output, it gets flus= hed to stdout, but if the string does not contain a \n then often nothing h= appens. This is most obvious with 1-line help or logo strings that never sh= ow up. Of course, most BSD apps use stderr for their usage, but even this d= oesn't go anywhere static void usage(void) { (void)fprintf(stderr, "usage: which [-as] program ...\n"); exit(EXIT_FAILURE); } Per the posix standard: OpenGroup says: https://pubs.opengroup.org/onlinepubs/009695399/functions/exit.html The exit() function shall then flush all open streams with unwritten buffe= red data, close all open streams, and remove all files created by tmpfile()= . F= inally, control shall be terminated with the consequences described below. I have seen similar behavior with CURL and printf. Any thoughts here? Tim --_000_DFF7383D242A84439AD17BCBA41787FE9F4793A3ORSMSX109amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think the ISO C standard is actually the = governing spec for exit() now.  However, it more or less says the same= thing as POSIX.1.

 

I actually recall some of the early input t= o POSIX discussions about exit() and flushing behavior (fflush() got lumped= in to the same conversation).  It was somewhat of a hot topic with the X/Open work group especially because ICL mainfram= es were “virtual” enough that the meaning of flushing was somew= hat in question (for files at any rate) when there weren’t actual dis= ks to receive the flush.

 

In any case the C standard now seems quite = clear to my eye: you ought to get your message on standard out or error reg= ardless of newline or not.  That should apply as I read the spec whether you have code that does an explicit exit() from m= ain(), or a return or even if execution just reaches the closing brace on t= he main() function.  Not knowing anything else, I’d say you are = seeing a bug in the implementation.

 

--

Cheers,

 

Mark.

 

From: devel@edk2.groups.io <devel@edk2.gr= oups.io> On Behalf Of Tim Lewis
Sent: Friday, October 18, 2019 2:13 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] Flush on main exit?

 

I have noticed recently, when porting BSD applicati= ons, that if main exits normally, the buffers are not flushed. This is most= obvious when using StdLib along with printf or fprintf to stdout.

 

Has anyone else noticed this? If there is a \n in t= he output, it gets flushed to stdout, but if the string does not contain a = \n then often nothing happens. This is most obvious with 1-line help or log= o strings that never show up. Of course, most BSD apps use stderr for their usage, but even this doesn’t go = anywhere

 

static void

usage(void)

{

 

        &nb= sp;      (void)fprintf(stderr, "usage: which = [-as] program ...\n");

        &nb= sp;      exit(EXIT_FAILURE);

}

 

Per the posix standard:

 

OpenGroup says:

https://pubs.opengroup.org/onlinepubs/00969539= 9/functions/exit.html

 

The exit(= ) function shall then flush all open streams with unwritten buffered data, = close all open streams, and remove all files created by tmpfile<= /i>(). Finally, control shall be terminated with the consequences described belo= w.

 

I have seen similar behavior with CURL and printf. =

 

Any thoughts here?

 

Tim

 

--_000_DFF7383D242A84439AD17BCBA41787FE9F4793A3ORSMSX109amrcor_--