Jason Merrill writes:
> On 12/14/2011 03:41 PM, Dodji Seketeli wrote:
>> @@ -8041,6 +8041,7 @@ joust (struct z_candidate *cand1, struct z_candidate
>> *cand2, bool warn)
>> {
>> conversion *t1 = cand1->convs[i + off1];
>> conversion *t2 = cand2->convs[i + off2];
>> + c
On 12/14/2011 03:41 PM, Dodji Seketeli wrote:
@@ -8041,6 +8041,7 @@ joust (struct z_candidate *cand1, struct z_candidate
*cand2, bool warn)
{
conversion *t1 = cand1->convs[i + off1];
conversion *t2 = cand2->convs[i + off2];
+ conversion *next_conv = next_conversion (t1
Jason Merrill writes:
> OK.
Thanks.
So here is the follow-up hardening patch that uses next_conversion
instead of touching conversion::u.next directly, for better safety and
maintainability.
Would this be OK for next stage 1?
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
OK.
Jason
Hello,
When we walk conversions, we need to be careful that the struct
conversion::u.next union field is the one that is active, depending on
the struct conversion::kind field.
In this bug for instance we are wrongly accessing conversion::u.next
when conversion::kind is a ck_list. Oops.
So I am
