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

Groups > comp.lang.c > #101470

Re: Function pointers conversions and UB

Show key headers only | View raw

Noob <root@127.0.0.1> writes:
> Hello,
>
> Consider the following code:
>
> void foo(struct s *arg) { }
> void (*fp)(void *) = foo;
>
> As far as I understand, this does /not/ have UB, because fp is not used
> to call the function. Is that correct?

It violates a constraint.  There is no implicit conversion from one
pointer-to-function type to another.

> C99 6.3.2.3 p8
> "A pointer to a function of one type may be converted to a pointer to a function of another
> type and back again; the result shall compare equal to the original pointer. If a converted
> pointer is used to call a function whose type is not compatible with the pointed-to type,
> the behavior is undefined."

Yes, it "may be converted", but a cast is required.

This is valid and exhibits no undefined behavior:

    void foo(struct s *arg) { }
    void (*fp)(void *) = (void(*)(void*))foo;

(Presumably `struct s` is defined somewhere; otherwise it's not visible
outside the function definition, and it's going to be difficult to write
a meaningful call.)

> So the following code does have UB, correct?
>
> void foo(struct s *arg) { }
> void (*fp)(void *) = foo;

Again, assume a cast.

> void bar(void) { fp(); } /* nasal demons from fp() */

Actually that's another constraint violation -- but
    fp(NULL);
is legal (doesn't violate a syntax rule or constraint) and has undefined
behavior.

> I assume the behavior will be "it works as expected" on most platforms.
> How/where will it blow up?
>
> Platforms with different argument passing for void * and other pointers?
>
> I lack imagination... What else? Pointer representation/encoding?

A likely cause of the call not "working as expected" (which actually
depends a great deal on your expectations) is that you've passed
a pointer to an object that isn't properly aligned to point to a
`struct s` object.  Differing representations and argument passing
conventions are also possibilities (likely not to apply to most
current systems).  And compiler optimization could mess things up.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Function pointers conversions and UB Noob <root@127.0.0.1> - 2017-01-11 21:26 +0100
  Re: Function pointers conversions and UB "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-11 15:57 -0500
    Re: Function pointers conversions and UB supercat@casperkitty.com - 2017-01-11 14:37 -0800
  Re: Function pointers conversions and UB jt@toerring.de (Jens Thoms Toerring) - 2017-01-11 21:46 +0000
  Re: Function pointers conversions and UB Keith Thompson <kst-u@mib.org> - 2017-01-11 13:51 -0800
    Re: Function pointers conversions and UB "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-11 17:06 -0500
  Re: Function pointers conversions and UB Noob <root@127.0.0.1> - 2017-01-12 00:29 +0100
    Re: Function pointers conversions and UB Richard Heathfield <rjh@cpax.org.uk> - 2017-01-11 23:37 +0000
      Re: Function pointers conversions and UB supercat@casperkitty.com - 2017-01-11 21:49 -0800
        Re: Function pointers conversions and UB Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 09:41 +0000
      Re: Function pointers conversions and UB Noob <root@127.0.0.1> - 2017-01-12 10:52 +0100
        Re: Function pointers conversions and UB Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 09:58 +0000
  Re: Function pointers conversions and UB Noob <root@127.0.0.1> - 2017-01-12 13:08 +0100
    Re: Function pointers conversions and UB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-12 13:45 +0000

csiph-web