tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Cleanups


From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] Cleanups
Date: Tue, 5 Feb 2013 14:56:12 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

Le lundi 4 février 2013 20:51:29, grischka a écrit :
> Thomas Preud'homme wrote:
> >> 1) too many warnings "conversion from/to ptr <-> integer of different
> >> size"
> >> 
> >> http://repo.or.cz/w/tinycc.git/commitdiff/82bcbd027f100d7601c6139e93e1f6
> >> 9a 9cc46244
> > 
> > Why some uplong were replaced by uintptr_t?
> 
> Well, that is with
>    LIBTCCAPI int tcc_add_symbol(TCCState *s, const char *name, const void
> *val); to convert
>    void *val -> elf-address.
> 
> Because
> 1) I wanted to keep "void* val" in the prototype because it is LIBTCCAPI.
> 2) It is not TCC_IS_NATIVE only.
> 
> So basically someone could use
> - an i386-libtcc.a (cross-compiler) made on x86-64
>    with addr_t(32) and void*(64), or
> 
> - an x86_64-libtcc.a (cross-compiler) made on i386/arm
>    with addr_t(64) but void*(32)
>    Which still wont work if the upper 32 bits are used, which
>    they usually aren't as long as no relocation was made, but
>    I'm not sure.
> 
> Of course you can't run something with such libtcc.a but you
> could still use tcc_output_file.
> 
> Technically perfect would be to change the prototype to accept
> a target address sized integer (addr_t).  Respectively return
> with tcc_get_symbol which has a similar problem.
> 
> But this then requires casts in the user code (e.g. libtcc_test.c)
> and probably would make some people cry.
> 
> --- grischka

It makes perfect sense. Thanks for the explaination.

Thomas

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]