This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
GLIBC question
- From: Denis Zaitsev <zzz at cd-club dot ru>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 19 May 2003 23:20:43 +0600
- Subject: GLIBC question
Below are the couple of mails from glibc list regarding the inline
i386 string code (sysdeps/i386/i486/bits/string.h in the glibc source
tree). First is my letter:
> So, just everyhere we have (for now) something like
>
> "m" ( *(struct { char __x[0xfffffff]; } *)__str)
>
> in the input parameters list. The question is: why 0xfffffff is used?
> Would 0x7fffffff be better? As it describes all the usable memory,
> not just 1/8 part of it.
>
> And would it be better to use some macros for this, like:
>
> "m" (*(ALL_MEM*)__str)
>
> along with, say:
>
> "m" (*(PART_MEM(__len)*)__mem)
>
> for __mem[__len] parameters. It seems to be more readable and more
> convinient and more etc. I would like to implement this, if the idea
> in general is sane.
And the second is the Ulrich Drepper's answer:
> I don't think there is any reason why we use 0xfffffff instead of
> 0xffffffff. Maybe some gcc version complained, but I don't remember any
> such problem.
>
> Cleaning these things up would certainly be nice. If you want to work
> on this I consider talking to the gcc about their preference and maybe
> define the macros you proposed in a compiler version-specific way.
So, any comments concerning this memory description would be healthy.
Thanks in advance.