Посмотрите setvbuf();

newlib - достаточно "взрослая" библиотека. Для увеличения производительности она буферизует вывод, в том числе и на stdout (насколько я помню stderr не буферизуется для удобства отладки). Содержимое буфера скидывается либо по fflush как было сказано выше, либо по символу перевода строки "\r\n".
По поводу yagartoo - она уже давно умела нормально собирать данный функционал.

Благодарю, уже почитал маны по теме. Не ожидал, что embedded библиотека столь "достаточно "взрослая"".

Вот этот момент мне не очень понятен. Чем инициализируется stdout? Иными словами, куда, на какое устройство будут выводиться данные, отправляемые в stdout?

У меня типичная инициализация происходит так (упрощенный пример - сервер, принимающий tcp соединения):

В результате вызова printf() я получаю вызов _write(int, char*, int), первым аргументом которого будет значение sd, указанное при вызове fdopen().
А что я получу в качестве первого аргумента _write, если не сделаю fdopen? Как в этом случае _write должна решить, куда отправлять данные, на которые указывает второй аргумент?...

Как я уже писал, на момент входа в main дескрипторы для stdin/stdout/stderr уже существуют, и инициализируются при первом обращении при помощи __sinit.


В случае newlib, вы получите дескриптор _reent->_stdin (ну или _stdout, _stderr) (посмотрите в newlib: sys/reent.h) - это позволит принять решение о целевом устройстве.

Не могу с Вами полностью согласиться.

Стандартные потоки, безусловно, существуют, как некий объект в памяти. Вопрос был в том, можно ли начать работать с этими объектами, предварительно явно их не инициализировав. О том, что они автоматически инициализируются при первом обращении, я не знал, спасибо за информацию. Мысль же моя заключалась в том, что для последующей работы с выводом на низком уровне (в соответствующих системных вызовах) необходимо, чтобы этим системным вызовам передавались осмысленные аргументы и, в частности, файловый дескриптор. При явной инициализации потока (через fopen или fdopen) это осмысленное значение предоставляет программист. А если инициализация происходит "автомагически", без участия программиста, откуда тогда возьмется это осмысленное значение?

Вот сейчас я посмотрел код newlib. Значение дескриптора хранится в поле _file структуры FILE. То есть системным вызовам, в нашем случае _write(), в качестве первого аргумента передается _reent->_stdout->_file. Теперь смотрим, какое же значение там находится. __sinit() для инициализации стандартных потоков вызывает __sfp(), которая, в свою очередь, инициализирует поле _file значением -1. Таким образом, при выполнении каких-либо операций с таким потоком системным вызовам будет передаваться -1 в качсетве файлового дескриптора, что традиционно означает невалидный дескриптор, и такой системный вызов, как правило, должен давать ошибку EBADF (bad file descriptor). По крайней мере, никакого решения о целевом устройстве такой дескриптор принять не позволит.

Конечно, если в целевой системе заведомо существует только одно устройство ввода/вывода (например один com-порт), тогда все операции производятся с ним и только с ним, и можно, наверное, в системных вызовах не анализировать значение дескриптора. Но как только мы допускаем наличия нескольких логических устройств (хотя бы двух com-портов), возникает и необходимость мультиплексировать операции ввода/вывода, а для этого потребуется селектор, которым и является дескриптор, передаваемый первым аргументом. И тогда придется-таки открывать потоки явно через fopen(3)/fdopen(3)...

Подозреваю, что мы говорим о различных версиях newlib; у меня 1.18, как я уже писал тут.


В случае 1.18, значение возмется из machine/spu/c99ppe.h:



Для 1.18 это не совсем верно:

Соответственно, для stdin/stdout/stderr мы получим дескрипторы 1, 2, 3.

А, понял. Вы говорите о __sinit из newlib/libc/machine/spu/stdio.c, а я смотрел __sinit() из newlib/libc/stdio/findfp.c.
У меня (вот сейчас смотрю map-файл реального проекта) используется __sinit именно из findfp.o (arm-elf/lib/libc.a). А у Вас не так?

Вы говорите о различиях стандартных потоков ввода, вывода и ошибок. Я говорил о другом.
Допустим, в целевом устройстве два com-порта. Для работы с ними я запускаю две одинаковые задачи. В каждой из них выполняется printf(), то есть производится вывод в stdout. Но одна задача должна выводить в один com-порт, другая - в другой! Для этого каждая задача должна по-своему проинициализировать stdout. Если первая задача выполнит stdout = fdopen(1, "w+"); а вторая - stdout = fdopen(2, "w+");, то printf(...) из первой задачи даст вызов _write(1, ....), а из второй - _write(2, .....).

Вы не ответили, какую версию newlib используете.


Верно, я говорил о другом, априори полагая, что все таски должны всё-таки по-умолчанию использовать общий stdout.

А Вы не спрашивали. Вы лишь высказали предположение, что мы говорим о разных версиях...
Нет, я говорю о newlib-1.18.0.

Точно - я вопрос забыл написать, но он подразумевался.
Ну и наконец, значения дескрипторов при выполнении:

Хм.