[pjmlp]

> C-style programming in C++ is also a bad sign; the IOBuffer design pattern with separate storage of buffers and their sizes is inherently dangerous.

This the main take away. Even when writing C, just prefer safe libraries to default strings and arrays, when possible.

By the way, MSR is hiring for Checked C.

[ChuckNorris89]

>By the way, MSR is hiring for Checked C

Only internships ATM according to their web page

[Recursing]

https://github.com/Microsoft/checkedc#we-are-hiring

> We have positions available for a Principal Software Engineer and Senior Software Engineer. We are looking for engineers who have production compiler development experience and who value shipping software.

[pjmlp]

Internships aren't done for free, so it is still a job.

[aneutron]

While that is true, when one says "hiring", it generally refers to a somewhat "tenured" or "continued" position.

At least that's what I understood from your original comment.

[pjmlp]

Fair enough.

[xvilka]

There is no reason to spend time on any variant of C in the age of Rust.

[pjmlp]

Sure there is, as much as I dislike C, no one is going to port the existing UNIX and POSIX clones to something else.

And even then, many of those interfaces are based in C semantics anyway.

So anything that helps to reduce the amount of possible security exploits per line of C code is welcomed.

[acdha]

For new projects, sure. For existing projects, it's not trivial to convert them and anyone working on something significant is going to need time to do a migration during which additional new C code will almost certainly need to be written.

[xvilka]

It can be semi-automated with the amazing c2rust[1] tool.

[1] https://github.com/immunant/c2rust

[acdha]

“semi-” is not a synonym for “easily done with production-ready results”. Until that changes, people are going to need to write new C code even if they're working to refactor their code into a better language.

[fortran77]

Good point. We can do this in Go.