Bug 154179 - #include <asm/atomic.h> in userspace breaks
Summary: #include <asm/atomic.h> in userspace breaks
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc-kernheaders
Version: rawhide
Hardware: ia64
OS: Linux
medium
high
Target Milestone: ---
Assignee: David Woodhouse
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-08 00:36 UTC by Tom Lane
Modified: 2013-07-03 03:05 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-04-09 14:47:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tom Lane 2005-04-08 00:36:34 UTC
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):
glibc-kernheaders-2.4-9.1.90

How reproducible:
100%

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

Please rename these variables ASAP ... I need to get mysql rebuilt ...

Comment 1 David Woodhouse 2005-04-08 06:00:23 UTC
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 06:21:35 UTC
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 06:39:20 UTC
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
#error KERNEL PRIVATE THINGS HERE. 



Comment 4 David Woodhouse 2005-04-09 14:47:18 UTC
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.