This is an archive of the discontinued LLVM Phabricator instance.

Check that memory allocation succeeds before use.
Needs ReviewPublic

Authored by trixirt on May 24 2018, 7:13 AM.

Details

Reviewers
pete
sanjoy
Summary

Check that memory allocation succeeds before use.
Rename variable DescInfo to DI for consistency.

Diff Detail

Repository
rL LLVM

Event Timeline

trixirt created this revision.May 24 2018, 7:13 AM
labath added a subscriber: labath.May 24 2018, 7:47 AM

Isn't this just dead code? a non-nothrow new will never return null http://en.cppreference.com/w/cpp/memory/new/operator_new

I will change this to try-catch

I will change this to try-catch

We don't use exceptions in LLVM.

Can you elaborate on what the bigger picture is? LLVM is *not* robust against allocation failures, and fixing just this bit won't change anything.

trixirt updated this revision to Diff 148462.May 24 2018, 12:17 PM

use nothrow version of new

As llvm is mostly an api, i assumed that it would be robust and this was a one-off.
Anything big should be done automagically, so i am going to look at sic-ing clang-tidy and/or the static analyzer at this problem.

The lack of exception handling i can understand for performance reasons but it does put normal use of the std library in a bind if like this case the default uses exceptions.

It would be nice if there was project wide design on how to handle exceptions/errors.
If there is please point me at it.

As llvm is mostly an api, i assumed that it would be robust and this was a one-off.
Anything big should be done automagically, so i am going to look at sic-ing clang-tidy and/or the static analyzer at this problem.

Before spending time on this, I'd suggest asking on llvm-dev@ about whether we _should_ make LLVM robust against allocation failures. I believe (but you should still ask) the consensus will be that it isn't worth the engineering complexity to make LLVM as a library robust against allocation failures, and that if you do want this, the right fix is to fork out to LLVM as a separate process.

The lack of exception handling i can understand for performance reasons but it does put normal use of the std library in a bind if like this case the default uses exceptions.

It would be nice if there was project wide design on how to handle exceptions/errors.
If there is please point me at it.

https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions

I agree on the consensus building.

However I can see the problem of default new not returning nullptr being a general problem.
So something automagic needs to be created if it doesn't exist already.

sanjoy resigned from this revision.Jan 29 2022, 5:30 PM