[Bug libc/31657] New: __attribute__((pure)) etc. in installed headers

[Bug libc/31657] New: __attribute__((pure)) etc. in installed headers

[jakub at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31657

            Bug ID: 31657
           Summary: __attribute__((pure)) etc. in installed headers
           Product: glibc
           Version: 2.40
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: jakub at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

I see
grep __attribute__ `rpm -ql glibc-headers-x86` 2>/dev/null | grep -v '((__'
/usr/include/bits/types/res_state.h:                     
__attribute__((packed));
/usr/include/sys/platform/x86.h:     __attribute__ ((pure));
and can see it even on latest glibc trunk:
find [^o]* -name res_state.h | xargs grep __attribute__
resolv/bits/types/res_state.h:                    __attribute__((packed));
find [^o]* -name \*.h | grep /platform/ | xargs grep __attribute__
sysdeps/x86/sys/platform/x86.h:     __attribute__ ((pure));
Guess it should be __attribute_pure__ or __attribute__ ((__pure__)) and
__attribute__((__packed__)) instead for namespace reasons.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31657] __attribute__((pure)) etc. in installed headers

[jakub at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31657

--- Comment #1 from Jakub Jelinek <jakub at redhat dot com> ---
Using __attribute__((something)) is just fine in internal headers, but I think
should be avoided in installed headers.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31657] __attribute__((pure)) etc. in installed headers

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31657

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
<bits/types/res_state.h> is only used by <resolv.h>, both have a lot of
namespace violations, but they aren't part of any standard.

-- 
You are receiving this mail because:
You are on the CC list for the bug.