This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]