addressed in the same way glibc typically
addresses such compatibility concerns: creating a new symbol-version for
the new bcmp implementation, with the previous bcmp symbol-version
remaining as a memcmp alias.
> On Thu, Sep 16, 2021 at 2:43 PM Joseph Myers
> wrote:
>
>> On Thu,
Wouldn't it be far simpler to just un-deprecate bcmp?
On Thu, Sep 16, 2021 at 1:04 PM Noah Goldstein
wrote:
> Hi All,
>
> This is a proposal for a new interface to be supported by libc.
>
> The new interface is the same as the old 'bcmp()' routine. Essentially
> the goal of this proposal is to a
No, you really don't need undefined behavior in the standard in order
to enable bug-finding.
The standard could've (and still could...) make signed integer
overflow "implementation-defined" rather than "undefined". Compilers
would thus be required to have *some documented meaning* for it (e.g.
wra
> It seems to be an inadvertent incompatibility caused by the
> interaction of a libstdc++ workaround for a bug and g++ behaviour that
> may not have been known to the libstdc++ devs, so not something that
> could have been prevented by making it a linker error, because noone
> knew it was even bro
> On 31 May 2012 22:35, James Y Knight wrote:
>> I understand that the ABI changes generally cannot be avoided, but a lot
>> of pain for a lot of people could be avoided by making things fail
>> obviously with a link error, instead of sometimes, arbitrarily, if
>> yo
You've missed at least one ABI incompatibility in GCC 4.7 and later, as
demonstrated in real life by (at least) libboost_python, and distilled
into this test case.
At least these bug reports are probably caused by this ABI incompatibility:
https://svn.boost.org/trac/boost/ticket/6919
http://gcc.gn
I just noted at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 (due to
std::list), that it's currently impossible to use any C++11-compiled code
in a program which also uses any C++98 code, even if the two pieces of
code never actually touch each other or share objects. After I noted that,
paolo
