Re: [boost] [interprocess] Possible bug in offset_ptr

Subject: Re: [boost] [interprocess] Possible bug in offset_ptr
From: Lars Hagstrom (lars_at_[hidden])
Date: 2011-06-22 01:10:29

Right!

I tried my test code with boost trunk, and it works now! It seems that clang
defines __GNUC__, and therefore uses the newly added noinline code.

Thanks for the info! (And the fix that you'd already made...)

/Lars

2011/6/20 Ion Gaztañaga <igaztanaga_at_[hidden]>

> El 20/06/2011 9:14, Lars Hagstrom escribió:
>
>  Hi,
>>
>> I reported a problem to the clang project about a problem I had with some
>> release-compiled boost code.
>> They're claiming it is a problem in offset_ptr, where the pointer
>> arithmetic
>> causes undefined behaviour according to the C++ standard.
>> See: http://llvm.org/bugs/show_bug.**cgi?id=10119
>

>>
>> This seems like a fairly major thing, if it is true.
>>
>
> It is true, yes, it always has been outside the standard, but worked for
> all compilers. For aggressive optimizers, the only solution is to disable
> inlining so that the compiler is forced to create stack offset_ptr variables
> with real addresses, that's the solution I took in trunk. Windows compilers
> had this inlining disabled since ages (__declspec(noinline)) and GCC was
> recently added (__attribute__((noinline))).
>
> The fact is that with current standard, relative addressing is banned and I
> don't think there is workaround at all inside the standard. I think shared
> memory containers are not possible without visiting undefined behaviour.
>
> Best,
>
> Ion
> ______________________________**_________________
> Unsubscribe & other changes: http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>