From: Joaquin Cono Bolillo <joaquin_ConoBolillo@yahoo.es>
To: Tim Lewis <tim.lewis@insyde.com>,
"Gao, Liming" <liming.gao@intel.com>,
edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: AsciiPrint behavior with \n linefeed characters.
Date: Fri, 14 Oct 2016 09:03:35 +0200 [thread overview]
Message-ID: <120632.90424.bm@smtp108.mail.ir2.yahoo.com> (raw)
In-Reply-To: <7236196A5DF6C040855A6D96F556A53F3F6968@msmail.insydesw.com.tw>
In theory, and in “Standard C”-implementations, the fwrite()—related functions does the conversations
in the “internal” FILE* -- buffer (in userland).
The translation is done if the so called “stream”, that is
• file on disk
• terminal
• printer
• NULL
• something else, that is handled by the fopen()/fclose()/fread()/fwrite() related functions
was opened in TEXT MODE, and if the string is written to the internal FILE* buffer by inserting additional CR before LF,
or if read from the internal FILE *buffer, by removing each CR, that is succeeded by LF
With PC – C – Compilers/Libraries different algorithms are implemented (only fread() examined):
• WATCOM: the character following carriage return CR/0x0D is skipped,
If there are consecutive CR, the second one is available in the text buffer
• Mircosoft: In a CRLF (0x0D,0x0A) pair, the CR is deleted in the text buffer, otherwise it is copied to the textbuffer
• Borland: each CR is removed
• Digital Mars: each CR is removed
In binary view you can see the differences, with that sample program
#include <stdio.h>
int main(int argc,char **argv){
FILE *fp = fopen("test.bin","wb" /*open for binary write*/);
//FILE *fp = fopen("test.bin","w" /*open for text write*/);
fwrite("line1\nline2\nline3\n",1,sizeof("line1\nline2\nline3\n"),fp);
fclose(fp);
return 0;
}
The translation has to be done by the output function.
To sure always use CR,LF in your string.
Regards,
JC
Von: Tim Lewis
Gesendet: Friday, October 14, 2016 04:05 AM
An: Gao, Liming; edk2-devel-01
Betreff: Re: [edk2] AsciiPrint behavior with \n linefeed characters.
Liming --
And I agree that this should be the behavior. I was surprised by the lack of translation for the other string printed via %s.
Tim
-----Original Message-----
From: Gao, Liming [mailto:liming.gao@intel.com]
Sent: Thursday, October 13, 2016 6:24 PM
To: Tim Lewis <tim.lewis@insyde.com>; edk2-devel-01 <edk2-devel@lists.01.org>
Subject: RE: AsciiPrint behavior with \n linefeed characters.
Tim:
The first parameter in AsciiPrint() is the Format string. Per PrintLib.h definition, \n will be changed to \r\n in the format string.
The following end of line(EOL) translations must be performed on the contents of the format string:
- '\\r' is translated to '\\r'
- '\\r\\n' is translated to '\\r\\n'
- '\\n' is translated to '\\r\\n'
- '\\n\\r' is translated to '\\r\\n'
Thanks
Liming
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Tim Lewis
Sent: Friday, October 14, 2016 5:29 AM
To: edk2-devel-01 <edk2-devel@lists.01.org>
Subject: [edk2] AsciiPrint behavior with \n linefeed characters.
In using AsciiPrint (I'm presuming the behavior is also in Print, but I haven't tested), I found an interesting behavior for linefeed characters embedded in strings that are parameters. I post it here just so people who are mystified by their output can understand it.
Consider this example:
CONST CHAR16 *XyzStr = "HI\nBYE";
AsciiPrint(XyzStr);
AsciiPrint("Offset\n%s\n", XyzStr);
Output looks like this:
HI
BYE
Offset
HI
BYE
It turns out that \n characters in the format string are converted to \r\n, but \n characters in strings that are embedded (as in the second example) are not converted. So only the linefeed character is interpreted, leading to "BYE" being suspended one character to the right and one row lower than "HI"
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
next prev parent reply other threads:[~2016-10-14 7:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-13 21:29 AsciiPrint behavior with \n linefeed characters Tim Lewis
2016-10-14 1:24 ` Gao, Liming
2016-10-14 2:05 ` Tim Lewis
2016-10-14 7:03 ` Joaquin Cono Bolillo [this message]
2016-10-14 9:31 ` Gao, Liming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=120632.90424.bm@smtp108.mail.ir2.yahoo.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox