Re: [PATCH] Use __unused0 instead of __unused for user visible struct members

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Wed, Feb 8, 2012 at 10:38 AM, Guillem Jover <guillem@hadrons.org> wrote:
> On Wed, 2012-02-08 at 09:39:19 -0500, Carlos O'Donell wrote:
>> On Tue, Feb 7, 2012 at 5:41 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
>> >> This is probably my last mail on this issue, as it does not seem to be
>> >> going anywhere. Thanks Carlos for your perseverance, though!
>> >
>> > Actually, I think a rough consensus was reached: establish a convention
>> > __glibc_reservedN for padding fields and rename them all. ?See
>> > <http://sourceware.org/ml/libc-alpha/2012-02/msg00051.html> and followups.
>
> Ah, thanks!
>
>> Do you have time to publish another patch using the __glibc_ prefix?
>
> Yes, I have now an almost finished, but untested draft patch which does
> the following:

Thank you for looking through things!

> * Renames all __pad, __padN, __padded, __private_tm (this one might
> ?be controversial?), __unused, __unusedN symbols to __glibc_reservedN,
> ?where N starts at 1, because that was the prevalent starting index
> ?on the code base.

Yes.

Please also convert "__padding."

Please change "__private_tm" to "__glibc_private_tm"; the comment
clarifies that this field is reserved for a potential future Intel
Transactional Memory ABI implementation.

> * Renames the _HAVE_STAT___UNUSED<N> and _HAVE_STAT___PAD<N> type
> ?macros to _HAVE_STAT___GLIBC_RESERVED<N>.

No.

Roland already commented here that these must match the kernel headers.

> * Renames st_reserved and st_padto_ll to __glibc_reservedN (but those
> ?are only for the AIX struct stat, so see the next paragraph, and
> ?otherwise might be better left alone).

No.

... and hppa's struct stat for Linux.

Per the previous discussion that we want to maintain consistency with
Linux headers please leave this change out.

> * Renames the malloc_trim function argument from __pad to __glibc_pad,
> ?to avoid similar overlaps too.

Maybe?

Why does malloc.h use __pad as the argument while malloc.c uses pad,
what reason does glibc have to make the function declaration have
private names? I don't want to have to change all the other arguments
in malloc.h from __XX to __glibc_XX, but if that's what we should do
to avoid future issues, then we should do it. My other worry is that
this makes us different from the upstream ptmalloc upon which this is
based, but I think we are already sufficiently different that it
doesn't matter.

> While going through the code I found the following things:
>
> * _HAVE___UNUSED<N> and _HAVE___PAD<N> macros do not seem to be used
> ?anywhere (not even on ports), do you want them removed?

No.

See kernel headers discussion.

> * Is the stuff under sysdeps/unix/sysv/linux/powerpc/aix/ actually used
> ?anywhere? If not, do you want it removed too?

No.

... not right now, that's a separate cleanup patch which would be
welcome on it's own.

Cheers,
Carlos.