Bug 154179 - #include <asm/atomic.h> in userspace breaks
#include <asm/atomic.h> in userspace breaks
Product: Fedora
Classification: Fedora
Component: glibc-kernheaders (Show other bugs)
ia64 Linux
medium Severity high
: ---
: ---
Assigned To: David Woodhouse
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-04-07 20:36 EDT by Tom Lane
Modified: 2013-07-02 23:05 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-09 10:47:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom Lane 2005-04-07 20:36:34 EDT
Description of problem:
The inline ia64_atomic_add and ia64_atomic_sub functions in this header fail to compile under C++, 
because they use "new" as a variable name ... and it's a reserved word in C++.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Try to build mysql on ia64 :=(
Additional info:

Please rename these variables ASAP ... I need to get mysql rebuilt ...
Comment 1 David Woodhouse 2005-04-08 02:00:23 EDT
asm/atomic.c is a kernel-private header and may provide atomic operations which
do not work in userspace. It's perfectly entitled to not compile either. You
must not include it from userspace.
Comment 2 Tom Lane 2005-04-08 02:21:35 EDT
mysql has been depending on that header since 3.x days, and I doubt it's the only such app.

Shall I close all future mysql bugs as blocked by this one?

I'm not going to accept "I can't be bothered to respell 'new'" as an answer.
Comment 3 David Woodhouse 2005-04-08 02:39:20 EDT
There's never been any guarantee that if you include this kernel-private header
it'll build. And there's _certainly_ never been any guarantee that if it builds,
what it does will actually be atomic in _userspace_.

Seriously, if we change this header it'll just be to add

Comment 4 David Woodhouse 2005-04-09 10:47:18 EDT
I've had code which does *(((uint16_t *)p)++) for longer than that. Should I
file a compiler bug because it stopped working?

Note You need to log in before you can comment on or make changes to this bug.