Hi Marc,
These rules were written at a time where graphical environments were
not a thing...
The definition of the standard I/O streams haven't changed in the latest POSIX standard from 2017:
"At program start-up, three streams shall be predefined and need not be opened explicitly: standard input (for reading
conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic
output). When opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully
buffered if and only if the stream can be determined not to refer to an interactive device."
Why not simply have an API function to override the stdout/stderr
outputs? This would be useful if a program wants to log Lightning's
output to file.
Yes! I very much second this. It is probably enough to make the stream variable an extern variable in <lightning.h> together with a preprocessor flag that tells whether the variable is actually defined (because we may have a non-debug build).
My point from above is simply that the default has to be stderr and not stdout because the latter (as a default!) is wrong.
Cheers,
Marc
Cheers,
-Paul
Le mar., mai 18 2021 at 10:49:56 +0200, Marc Nieper-Wißkirchen
<marc.nieper+gnu@gmail.com> a écrit :
> Hi Paul,
>
> thanks for explaining.
>
> Your use of stdout/stderr doesn't seem to be the intended one. All
> the log messages should go to stderr (unless the sole purpose of the
> program is to produce log messages :)).
>
> Can't you pipe your log messages (the stderr output) through a
> filter? That looks like the best (and canonical) solution to me.
>
> Marc
>
> Am Di., 18. Mai 2021 um 10:14 Uhr schrieb Paul Cercueil
> <paul@crapouillou.net>:
>> Hi Marc,
>>
>> I use log levels, Debug - Info - Warning - Error, the first two
>> going
>> to stdout, the last two going to stderr. That way I can easily
>> separate
>> important messages from non-important messages when debugging. If
>> Lightning sends the disassembly to stderr, then both outputs become
>> extremely verbose and I'd have a hard time to spot actual errors.
>>
>> -Paul
>>
>>
>> Le mar., mai 18 2021 at 08:31:38 +0200, Marc Nieper-Wißkirchen
>> <marc.nieper+gnu@gmail.com> a écrit :
>> > Hi Paul,
>> >
>> > I hope you can easily fix it.
>> >
>> > POSIX and the GNU C Library define "stderr" to be "used for error
>> > messages and diagnostics issued by the program", so the
>> disassembly
>> > info should really go there by default.
>> >
>> > Marc
>> >
>> > Am Mo., 17. Mai 2021 um 20:35 Uhr schrieb Paul Cercueil
>> > <paul@crapouillou.net>:
>> >> Hi,
>> >>
>> >> This now breaks it for me :)
>> >>
>> >> My dynarec right now outputs all debug data (including
>> disassembly)
>> >> to
>> >> stdout, and I run scripts on the output to check compliance vs.
>> the
>> >> interpreter.
>> >>
>> >> -Paul
>> >>
>> >>
>> >> Le lun., mai 17 2021 at 19:02:30 +0200, Marc Nieper-Wißkirchen
>> >> <marc.nieper+gnu@gmail.com> a écrit :
>> >> > Thanks a lot for the quick reply and the update!
>> >> >
>> >> > Marc
>> >> >
>> >> > Am Mo., 17. Mai 2021 um 18:35 Uhr schrieb Paulo César
>> Pereira de
>> >> > Andrade <paulo.cesar.pereira.de.andrade@gmail.com>:
>> >> >> Em seg., 17 de mai. de 2021 às 06:10, Marc
>> Nieper-Wißkirchen
>> >> >> <marc.nieper+gnu@gmail.com> escreveu:
>> >> >> >
>> >> >> > Hi Paulo,
>> >> >>
>> >> >> Hi Marc,
>> >> >>
>> >> >> > this is a feature request to either make stderr (instead
>> of
>> >> >> stdout) the disassembler output stream or to make it
>> >> customizable.
>> >> >> >
>> >> >> > Currently, we have
>> >> >> >
>> >> >> > #define disasm_stream stdout
>> >> >> >
>> >> >> > in jit_disasm.c.
>> >> >>
>> >> >> Just created a static variable. An interface to change it
>> >> might
>> >> >> be added,
>> >> >> as builds with --enable-devel-disassembler are very useful
>> and
>> >> far
>> >> >> easier
>> >> >> to debug.
>> >> >>
>> >> >> > Especially for debugging programs that work as a pipe from
>> >> stdin
>> >> >> to stdout, it is important not to have the output cluttered
>> with
>> >> >> disassembly info.
>> >> >> >
>> >> >> > Thanks,
>> >> >> >
>> >> >> > Marc
>> >> >>
>> >> >> Thanks,
>> >> >> Paulo
>> >>
>> >>
>>
>>