Philipp Klaus Krause wrote:
> In the end, I wouldn't be surprised, if WG14 just goes with one of the
> existing names, not caring about reserved identifiers.
There is only one existing name in common use.
Even glibc chose to go with the name explicit_bzero.
I notice you keep using the other
Theo de Raadt wrote in
<61139.1597087...@cvs.openbsd.org>:
|Philipp Klaus Krause wrote:
|> Am 10.08.20 um 17:00 schrieb Theo de Raadt:
|>> Philipp Klaus Krause wrote:
|>>
|>>> OpenBSD has the explicit_bzero function to reliably (i.e. even if not
|>>> observable in the C abstract machine)
>>
>> WG14 has reserved some identifiers for future extensions of the
>> standard. E.g. those starting with mem_. Naturally, others then choose
>> identifiers that do not conflict with this, such as explicit_bzero. But
>> if that name is then used in the standard unchanged, it would mean that
>>
On Tue, Aug 11, 2020 at 08:20:32AM +0200, Otto Moerbeek wrote:
> On Tue, Aug 11, 2020 at 08:13:24AM +0200, Philipp Klaus Krause wrote:
>
> > Am 11.08.20 um 02:52 schrieb Theo de Raadt:
> > >
> > > But no, WG14 are the lords and masters in the high castle, and now 6
> > > years after the ship
On Tue, Aug 11, 2020 at 08:13:24AM +0200, Philipp Klaus Krause wrote:
> Am 11.08.20 um 02:52 schrieb Theo de Raadt:
> >
> > But no, WG14 are the lords and masters in the high castle, and now 6
> > years after the ship sailed something Must Be Done, it must look like
> > They Solved The Problem,
Am 11.08.20 um 02:52 schrieb Theo de Raadt:
>
> But no, WG14 are the lords and masters in the high castle, and now 6
> years after the ship sailed something Must Be Done, it must look like
> They Solved The Problem, and so they'll create an incompatible API.
>
> Will they be heroes? No, not
Steffen Nurpmeso wrote:
> Theo de Raadt wrote in
> <61139.1597087...@cvs.openbsd.org>:
> |Philipp Klaus Krause wrote:
> |> Am 10.08.20 um 17:00 schrieb Theo de Raadt:
> |>> Philipp Klaus Krause wrote:
> |>>
> |>>> OpenBSD has the explicit_bzero function to reliably (i.e. even if not
>
Tim van der Molen wrote:
> Philipp Klaus Krause (2020-08-10 21:00 +0200):
> > Am 10.08.20 um 17:00 schrieb Theo de Raadt:
> > > Philipp Klaus Krause wrote:
> > >
> > >> OpenBSD has the explicit_bzero function to reliably (i.e. even if not
> > >> observable in the C abstract machine) overwrite
Philipp Klaus Krause (2020-08-10 21:00 +0200):
> Am 10.08.20 um 17:00 schrieb Theo de Raadt:
> > Philipp Klaus Krause wrote:
> >
> >> OpenBSD has the explicit_bzero function to reliably (i.e. even if not
> >> observable in the C abstract machine) overwrite memory with zeroes.
> >>
> >> WG14 is
> Our base tree has 641 calls to explicit_bzero, because previous
> commitees fucked the C language and created hundreds of not thousands of
> security vulnerabilities by leaving data on the stack. In application
> software, both explicit_memset and explicit
Sorry I didn't finish the last
Philipp Klaus Krause wrote:
> Am 10.08.20 um 17:00 schrieb Theo de Raadt:
> > Philipp Klaus Krause wrote:
> >
> >> OpenBSD has the explicit_bzero function to reliably (i.e. even if not
> >> observable in the C abstract machine) overwrite memory with zeroes.
> >>
> >> WG14 is currently
Am 10.08.20 um 17:00 schrieb Theo de Raadt:
> Philipp Klaus Krause wrote:
>
>> OpenBSD has the explicit_bzero function to reliably (i.e. even if not
>> observable in the C abstract machine) overwrite memory with zeroes.
>>
>> WG14 is currently considering adding similar functionality to C2X.
>
Philipp Klaus Krause wrote:
> OpenBSD has the explicit_bzero function to reliably (i.e. even if not
> observable in the C abstract machine) overwrite memory with zeroes.
>
> WG14 is currently considering adding similar functionality to C2X.
Then perhaps in the interests of the public they
OpenBSD has the explicit_bzero function to reliably (i.e. even if not
observable in the C abstract machine) overwrite memory with zeroes.
WG14 is currently considering adding similar functionality to C2X.
Considered options include:
* A function like explicit_bzero or memset_explicit, that
14 matches
Mail list logo
