public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* GLIBC question
@ 2003-05-19 17:42 Denis Zaitsev
  0 siblings, 0 replies; only message in thread
From: Denis Zaitsev @ 2003-05-19 17:42 UTC (permalink / raw)
  To: gcc

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.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2003-05-19 17:40 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-19 17:42 GLIBC question Denis Zaitsev

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).