FreeType 2.10.4 Rushed Out As Emergency Security Release

[phoronix]

Phoronix: FreeType 2.10.4 Rushed Out As Emergency Security Release

The FreeType text rendering library is out with version 2.10.4 today as an important security update...

http://www.phoronix.com/scan.php?page=news_item&px=FreeType-2.10.4-Released

[uid313]

Maybe FreeType or parts of it should be rewritten in Rust to avoid these buffer overflow problems.

[Alexmitter]

Maybe FreeType or parts of it should be rewritten in Rust to avoid these buffer overflow problems.

I still think Go is the better rewrite everything in it hype bubble language.

Jokes aside, Rust is currently not compilable via GCC, so its a instant fail.

[ultimA]

Just modern C++ would make much more sense. Modern C++ with its smart pointers, containers and std::array/span offers the same memory-safety as Rust, all the while allowing a gradual rewrite, and without having to learn a completely new language.

Rust is not a magic bullet to bugs people. Program logic bugs are a much larger problem and Rust won't help you at all with those. As for the stuff that Rust does help with, there are many other languages that offer the same kind of type- and array-safety as Rust. Granted, it also offers some additional checks and guarantees with regards to multi-threading, but that is almost never an issue with foundation-type libraries such as FreeType (and in fact, FreeType would not profit from it at all).

[uid313]

I still think Go is the better rewrite everything in it hype bubble language.

Jokes aside, Rust is currently not compilable via GCC, so its a instant fail.

I think Go is for different things than Rust.
I think maybe Rust is good for security and robustness. Go is good for make everything into one statically compiled file. Maybe Go is good for distributed applications too.

[uid313]

Just modern C++ would make much more sense. Modern C++ with its smart pointers, containers and std::array/span offers the same memory-safety as Rust, all the while allowing a gradual rewrite, and without having to learn a completely new language.

Rust is not a magic bullet to bugs people. Program logic bugs are a much larger problem and Rust won't help you at all with those. As for the stuff that Rust does help with, there are many other languages that offer the same kind of type- and array-safety as Rust. Granted, it also offers some additional checks and guarantees with regards to multi-threading, but that is almost never an issue with foundation-type libraries such as FreeType (and in fact, FreeType would not profit from it at all).

Rust also doesn't suffer from null problems because it has no null value, instead if has an Option<T> and Result<T> enum. Also it has lifetime declarations so it automatically frees memory. It also has ownership of values, so something else cannot modify a variable when it is owned by something else.

[ultimA]

Rust also doesn't suffer from null problems because it has no null value, instead if has an Option<T> and Result<T> enum. Also it has lifetime declarations so it automatically frees memory. It also has ownership of values, so something else cannot modify a variable when it is owned by something else.

Now you're just talking without knowing C++ (or you do know it but just being bigotic about Rust).

> instead it [Rust] has an Option<T>and Result<T>
C++ too, see std:: optional and/or std::variant

> Also it has lifetime declarations so it automatically frees memory
C++ too, see smart pointers

> It also has ownership of values
C++ too, see non-copyable classes (and std::unique_ptr is non-copyable btw, so it ties nicely into ownership using smart-pointers and automatic lifetime management)

> So something else cannot modify a variable
C++ too, ever heard of const?

>Rust also doesn't suffer from null problems because it has no null value
It has no null value? Then I wonder what Ptr::null() or cpp_utils::NullPtr are for in Rust... Having to or not having to deal with nulls is not a language feature but a design-choice of the code author. In both Rust and C++ you can produce nulls and then you need to deal with them, or you can decide not to produce nulls in your code and then you don't suffer from them. But given that most existing and wide-spread libraries use null-pointers to a heavy extent (including even but not only OS interfaces such as POSIX or WinAPI), it would be a fatal mistake even in Rust to completely ignore nulls. All you can do is to decide not to produce nulls in your own code, which is easily possible in C++ too.

[HadrienG]

Just modern C++ would make much more sense. Modern C++ with its smart pointers, containers and std::array/span offers the same memory-safety as Rust, all the while allowing a gradual rewrite, and without having to learn a completely new language.

This is false.

For a simple counter-example, iterator invalidation is a very common C++ memory safety bug, that no amount of modern C++ magic will save you from.

As a less tongue-in-cheek answer, rewriting code in modern C++ is effectively the same amount of work as rewriting it in a whole new language, since there simply aren't that much foundational libraries / existing projects written in modern C++, and claiming that your code is super-safe C++20 while most of your codebase is actually written in C++98 style is just luring yourself into a false sense of safety.

