From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: Simon Marchi <simon.marchi@ericsson.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 4/4] Poison XNEW and friends for types that should use new/delete
Date: Thu, 23 Nov 2017 17:31:00 -0000 [thread overview]
Message-ID: <d8e9dbed-6956-e371-0fa9-abb0f9e60894@redhat.com> (raw)
In-Reply-To: <c225643d40ebb855e7779dfd0e462c00@polymtl.ca>
On 11/23/2017 05:27 PM, Simon Marchi wrote:
> On 2017-11-23 10:02, Pedro Alves wrote:
>> On 11/22/2017 04:41 PM, Simon Marchi wrote:
>>> From: Simon Marchi <simon.marchi@polymtl.ca>
>> The criterion I
>>> initially used to allow a type to use XNEW (which calls malloc in the
>>> end) was std::is_trivially_constructible, but then realized that gcc 4.8
>>> did not have it. Instead, I went with:
>>>
>>
>> Yeah, in the memset poisoning I just disabled the poisoning on older
>> compilers. This is the "#if HAVE_IS_TRIVIALLY_COPYABLE" check in
>> poison.h.
>
> I'm not sure if you are suggesting adding
> HAVE_IS_TRIVIALLY_CONSTRUCTIBLE, but since we can use std::is_pod
> easily, I think it's simpler just to use that (even if it's a bit more
> strict than needed).
Nope, I was really just stating a fact.
>>> which is just a bit more strict, which doesn't hurt. A similar thing is
>>> done for macros that free instead of allocated, the criterion is:
>>>
>>> using IsFreeable = gdb::Or<std::is_trivially_destructible<T>,
>>> std::is_void<T>>;
>>>
>>> For simplicity, we could also do for std::is_pod for IsFreeable as well,
>>> if you prefer.
>>>
>>> I chose to put static_assert in the functions, instead of using
>>> gdb::Requires in the template as SFINAE, because it allows to put a
>>> message, which I think makes the compiler error more understandable.
>>> With gdb::Requires, the error is:
>>
>> Right, I think static_assert is what I had suggest initially too.
>> SFINAE alone wouldn't sound right to me here.
>>
>> The right alternative to static_assert would be SFINAE+"=delete;",
>> which is what we do for the memcpy/memcpy poisoning, and what
>> you're doing to "free".
>>
>> =delete keeps the function/overload in the overload set, serving
>> as "honeypot", so you get an error about trying to call a
>> deleted function.
>>
>> You could do that to xfree instead
>> of the static_assert, but I guess inlining xfree ends up being
>> a good thing.
>
> Ah yeah, it would probably make the message a bit clearer. Instead of
> saying "I can't find a function that matches", it would say "I found a
> function that matches, but you can't use it".
Exactly.
> I'll just keep
> static_assert for xfree as well, since it ends up clearer anyway.
*nod*
>> Other than the formatting, this LGTM. Thanks a lot for doing this.
>
> Thanks, I'm glad that I won't have to carry that branch on the side
> anymore :)
>
:-)
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-11-23 17:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-22 16:41 [PATCH 0/4] Poison XNEW and friends for non-POD types Simon Marchi
2017-11-22 16:41 ` [PATCH 1/4] Create private_inferior class hierarchy Simon Marchi
2017-11-22 22:20 ` Joel Brobecker
2017-11-24 15:46 ` Simon Marchi
2017-11-24 21:31 ` Joel Brobecker
2017-11-23 14:09 ` Pedro Alves
2017-11-23 16:17 ` Simon Marchi
2017-11-22 16:42 ` [PATCH 2/4] remote: C++ify thread_item and threads_listing_context Simon Marchi
2017-11-23 14:22 ` Pedro Alves
2017-11-23 16:48 ` Simon Marchi
2017-11-23 16:52 ` Pedro Alves
2017-11-22 16:42 ` [PATCH 4/4] Poison XNEW and friends for types that should use new/delete Simon Marchi
2017-11-23 15:02 ` Pedro Alves
2017-11-23 17:27 ` Simon Marchi
2017-11-23 17:31 ` Pedro Alves [this message]
2017-11-22 16:42 ` [PATCH 3/4] Create private_thread_info hierarchy Simon Marchi
2017-11-23 14:41 ` Pedro Alves
2017-11-23 16:54 ` Simon Marchi
2017-11-23 16:56 ` Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d8e9dbed-6956-e371-0fa9-abb0f9e60894@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@ericsson.com \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox