This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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]

Re: don't assume reloc_addr passed to elf_machine_rel* is aligned


> I find explicit casts ugly, and I don't know whether every
> architecture I touched may have unaligned relocations.  

I was not suggesting introducing explicit casts in functions which had none
at all, but rather consistently using one cast instead of two (one
implicit, one explicit) in functions that do that after your patch.  To me
the ugliest of the options is to have an extra cast to a type that lets the
compiler validly produce broken code.  

> My patch was a syntactical-only change.

Ok.  I don't have sufficient knowledge of the aliasing rules or the
compiler's workings to be confident just from looking that they are in fact
guaranteed such.  But if you're quite sure they are, that's good enough for
me.  However, the "reloc_addr_" variable name is just too ugly.

> I was leaving it up to each arch's maintainer to figure out whether there
> were cases in which a compiler might be assuming too much from the
> implied alignment of the pointer, and adjust the code correspondingly.

It's more likely that one person making a single effort will be sure of all
the aliasing semantics in the compiler than that each machine maintainer
will be totally sure.  It's easy enough to notice machines where there is
certainly no alignment issue, such as i386 where all the stores do use the
same 32-bit type.  If the situation is not obvious enough by inspection for
another machine, we have this handy mailing list right here to get in touch
with all the maintainers.

> It didn't mean to fix any bug in any architecture

But you have a generous spirit much too large for us to have beaten it all
out of you yet.

> > Anyway, it's a bit unsightly and it's not so hard to modify each
> > machine's file that it can't be made prettier.
> 
> But then, the risk of breaking something would also increase.

In the abstract, yes.  But in fact you know the C rules, and so you know
whether a change imposes strictly fewer constraints on the set of
alignments guaranteed to work right if the compiler is not broken.


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