* Paul Eggert:
> Florian Weimer wrote:
>>> You can achieve that "actual close call" using
>>>
>>>error = close(dup(fileno(stdout)));
>>>
>>> so you don't actually need to "fclose" if you don't want to.
>>> Any 'close' will do, it doesn't have to be the "last close".
>> Hah, thanks for this
Florian Weimer wrote:
You can achieve that "actual close call" using
error = close(dup(fileno(stdout)));
so you don't actually need to "fclose" if you don't want to.
Any 'close' will do, it doesn't have to be the "last close".
Hah, thanks for this suggestion! So something good came out of
* NeilBrown:
> On Tue, May 07 2019, Bruno Haible wrote:
>
>> Assaf Gordon wrote:
>>> 4.
>>> "fflush" instead of "fclose" seems to work OK, but I do not know
>>> if there are other side effects:
>>>
>>>$ ./aa stdout fflush > /dev/full && echo ok || echo error
>>>aa: fflush failed: No
Hi Kamil,
> Coverity Analysis 2019.03 incorrectly marks the input argument
> of base64_encode(), and conseuqnetly base64_encode_alloc(), as
> tainted_data_sink because it sees byte-level operations on the input.
>
> It triggered the following false positives in the cryptsetup project:
>
>
