Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Calling a machine code/binary function given its address, return type, & parameter types Date: Sat, 17 Aug 2019 17:54:00 -0700 Organization: None to speak of Lines: 44 Message-ID: References: <66319c70-be79-466d-ba04-f8bb1b2d3a8a@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="9783fc84761b29b85f300e9e166573f7"; logging-data="31105"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18EU831HwfTK3ZQsKX1kfSx" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Dku39yoO6TIuJIVvxcxjZDkrjJA= sha1:ilj20dBNwo9/1YgmTOUZ4mBnSCM= Xref: csiph.com comp.lang.c:145707 Richard Damon writes: > On 8/17/19 6:10 PM, Keith Thompson wrote: >> David Williams writes: > ... >>> The platform is 64-bit Linux (x86-64). >> >> Others have discussed how you can do this *if it can be done*. But >> there is no way to do this in portable C. But since you're dealing with >> calling machine code routines, you're probably not too concerned about >> portability. > > Actually, since he knows the platform and that has been specified, he > probably only really needs portable on that platform. I am pretty sure > the ABI for that platform says that uintptr_t will exist and alias the > same type as uint64_t which I think is unsigned long long (not as sure > on that last point). Sure -- but if the OP really needs to use an integer type to represent a pointer value, using uintptr_t makes the code clearer. I often find that portable code is clearer than non-portable code, even if portability is not a concern. (Often, not always.) > I am also pretty sure that the platform ABI will define how casting that > type to a function pointer will work (Linux has needs for that operation > for things like share libraries, so they will define how it should work). > > Given that, assuming he is using a proper compiler for the environment, > it should work. Agreed. See POSIX dlsym(), for example, which assumes you can can convert a void* to a function pointer. But if you need to convert void* to a function pointer type, you should at least be aware that gcc will complain about it *if* you use certain options. (It also doesn't hurt to be aware that, at the very least, the C standard doesn't define the behavior.) Some of these issues don't apply to converting an integer to a function pointer. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */