> From: "Brian Smith" <br...@briansmith.org>
>
> C++ desperately needs improvements for reducing the occurrence of
> use-after-free errors. Rust features for this like borrowed references
> should be imported into the language. A real-life (but reduced/modified)
> example from mozilla::pkix:
>
> Result parse(const std::vector<uint8_t>& der)
> {
> Input input(der);
> uint8_t b;
> if (input.Read(b) != Success) {
> return Failure;
> }
> ....
> return Result;
> }
>
> It should be possible to ensure that, no matter what the Input class does
> with the argument in its constructor, there will be no references to the
> "der" parameter that outlive the scope of the function. Right now this is
> impossible to specify in C++.
I'd like to understand this better.
Do you mean that if the constructor of 'input' saves a reference or pointer
to 'der' in a place where it will not go out of scope when 'input' does,
the compiler should give an error at the call site of the constructor in
this function?
> Discriminated unions (Boost.Variant or better) are another safety feature
> that would be very useful to have in Standard C++.
An "optional" class, heavily inspired by Boost.Optional, has been accepted
into the Library Fundamentals Technical Specification, which is expected to
be published early next year.
While I'm not aware of any concrete plans, I don't image a variant class
will be far behind.
> There should be a way to indicate in a switch statement whether you intend
> to cover all the cases:
>
> enum A { a, b, c };
>
> switch (x) {
> case a:
> return true;
> case b:
> return false;
> }
>
> There needs to be a way to tell the compiler to reject this switch
> statement because it doesn't cover all the cases. To work around the lack
> of that feature, we end up writing:
>
> switch (x) {
> case a:
> return true;
> case b:
> return false;
> case c:
> return false;
> default:
> PR_NOT_REACHED("unexpected case"); // or...
> MOZ_CRASH("unexpected case");
> }
>
> But, that's turning a statically-detectable error into a potential runtime
> crash, unnecessarily. Currently, we can mess with compiler warnings
> settings to catch these but that isn't good enough.
I'd very much like to see this as well!
The C++11 attribute syntax might be a good way to accomplish this without
inventing new syntax. For example, the standard could define an "exhaustive"
attribute on a switch statement for an enumeration:
enum A { a, b, c };
A x;
...
switch (x) [[exhaustive]] {
case a:
return true;
case b:
return false;
} // error: 'c' is not handled
I'll find out if something like this has ever been discussed.
Assuming that this hasn't been already discussed and passed up for some
technical reason, it's very much possible that all that is required for
something like this to be standardized is for someone to write a paper
proposing it, and someone to present it at a committee meeting. I'd
gladly do the second task, and help someone with the first.
> Large parts of the standard library are unusable or nearly unusable when
> exceptions are disabled, such as the standard containers. Sometimes they
> can be used if the default allocator is changed to abort on out-of-memory,
> but often abort-on-OOM is not what you want. Thus, much (most?) Gecko code
> cannot use a huge part of the standard library. For example, it should be
> made possible to call std::resize() when exceptions are disabled and
> without triggering abort-on-OOM, such that the caller can detect when the
> resize fails. Similarly, it should be possible to attempt to append an
> element to std::vector without an exception being throw or the process
> being aborted on failure, but with the error still detectable.
>From what I've heard at committee meetings, the dominant opinion on this
topic seems to be that, since exceptions are part of the standard language,
library writers shouldn't have to go out of their way to cater to people
who don't use them.
That said, there are some libraries which have an option to use an error
code instead of an exception for error handling. I'm thinking in particular
of the Filesystem TS [1].
I'll try to find out some more concrete information on this topic.
> std::shared_ptr is mostly unusable in Gecko code because there's no way to
> specify whether you need thread-safety or not (usually you don't). There
> should be a way to specify whether you want to pay the cost of thread
> safety when using it.
I would like to see this as well.
> The language should define a solution for the build time problems that we
> work around with UNIFIED_SOURCES, so that we don't have to use
> UNIFIED_SOURCES any more.
Modules [2] aim to solve this class of problems.
> In general, I'd rather have the committee focus more on safety and
> correctness of code by improving the core language and core libraries,
> rather than standardizing APIs like graphics.
The committee is mostly made up of volunteers who spend their time on
proposals that they care about / are interested in. Standardizing a
graphics API does not necessarily take away time from improving the
core language and core libraries (which, to be sure, is a task others
in the committee are still working on!).
> Cheers,
> Brian
Thanks for your input! I'll ask around about the topics you brought up
and hopefully have more informative replies after the meeting.
Cheers,
Botond
[1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3940.html
[2] http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4047.pdf
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
