Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #384065

Re: Casting the return value of ...

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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