uecker

Not sure what ELF and C type system has to do with this. C type information can be stored in ELF (as well as many other things). This is how a debugger can know the types. It is simply a language desi…

I like to add that WG14 accepted my comment into the current draft standard that clarifies that UB does - in fact - not invalidate the whole program, and can not affect observable behavior that comes …

Well, I use UB to let the compiler check for overflow. Works for me. https://godbolt.org/z/h3rvaz5Gn …

I personally like headers very much and do not understand the hate: They are super simple and efficient. They do not work well C++ though because it puts the implementation into the header for some re…

I do not think C's UB is damaging. As I said, you instruct the compiler to insert a trap and then it is not unsafe. Example: https://godbolt.org/z/Kvrrx19Pa The UB in the sp…

I think modular behavior at run-time is actively dangerous. It is not memory-unsafe, but still unsafe. Having it trap would better. For C, you can tell the compiler to trap for signed overflow.

For C, I tell my compiler to make it trap. Then it is also safe.

You can write correct programs with both. The reality is that people often fail to do this. But you can automatically detect signed overflow and protect against it, while unsigned wrap detected at run…

It is not evaluated for regular arrays. It is evaluated for arrays with variable size, you need to be careful a bit. But this is rarely happens to be a problem. The general rule for sizeof is to apply…

Please use those. They are useful, make code clearer, improve bounds checking, ... Don't let attackers influence the size of a buffer (neither for VLAs nor for heap allocations).

The advantage of using signed types is that you can reliably find overflow bugs using UBSan and protect against exploiting such errors by trapping at run time. For unsigned types, wrap-around bugs are…

I think fat pointers are relatively straightforward. VLAs and VMTs are now supported by many compilers (with some exceptions) even very small ones. Microsoft did - for a long time - not implement any…

I do not know for sure, but there are now more people in WG14 which care about safety, so I would say yes.

Attacker controlled sizes are always bad, this is also true for heap allocations. With stack clash protection this becomes a DOS for VLAs (same as for heap allocations). But I am not saying that VLAs…

It works because the type (char ( buf)[n]) knows the dynamic size 'n'. So the compiler can simply add the bounds check to an array access ( buf)[i] if instructed to do so. If you replace the…

We made variably modified types mandatory in C23. Compiler support for bounds checking is improving (via UBSan). Static analysis is improving (a bit). Flexible array members can now be secured using l…

The difference is that if there are there, you get consistent behavior across all compilers that support them. MSVC was essentially stuck with pre-C99 for a long time. So nobody in their right mind w…

Ah, thanks. I didn't know this proposal. I am trying to push similar things. The main obstacle are people coming from MSVC or C++ not knowing variably modified types and people being convinced th…

Just use array properly and you get run-time bounds checking: https://godbolt.org/z/4a45xq5hr (yes, a bit more compiler support is necessary to make this safe. I posted a patch t…

D has dynamic arrays which can be on the stack. At least it looks to me like this: https://godbolt.org/z/vTqMah569 I guess this depends on whether you count higher level language…

Yes, pointer + plus length is something else. C has variably modified types (in CS usually known as dependent types), where the length is encoded into the type. A VLA has a dependent type: char buf[n]…

VLA were not removed. VLAs are almost always better than the next best alternative: - They are better than alloca due to proper scoping and standard compliance. - They use less stack than regula…

We have no "end goal". PVNI-ae-udi is intended to capture the semantics of most existing C code. I mention terminology such as "exposure" etc. just because this makes it obvious …

I should also give a bit of background information, because I find it funny that some surface-level API for Rust is portrait as "solving" the problem in three months which C struggled for ye…

The "expose" mechanism as described in the document you linked to corresponds exactly to PVNI-ae-udi (including the "expose" terminology which was taken from N3005 or an earlier dr…

You realize that this experiment is basically our proposal translated to Rust? Also I wonder why it is an issue that N3005 is still a draft? Rust also does not have an ISO standard.

WG14 produced a document clarifying provenance in C (which Aria knew): https://open-std.org/JTC1/SC22/WG14/www/docs/n3005.pdf …

... >> Xpra shows that it could also work over low latency links if you have latency hiding which the X supports but because it is asynchronous but - again - toolkits never bothered >This is …

Well perceived as ancient and crufty. I do not think there is any genuine obstacle to progress. But the thing is not just that some crazy people got together and implemented something we could all u…

Forwarding after starting program or disconnecting would be entirely possible with X if toolkits supported it. I wrote a tool once which this for my own work. I also use ssh -X a lot from home to wor…