[PATCH] [Object, MachO] Make MachO parser significantly more robust to invalid inputs.

[Alexey Samsonov]

Moved the discussion to llvmdev. I think I'll abandon this change, and will
proceed with small incremental changes, converting interface functions to
ErrorOr<> where necessary.

On Fri, May 29, 2015 at 2:44 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Fri, May 29, 2015 at 2:29 PM, Alexey Samsonov <vonosmas at gmail.com>
> wrote:
>
>>
>> On Fri, May 29, 2015 at 11:45 AM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, May 28, 2015 at 6:55 PM, Keno Fischer <
>>> kfischer at college.harvard.edu> wrote:
>>>
>>>> I don't really have a strong opinion either way, I just wanted to bring
>>>> it up as last time I touched this file a strong preference for moving
>>>> everything to ErrorOr was expressed in the review, because it's easy to
>>>> ignore the std::error_code.
>>>>
>>>
>>> *nod* I'll +1 this idea, but I haven't looked at these APIs to see how
>>> ingrained the options are. I also don't think there's a /huge/ cognitive
>>> overload to some inconsistency here, so I'd be willing to pay some
>>> inconsistency to move towards ErrorOr over error_code+out parameter.
>>>
>>
>> Hm... I'm kind of worried about the boilerplate on the caller side: there
>> are dozens of calls of these methods in LLVM tools.
>>
>
> I rather like APIs that are a little safer-by-design, but yes - it can add
> some verbosity. I'm not sure if there's a nice solution there.
>
> Internally, Google is still grappling with this problem (with similar
> abstractions to ErrorOr, error_code, etc), some people playing with macros
> to do it, etc. So it doesn't seem like there's a simple answer we're
> missing... (or at least if we've missed, so have a lot of other people,
> which is reassuring)
>
>
>> What do you think of using __attribute__((warn_unused_result)) instead?
>>
>
> ErrorOr should certainly have that attribute (as should std::error_code -
> problem is we can't put it on the standard library) - doing it on a
> per-function basis is a bit, similarly, error-prone and verbose.
>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>> http://reviews.llvm.org/D10111
>>>>
>>>> EMAIL PREFERENCES
>>>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>
>>>
>>>
>>
>>
>> --
>> Alexey Samsonov
>> vonosmas at gmail.com
>>
>
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150529/ff571b99/attachment.html>