(For what it's worth, the latter problem also exists in Rust code that binds to old-style C++ or C libraries, which is why the "rewrite old codebases in X safe language" meme is a thing at all.)

The "without having to learn a completely new language" argument is similarly dubious. So many changes have been hacked into the C++11/14/17/20 standards that learning and mastering them is effectively the same amount of work as learning two well-designed programing languages from scratch.

Conversely, gradual rewrites of existing libraries into a more modern style or language is just as much of a thing in Rust as it is in C++. It's how most "rewrite X in Rust" projects are done, if I am to trust the written accounts thereof that I've found on the web (I'm personnally not that much into the idea of rewriting healthy codebases, I understand why it's done but I feel the costs often outweight the benefits).

[HadrienG]

Now you're just talking without knowing C++ (or you do know it but just being bigotic about Rust).

Replying as someone who uses C++ daily at work and has spent way too much time getting comfortable with the intricacies of the recent standards for my own good...

> instead it [Rust] has an Option<T>and Result<T>
C++ too, see std:: optional and/or std::variant

std:: optional is indeed very neat and could use more love. Hopefully it will get some as codebases move to C++17, but given how good C++11 adoption has been so far, I wouldn't bet on a large-scale movement in that direction.

std::variant, on the other hand, is a terrible hack that is only good for bragging "hey we have some kind of algebraic data type in C++" and should never be used in real code. Code that uses it is a poor shadow of what it would be in an ML-like language with first-class support for tagged unions and pattern matching, for multiple reasons :

• Since variants aren't named, but only referred to by index or by type, the self-documentation of code is very poor.
• Referring to variants by type is fragile since a type may occur multiple times within a variant (e.g. imagine a type which describes network endpoints, you would need an (IP, port) variant data payload for both TCP and UDP protocols). Referring to variant by index is fragile since adding or removing a variant will break the code in a way which is much harder to fix than in programming languages where variants are named explicitly (compiler error messages will be much worse).
• std::visit is a mess. Writing a single lambda with auto params that handles all cases of the variant leads to vobscure logic when the different inner types of the variant have different semantics (as in the Result<T, E> case) and writing each case as a separate function in a functor class means much boilerplate and unpleasant nonlinear control flow even for very simple branching code.
• ...and to those who would still thing that the abomination featured on the https://en.cppreference.com/w/cpp/utility/variant/visit page is reasonable, consider the case of matching two nested variants. This leads to callback soup, whereas the equivalent is straightforward in languages with proper first-class algebraic data type and pattern matching support.

> Also it has lifetime declarations so it automatically frees memory
C++ too, see smart pointers

Both you and the OP are misunderstanding what Rust's lifetime annotations are doing. They are not about automatic memory allocation/liberation (which are handled via RAII in Rust, just like in C++), they are about proving the absence of dangling pointers and UAF at compile time when handing out references to preallocated data, in such a manner that changing the implementation of a function without changing its signature will never break its API.

> It also has ownership of values
C++ too, see non-copyable classes (and std::unique_ptr is non-copyable btw, so it ties nicely into ownership using smart-pointers and automatic lifetime management)

I agree with you here, C++ was there first and did the hard work of formalizing ownership while designing C++11, let's give the original author credit here.

I must add, though, that by virtue of coming much later and with experience of lessons learned from C++, Rust can integrate the notion of ownership better than is done in C++. For example, movable values in Rust do not need a "null state", as is necessary in C++, because the compiler is smart enough not to destroy a value which has been moved away. And the Rust compiler can correctly flag use-after-move as an error, something which to my surprise I still haven't seen a C++ compiler do to date even at maximal warnings level. Finally, non-copyable types are much more ergonomic in Rust than in C++, since moves are the default (whereas a C++ codebase with non-copyable types often sees its core logic drowned in a sea of std:: move noise).

> So something else cannot modify a variable
C++ too, ever heard of const?

Const in C++ is unfortunately a bit of a lie. As long as you can const_cast it away (and I see people regularly do so, either due to a misunderstanding of the "const means thread-safe" motto or due to the general complexity of correctly initializing an object that contains const pointers), it does not help compiler optimization and can mislead programmer reasoning. It is therefore a much less powerful property than Rust's immutability, where the possibility of "internal mutation" still exists but is not on by default and must instead be explicitly opted into at type declaration time.

>Rust also doesn't suffer from null problems because it has no null value
It has no null value? Then I wonder what Ptr::null() or cpp_utils::NullPtr are for in Rust... Having to or not having to deal with nulls is not a language feature but a design-choice of the code author. In both Rust and C++ you can produce nulls and then you need to deal with them, or you can decide not to produce nulls in your code and then you don't suffer from them. But given that most existing and wide-spread libraries use null-pointers to a heavy extent (including even but not only OS interfaces such as POSIX or WinAPI), it would be a fatal mistake even in Rust to completely ignore nulls. All you can do is to decide not to produce nulls in your own code, which is easily possible in C++ too.

While the original statement is indeed incorrect (you need nullable pointers in order to interact with Unix OSes at a low level ), it is true that nullable values are a much rarer occurence in Rust that in C++, due to a variety of factors :

• As already mentioned above, Rust destructors are not run on moved values, so there is no need for all movable types to provide a null state.
• Rust's reference type, which is much more commonly used in idiomatic code than raw pointers for obvious reasons, does not have a null state. Such a null state must be opted into via Option<T>. Therefore, for convenience reasons Rust APIs tend to use "typestate" patterns where APIs accept or provide nullable references, the presence of nulls is checked once in the code, and then the underlying reference is unpacked and the rest of the code can operate under the assumption that the reference is non-null.
• Safe Rust forces people to check for null on nullable types before using the inner value, which is a good thing in general. It does also make nullable types harder to use, which discourages people from using them everywhere.
• And unlike C++'s std:: optional, Rust's Option<T> comes with smart compiler optimizations that can effectively turn an Option<&T> into a *mut T under the hood. So no performance price is paid for using optional non-nullable types over nullable types.

[zxy_thf]

Just modern C++ would make much more sense. Modern C++ with its smart pointers, containers and std::array/span offers the same memory-safety as Rust, all the while allowing a gradual rewrite, and without having to learn a completely new language.

For some reason Idk I feel lots of Linux system library developers only want to use C, even if its C implementation would be very verbose in today's view.