Defining the Undefinedness of C (2015) [pdf]

Re:Defining the Undefinedness of C (2015) [pdf] by pjmlp on Wednesday July 26, 2017 @12:58PM (#14857959)

C will always be around, unless we get rid of UNIX and POSIX compatibility layers.

Which given Microsoft's sudden love to stay relevant, means that we are at the edge of an UNIX monoculture.

So any improvement to make C safer is more than welcome.

My preference would be to have something like Frama-C be part of ANSI C.

[ Parent | on HN ]

Re:Defining the Undefinedness of C (2015) [pdf] by pcwalton on Wednesday July 26, 2017 @02:39PM (#14858924)

Virtually nobody who is not already using Frama-C would start using it as a result of it being added to ANSI C.

Ask industry C programmers "why aren't you using theorem provers to prove the correctness of your C code?" The number of them who will give you "because ANSI didn't standardize them" as an answer is zero.

[ Parent | on HN ]

Re:Defining the Undefinedness of C (2015) [pdf] by pjmlp on Wednesday July 26, 2017 @03:41PM (#14859498)

I know, but since we are not going to get any UNIX/POSIX variant out there replaced with C++, let alone Rust, we better get ways of improving its safety. Even it means just pilling up safety band-aids.

Even Microsoft caved in regarding not supporting C newer than C89, and now have on their Visual Studio roadmap to improve the C support beyond what ANSI C++ requires.

https://www.reddit.com/r/cpp/comments/6mqd2e/why_is_msvc_usu...

They also rewrote their User-Mode Driver Framework (UMDF) from COM/C++ back into C, https://docs.microsoft.com/en-us/windows-hardware/drivers/wd...

I am really looking forward to Joe Duffy's keynote at Rustcon, regarding systems programming improvements.

[ Parent | on HN ]