After compiling with -mboard=or1ksim-uart it blocked with xterm.
But it 's not 100% good.
the code is
#include<stdlib.h>
#include<stdio.h>
int foo(int a, int b)
{
int c;
c = a + b;
return c;
}
int main()
{
int a, b, x;
a = 2;
b = 3;
printf("\nEnter a: ");
scanf ("%d", &a);
printf("\nEnter b: ");
scanf ("%d", &b);
x = foo(a,b);
printf("\nThe result is: %d\n", x);
exit(0);
}
After entering a or b if I don't leave a space before hitting return
it does not read correctly .
Run the code on the PC to see the correct behavior.
On Mon, Feb 17, 2014 at 10:15 PM, Olof Kindgren <[email protected]> wrote:
> I got a bit curious after I read on IRC that scanf in or1ksim behaves
> a bit weird, so I decided to investigate this
>
> Armed with a test program like this:
> #include <stdio.h>
>
> void main(void) {
> int x;
> scanf("%d", &x);
> printf("Before\n");
> printf("%d\n", x);
> printf("After\n");
> }
> I could conclude that or1ksim doesn't block on scanf neither with
> channel = fd or channel = tcp in the or1ksim config.
>
> I'm not sure I found the correct solution yet, but I did find some
> dubious code that looks like off-by-one errors paired with inverted
> logic. Could anyone with more read/select experience take a quick look
> at this patch and see if it makes more sense than the original code. I
> think it does
>
> diff --git a/peripheral/channels/fd.c b/peripheral/channels/fd.c
> index ee4b810..8ee6aed 100644
> --- a/peripheral/channels/fd.c
> +++ b/peripheral/channels/fd.c
> @@ -114,7 +114,7 @@ fd_read (void *data, char *buffer, int size)
>
> retval = select (fds->fdin + 1, &rfds, NULL, NULL, &timeout);
> }
> - while ((retval < 0) && (EINTR == errno));
> + while ((retval <= 0) && (EINTR != errno));
>
> if (retval <= 0)
> return retval;
> @@ -124,7 +124,7 @@ fd_read (void *data, char *buffer, int size)
> {
> retval = read (fds->fdin, buffer, size);
> }
> - while ((retval < 0) && (EINTR == errno));
> + while ((retval <= 0) && (EINTR != errno));
>
> return retval;
> }
>
> Also, it would be interesting to see how the same test program
> compiled with glibc or uclibc behaves under linux. Might be a newlib
> bug rather than something in or1ksim
>
> //Olof
> _______________________________________________
> OpenRISC mailing list
> [email protected]
> http://lists.openrisc.net/listinfo/openrisc
--
Jose T. de Sousa, PhD
Office: +351 213 100 213
R. Alves Redol 9
1000-029 Lisboa
Portugal
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
