Program issue when compiled against Newlib

[Ian Seyler]

The extra newlines issue was fixed in the OS:

os_print_chars_nextchar:
	jrcxz os_print_chars_done
	sub rcx, 1
	lodsb				; Get char from string and store in AL
	cmp al, 13			; Check if there was a newline character in the string
	je os_print_chars_newline	; If so then we print a new line
	cmp al, 10			; Check if there was a newline character in the string
	je os_print_chars_newline	; If so then we print a new line

There was no logic to check if it was a CR followed by a LF. The same
code compiled for BareMetal OS and Linux behaves the same way now.

Thanks,
-Ian


On Fri, Aug 12, 2011 at 12:03 PM, Ian Seyler
<ian.seyler@returninfinity.com> wrote:
> You are on to something with '\r'. Maybe my implementation of read()
> is off. I now get better results as seen here:
> ----------------
> Please type your name: Ian
> Please type another word: Test
> Hello Ian
>
> Word was Test
>
> Goodbye.
> ----------------
>
> The data from the second string is now printed. I just get some extra
> newline characters now.
>
> // read - Read from a file
> int read(int file, char *ptr, int len)
> {
>        asm volatile ("xchg %bx, %bx"); // Bochs magic debug
>        if (file == 0) // STDIN
>        {
>                asm volatile ("call *0x00100078" : "=c" (len) : "c"(len), "D"(ptr));
> // Automatically NULL terminates input from the keyboard
>                ptr[len] = '\r';
>                ptr[len+1] = '\n'; // NULL terminate as well?
>                len += 2;
>                asm volatile ("call *0x00100048"); // Print a newline
>        }
>        else
>        {
>                len = 0;
>        }
>        return len;
> }
>
> I am debugging the OS and program under Bochs.
>
> Thanks,
> -Ian
>
>
> On Fri, Aug 12, 2011 at 10:50 AM, Eric Norum <eric@norum.ca> wrote:
>> The serial I/O driver on your BareMetal OS isn't converting the '\r' that you used to terminate the input string into a "\r\n" when echoing -- on an old-fashioned paper terminal you'd see the two lines printed on top of each other.
>>
>> On Aug 12, 2011, at 7:26 AM, Ian Seyler wrote:
>>
>>> I have compiled NewLib for use in BareMetal OS but there seems to be
>>> an issue during program execution.
>>>
>>> Example Code:
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> char userinput1[160];
>>> char userinput2[160];
>>>
>>> int main()
>>> {
>>>       printf("Please type your name: ");
>>>       fgets(userinput1, 100, stdin);
>>>       printf("Please type another word: ");
>>>       fgets(userinput2, 100, stdin);
>>>       printf("Hello %s", userinput1);
>>>       printf("Word was %s", userinput2);
>>>       printf("Goodbye.\n");
>>>
>>>       return 0;
>>> }
>>>
>>> Program compiled with the regular C library and run under Ubuntu:
>>> Please type your name: Ian
>>> Please type another word: Test
>>> Hello Ian
>>> Word was Test
>>> Goodbye.
>>>
>>> Program compiled against Newlib and run under BareMetal OS:
>>> Please type your name: Ian
>>> Please type another word: Test
>>> Hello Ian
>>> Word was Goodbye.
>>>
>>> With debugging enabled under BareMetal OS I can see that both strings
>>> are populated with the data that was entered. However the last string
>>> displayed on the screen is "Word was Goodbye." in one call to the OS.
>>> Does anyone have a hint on this? Seems like an issue with printf().
>>> Does GCC optimize it somehow?
>>>
>>> Best regards,
>>> Ian
>>>
>>>
>>> --
>>> Ian Seyler | Founder / Lead Programmer | Return Infinity |
>>> ian.seyler@returninfinity.com | visit us at www.returninfinity.com
>>
>> --
>> Eric Norum
>> eric@norum.ca
>>
>>
>>
>>
>>
>
>
>
> --
> Ian Seyler | Founder / Lead Programmer | Return Infinity |
> ian.seyler@returninfinity.com | visit us at www.returninfinity.com
>



-- 
Ian Seyler | Founder / Lead Programmer | Return Infinity |
ian.seyler@returninfinity.com | visit us at www.returninfinity.com