* AsciiPrint behavior with \n linefeed characters.
@ 2016-10-13 21:29 Tim Lewis
2016-10-14 1:24 ` Gao, Liming
0 siblings, 1 reply; 5+ messages in thread
From: Tim Lewis @ 2016-10-13 21:29 UTC (permalink / raw)
To: edk2-devel-01
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"
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: AsciiPrint behavior with \n linefeed characters.
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
0 siblings, 1 reply; 5+ messages in thread
From: Gao, Liming @ 2016-10-14 1:24 UTC (permalink / raw)
To: Tim Lewis, edk2-devel-01
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: AsciiPrint behavior with \n linefeed characters.
2016-10-14 1:24 ` Gao, Liming
@ 2016-10-14 2:05 ` Tim Lewis
2016-10-14 7:03 ` Joaquin Cono Bolillo
2016-10-14 9:31 ` Gao, Liming
0 siblings, 2 replies; 5+ messages in thread
From: Tim Lewis @ 2016-10-14 2:05 UTC (permalink / raw)
To: Gao, Liming, edk2-devel-01
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: AsciiPrint behavior with \n linefeed characters.
2016-10-14 2:05 ` Tim Lewis
@ 2016-10-14 7:03 ` Joaquin Cono Bolillo
2016-10-14 9:31 ` Gao, Liming
1 sibling, 0 replies; 5+ messages in thread
From: Joaquin Cono Bolillo @ 2016-10-14 7:03 UTC (permalink / raw)
To: Tim Lewis, Gao, Liming, edk2-devel-01
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: AsciiPrint behavior with \n linefeed characters.
2016-10-14 2:05 ` Tim Lewis
2016-10-14 7:03 ` Joaquin Cono Bolillo
@ 2016-10-14 9:31 ` Gao, Liming
1 sibling, 0 replies; 5+ messages in thread
From: Gao, Liming @ 2016-10-14 9:31 UTC (permalink / raw)
To: Tim Lewis, edk2-devel-01
Tim:
PrintLib only says \n in format string to be converted. It keeps other string as-is. So, this is the expected behavior.
Thanks
Liming
> -----Original Message-----
> From: Tim Lewis [mailto:tim.lewis@insyde.com]
> Sent: Friday, October 14, 2016 10:05 AM
> To: Gao, Liming <liming.gao@intel.com>; edk2-devel-01 <edk2-
> devel@lists.01.org>
> Subject: RE: 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-10-14 9:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2016-10-14 9:31 ` Gao, Liming
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox