Date:Thu, 4 Apr 2019 10:12:35 +
From:co...@sdf.org
Message-ID: <20190404101235.gb6...@sdf.org>
| I understand the need for correctness, but the limits for find ... -exec
| are really low,
What limits do you think are being encountered here?
| and it's quite
On 04/05, Edgar Fuß wrote:
> Apart from a GS rendering library exporting symbol with the name of a
> well-known crypto function being a strange idea, who is at fault?
IMO, they're both at fault. To avoid this kind of problem, all global
symbols should be namespaced, so OpenSSL's SHA384_Update sh
I'm not sure at which level this needs to be dealt with.
libgs, in its infinite wisdom, exports SHA384_Update, which of course clashes
with OpenSSL's well known symbol of the same name. Which means that as soon as
you pull in libgs, your TLS may fail in mysterious ways.
[In my case, it was php-
In article ,
enh wrote:
>-=-=-=-=-=-
>
>here's a patch that doesn't actually break anything. the previous
>version was wrong in the non-copy case, so this version always copies.
>(the alternative would be to remember the overwritten byte and restore
>it on the next call, but this brings the code
