stdout and stderr are getting mixed up?

[Sebastian Huber]

On 22/06/17 08:00, Chris Johns wrote:

> 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 Ada run-time is also broken. I don't think you can easily disable 
the thread-local stdio streams. Applications may rely on this feature.

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

I think flockfile() is not supported by RTEMS. It could be supported 
since the Newlib internal locking is now enabled.

powerpc-rtems4.12-objdump -d 
./powerpc-rtems4.12/c/qoriq_t4240rdb/cpukit/libcsupport/src/libcsupport_a-flockfile.o

./powerpc-rtems4.12/c/qoriq_t4240rdb/cpukit/libcsupport/src/libcsupport_a-flockfile.o: 
file format elf32-powerpc


Disassembly of section .text.flockfile:

00000000 <flockfile>:
    0:   4e 80 00 20     blr

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

It boils down to if you want to keep the thread-local stdio streams or 
not. For log output you could still use syslog() for example.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.