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
