[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
On 20/04/2020 20:26, Andrew Cooper wrote: >>>> --- >>>> common/libc/vsnprintf.c | 10 ++++++++++ >>>> 1 file changed, 10 insertions(+) >>>> >>>> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c >>>> index a49fd30..3202137 100644 >>>> --- a/common/libc/vsnprintf.c >>>> +++ b/common/libc/vsnprintf.c >>>> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char >>>> *fmt, va_list args) >>>> if ( *fmt != '%' ) >>>> { >>>> PUT(*fmt); >>>> + >>>> + /* >>>> + * The '\n' character alone on some terminals is not >>>> automatically >>>> + * converted to LFCR. >>>> + * The explicit LFCR sequence guarantees proper line by line >>>> + * formatting in the output. >>>> + */ >>>> + if ( *fmt == '\n' && str < end ) >>>> + PUT('\r'); >>> ... doesn't this end up putting out \n\r ? >> yes, it does > So the one type of line ending which isn't in common use? Switching this to do \r\n does seem to fix the raw `xl create` problem you were seeing before, doesn't cause the double newlines as far as `./xtf-runner` is concerned, and doesn't appear to cause xenconsoled to write windows file endings. I'm still a little hesitant to do this unilaterally. Do we know what Linux usually emits via the console, because that will get us closer to whatever people actually test. ~Andrew
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |