stdout and stderr are getting mixed up?
chrisj at rtems.org
Thu Jun 22 06:00:26 UTC 2017
On 22/06/2017 15:48, Sebastian Huber wrote:
> On 22/06/17 07:29, Chris Johns wrote:
>> On 22/06/2017 15:20, Sebastian Huber wrote:
>>> On 22/06/17 07:14, Chris Johns wrote:
>>>>> If you need a proper log, then you have to ensure this at application level.
>>>> What about this post:
>>>> It would imply a line should not be broken up. I do not know.
>>> You have thread-local stdio streams in Newlib that use a common output device by
>> Is what we do acceptable standard behavior?
> I doubt that thread-local stdio streams are in line with POSIX/C.
We need to consider this and what we do. We have breakage here and with C++.
>> The link I posted would suggest otherwise.
> It doesn't cite the POSIX standard. I don't know where this atomic printf()
> behaviour is defined.
Did you check the author's name?
>> RTEMS 4.9, 4.10, and 4.11 did not do
>> this so is this a regression?
> The original post compares the beatnik and pc386 BSPs. It compares an Epic
> implementation using the Classic API with one using the POSIX API. I don't
> think there is a regression. I remember that the output of ticker was always
> mixed up with an interrupt driven console driver.
It is present on the Zynq (polled driver). A sample:
rc.conf: /etc/n]o]t ipcoew:e rs.tpaetauks.:P isny:s mmoanx :g e2t8 3v.a3l3u0e0:0 0p
orwce.rc.oVnifn:: iifoc oenrfriogr:
LiOfGc:o nsftiagt ulso:0 siynsemto n1 2g7e.t0 .v0a.l1u en:e tpmoawsekr
.2V5i5n.:0 .i0o. 0e rurp
It is a complete turn off for users if this happens. If what we do meets the
standards then we can at least have a case we can present. If it does not and we
then create requirements based on the standards what happens?
More information about the users