stdout and stderr are getting mixed up?

[Chris Johns]

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:
>>>>
>>>> https://groups.google.com/d/msg/comp.programming.threads/1-bU71nYgqw/HSfD8625QzkJ
>>>>
>>>>
>>>> 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
>>> default.
>>>
>> 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?

http://pubs.opengroup.org/onlinepubs/9699919799/functions/flockfile.html ?

> 
>>   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?

Chris