Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #384065
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Casting the return value of ... |
| Date | 2024-03-28 18:16 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <20240328105203.773@kylheku.com> (permalink) |
| References | <uu416t$33u55$1@news.xmission.com> |
On 2024-03-28, Kenny McCormack <gazelle@shell.xmission.com> wrote: > But here's the thing. Is the casting of the result of dlsym() > [to a function pointer type] necessary? > Isn't this the same as "casting the return value of malloc()", where you Conversions between function pointers and data pointers are an extension; it is not well-defined behavior in ISO C. Therefore we can neither say that ISO C doesn't require a cast there (it imposes no requirements at all), nor that the conversion is fine with a cast. The cast is /likely/ necessary, in order to correctly trigger the extension. > But here's where it gets interesting. In the man page for dlopen(), we > find this example code and a long detailed comment: The "Linux Programmer's Manual" man pages are often lacking in technical precision, and even contain rants (see regex(7)). > *(void **) (&cosine) = dlsym(handle, "cos"); > > This (clumsy) cast conforms with the ISO C standard and will > avoid any compiler warnings. It does not conform! The address of a pointer-to-function object is type punned to look like a "void *", and assigned. It breaks aliasing rules. It does not use the extension of converting between function and object pointers; it's relying on punning them. For it to be 100% correct, there has to be a compiler extension to support the punning that it is doing, and function and object pointers have to have the same representation. > The 2013 Technical Corrigendum to POSIX.1-2008 (a.k.a. > POSIX.1-2013) improved matters by requiring that conforming > implementations support casting 'void *' to a function pointer. I also seem to remember something like this, but I cannot trust this documentation without a chapter-and-verse citation. Assuming it is true, there you have it; if you're on POSIX, the compiler is required to have the extension and it is connected to casting, in which case the cast is required. > And why do we even need the "clumsy" cast? Why not just: > > cosine = dlsym(handle, "cos"); Because of the man page author's goal of eliminating a warning from GCC. I think there was a time in the development of GCC when there was a warning even with the cast. I don't think it's enabled by default now? (I seem to recall that, a number of years ago, the GCC goofballs, in fact, merged a change that caused the compiler to generate a run-time abort in code that converted function/object pointers. It was turned on by default. It had to be backpedaled due to all the screaming from downstream distros. Am I hallucinating that?) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
Casting the return value of ... gazelle@shell.xmission.com (Kenny McCormack) - 2024-03-28 15:09 +0000
Re: Casting the return value of ... Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-28 18:16 +0000
Re: Casting the return value of ... scott@slp53.sl.home (Scott Lurndal) - 2024-03-28 18:53 +0000
Re: Casting the return value of ... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-30 10:33 -0700
Re: Casting the return value of ... scott@slp53.sl.home (Scott Lurndal) - 2024-03-30 19:29 +0000
Re: Casting the return value of ... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-30 23:05 +0000
Re: Casting the return value of ... scott@slp53.sl.home (Scott Lurndal) - 2024-03-30 23:25 +0000
Re: Casting the return value of ... David Brown <david.brown@hesbynett.no> - 2024-03-31 15:44 +0200
Re: Casting the return value of ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-31 13:15 -0700
Re: Casting the return value of ... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-08 23:01 -0700
Re: Casting the return value of ... David Brown <david.brown@hesbynett.no> - 2024-04-09 10:03 +0200
Re: Casting the return value of ... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-28 12:38 -0700
Re: Casting the return value of ... bart <bc@freeuk.com> - 2024-03-28 20:30 +0000
Re: Casting the return value of ... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-28 14:07 -0700
Re: Casting the return value of ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-28 14:15 -0700
Re: Casting the return value of ... Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-28 21:44 +0000
Re: Casting the return value of ... Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-28 22:01 +0000
Re: Casting the return value of ... Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-28 22:33 +0000
Re: Casting the return value of ... Michael S <already5chosen@yahoo.com> - 2024-03-29 15:53 +0200
gcc Bugzilla search (was: Casting the return value of ...) Michael S <already5chosen@yahoo.com> - 2024-03-29 16:01 +0200
Re: gcc Bugzilla search David Brown <david.brown@hesbynett.no> - 2024-03-29 17:00 +0100
Re: Casting the return value of ... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-28 15:37 -0700
Re: Casting the return value of ... David Brown <david.brown@hesbynett.no> - 2024-03-29 14:06 +0100
Re: Casting the return value of ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-29 15:46 -0700
Re: Casting the return value of ... David Brown <david.brown@hesbynett.no> - 2024-03-29 13:58 +0100
Re: Casting the return value of ... bart <bc@freeuk.com> - 2024-03-29 13:32 +0000
Re: Casting the return value of ... David Brown <david.brown@hesbynett.no> - 2024-03-29 17:10 +0100
Re: Casting the return value of ... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-30 02:32 -0700
Re: Casting the return value of ... bart <bc@freeuk.com> - 2024-03-30 11:14 +0000
Re: Casting the return value of ... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-08 23:41 -0700
Re: Casting the return value of ... Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-03-28 21:41 -0700
Re: Casting the return value of ... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-28 22:02 -0700
Re: Casting the return value of ... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-29 15:52 -0700
csiph-web