Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

Re:Patch Critical Cryptographic Vulnerability in Microsoft W... by loup-vaillant on Thursday January 16, 2020 @02:31AM (#22062361)

C compiler writers have answered that conundrum a long time ago: "if you (even accidentally) rely on undefined behaviour, the warranty is void".

I don't necessarily agree, but if we have a way to avoid undefined behaviour (and at least in C there are ways to make pretty thorough checks), then it works in practice.

[ Parent | on HN ]

Re:Patch Critical Cryptographic Vulnerability in Microsoft W... by pjmlp on Thursday January 16, 2020 @03:12AM (#22062549)

The checks that according to most surveys and security reports are used by a tiny part of the C community?

If it doesn't work for C regarding mainstream adoption, how come it will work for Vulkan?

[ Parent | on HN ]

Re:Patch Critical Cryptographic Vulnerability in Microsoft W... by loup-vaillant on Thursday January 16, 2020 @07:56PM (#22070791)

It won't, unless only a fairly small elite ends up using Vulkan. And I believe that's what will happen indeed: Vulkan is low level enough that most likely, only engine devs and middleware devs will touch it.

You will of course have the occasional cowboy (which I personally am, though in a different domain), but that shouldn't matter that much in the grand scheme of things.

Now if you ask me, Vulkan is not enough. What we really want is a stable, usable hardware interface. Basically an ISA. The thing will have close to zero bug, because hardware folks know how to properly test their designs. Undefined behaviour is likely unavoidable, but I believe it can be reduced to a reasonable minimum.

If AMD and NVidia started something like RISC-V, except for graphics cards, it will likely have a greater impact than RISC-V itself.

[ Parent | on HN ]