> And don't ask me to actually think about what I'm doing,
I am still open for further discussions.
> it's too hard to figure out how to print a string and a number without using
> printf().
This data display (e. g. for the input command and line number) is generally
not a problem. But the si
> Original printed more useful information.
I am aware of the desire to get some data for easier program debugging
conveniently.
> Just dropping it in sake of "correctness" is wrong.
I have got an opposite opinion. I am curious if more software developers would
like to care for complete async
Don't CC wine-patches.
Markus Elfring wrote:
>> Original printed more useful information.
>> Just dropping it in sake of "correctness" is wrong.
>> You'll have to come up with something that prints the same
>> or don't touch it.
>
> I am aware of the desire to get some data for easier program deb
Markus Elfring wrote:
> Hello,
>
> Some signal handler implementations are also affected by technical details
> that are described in an article by Justin Pincar.
> https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers
>
I'm not sure this change does what you think:
- fflush(stdout);
...
+(void) fsync(STDOUT_FILENO);
The real problem with your change is that *we don't care*
whether the output of wineserver is garbled, because
it is low priority debugging information, and I've never
seen it garbled in pr
