* 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).