Problems redirecting stdin/out for a task in

Thomas Doerfler Thomas.Doerfler at
Mon Nov 28 07:04:15 UTC 2005


I have just ported a piece of test code from rtems-4.6.0pre4 to 
on a PowerPC 603 machine. I am workling with the gcc-4.0.1 toolset. I 
have detected two issues concerning stdio functionality:

1. It seems the newlib no longer detects, that a given path is a tty 
(serial console) device, it performs line buffering on the output 
stream. The effect is as follows:

	printf("Hello, this is Task xxx\n");
	printf("Enter your input==>");

The above code only outputs the first line, the second one only comes up 
when a further printf also adds a "\n" to the output stream. Adding a 
"fflush(stdout)" after the second printf makes the prompt visible, but I 
am quite sure this was not neccesary for character devices in earlier 
RTEMS versions.

2. (And this is worse): I instantiate the same sample code in multiple 
tasks, each task uses a different serial device for I/O. See the 
following code:

rtems_task v24_demo_task(rtems_task_argument arg)
   const char *stddev = (const char *)arg;
   rtems_status_code sc = RTEMS_SUCCESSFUL;
   int tsk_fd;
    * open new device
   tsk_fd = open(stddev,O_RDWR);
   if (tsk_fd < 0) {
     sc = RTEMS_IO_ERROR;
     fprintf(stderr,"Can't open %s for V.24 demo task: %s",
    * assign paths to stdin/out
   if (sc == RTEMS_SUCCESSFUL) {
     stdin  = fdopen(tsk_fd,"r");
     if (stdin == NULL) {
       sc = RTEMS_IO_ERROR;
   if (sc == RTEMS_SUCCESSFUL) {
     stdout = fdopen(tsk_fd,"a");
     if (stdout == NULL) {
       sc = RTEMS_IO_ERROR;
   if (sc != RTEMS_SUCCESSFUL) {
     fprintf(stderr,"Can't fdopen %s for V.24 demo task: %s",
   while (sc == RTEMS_SUCCESSFUL) {
      * print info (own path etc)
     printf(" Hi, you are talking to the demo task on %s\n",stddev);
     printf("Enter expression or==>");

The intention is that this code redirects stdin/stdout to the device 
passed in the "arg" argument ("/dev/tty1", "/dev/tty2"...) when the task 
is started. Strange things happen:
	The first "write" call really sends output to the desired interface. 
When I inspect the "_impure_ptr" for this task, I can also see that the 
_stdin/_stdout structure contains the proper "_file" parameter, before 
the first printf is called. But after the printf call returns, 
_impure_ptr->_stdout->_file has been rewritten with "1", which seems the 
"default" value for stdout. Before I start digging into newlib, I would 
like to know:

- has the mechanism to redirect stdio changed?
- has anybody else detected the same effects?
- has anybody already fixed this?

Thomas Doerfler.

IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at
PGP public key available at:

More information about the users mailing list