[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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.