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

Groups > comp.lang.c++ > #118835 > unrolled thread

Proper cast of function pointers

Back to article view | Back to comp.lang.c++

Contents

  Proper cast of function pointers Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-23 14:31 +0300
    Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-23 13:44 +0200
      Re: Proper cast of function pointers Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-23 21:33 +0300
        Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-24 09:33 +0200
        Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-24 09:36 +0200
          Re: Proper cast of function pointers Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-24 15:32 +0300
            Re: Proper cast of function pointers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-24 15:10 -0700
              Re: Proper cast of function pointers "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-24 15:14 -0700
              Re: Proper cast of function pointers Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-25 08:37 +0300
                Re: Proper cast of function pointers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-25 15:04 -0700
            Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-25 11:19 +0200
              Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-25 11:39 +0200
                Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-25 11:48 +0200
                  Re: Proper cast of function pointers Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-25 22:22 +0300
                    Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-26 07:52 +0200
        Re: Proper cast of function pointers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-24 14:40 -0700
    Re: Proper cast of function pointers Markus Schaaf <mschaaf@elaboris.de> - 2024-04-23 14:23 +0200
      Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-23 16:44 +0200
        Re: Proper cast of function pointers Markus Schaaf <mschaaf@elaboris.de> - 2024-04-23 17:00 +0200
          Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-24 09:55 +0200
          Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-24 13:11 +0200
            Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-24 13:15 +0200
        Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-24 13:10 +0200
          Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-24 13:23 +0200
            Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-24 17:06 +0200
              Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-24 17:59 +0200
                Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-24 19:36 +0200
      Re: Proper cast of function pointers Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-23 21:50 +0300
        Re: Proper cast of function pointers Markus Schaaf <mschaaf@elaboris.de> - 2024-04-23 22:18 +0200
          Re: Proper cast of function pointers Markus Schaaf <mschaaf@elaboris.de> - 2024-04-23 22:22 +0200
          Re: Proper cast of function pointers Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-23 23:33 +0300
    Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-23 16:44 +0200
      Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-24 11:27 +0200
        Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-24 13:14 +0200
          Re: Proper cast of function pointers Bo Persson <bo@bo-persson.se> - 2024-04-24 14:00 +0200
            Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-24 16:41 +0200
          Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-24 17:07 +0200
            Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-24 18:02 +0200
              Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-24 19:36 +0200
                Re: Proper cast of function pointers David Brown <david.brown@hesbynett.no> - 2024-04-24 21:18 +0200
                  Re: Proper cast of function pointers Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-25 09:50 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#118857

Am 23.04.2024 um 17:00 schrieb Markus Schaaf:
> Am 23.04.24 um 16:44 schrieb David Brown:
>> On 23/04/2024 14:23, Markus Schaaf wrote:
>>> Am 23.04.24 um 13:31 schrieb Paavo Helde:
>>>>
>>>> There is an old third-party library where some function pointers are
>>>> casted to another type, then back to the original type before use. C++
>>>> standard says this is kosher, and there have never been any problems
>>>> with actual behavior. Alas, different versions and compile modes of g++
>>>> still produce warnings. What would be the best way to silence them
>>>> (without just switching off warnings)?
>>>
>>> You could use a union, if you know all possible function types 
>>> beforehand.
>>>
>>
>> You /could/, if you don't mind the undefined behaviour - type-punning
>> unions are not defined behaviour in C++.
> 
> I have no idea what you are writing about. Of course one would read the 
> exact same member of the union one had written to before. That is what 
> unions are for.

A union actually isn't needed for the discusses purpose.
Just do a reinterpret_cast or a C-style cast.

[toc] | [prev] | [next] | [standalone]

#118859

On 24/04/2024 13:11, Bonita Montero wrote:
> Am 23.04.2024 um 17:00 schrieb Markus Schaaf:
>> Am 23.04.24 um 16:44 schrieb David Brown:
>>> On 23/04/2024 14:23, Markus Schaaf wrote:
>>>> Am 23.04.24 um 13:31 schrieb Paavo Helde:
>>>>>
>>>>> There is an old third-party library where some function pointers are
>>>>> casted to another type, then back to the original type before use. C++
>>>>> standard says this is kosher, and there have never been any problems
>>>>> with actual behavior. Alas, different versions and compile modes of 
>>>>> g++
>>>>> still produce warnings. What would be the best way to silence them
>>>>> (without just switching off warnings)?
>>>>
>>>> You could use a union, if you know all possible function types 
>>>> beforehand.
>>>>
>>>
>>> You /could/, if you don't mind the undefined behaviour - type-punning
>>> unions are not defined behaviour in C++.
>>
>> I have no idea what you are writing about. Of course one would read 
>> the exact same member of the union one had written to before. That is 
>> what unions are for.
> 
> A union actually isn't needed for the discusses purpose.
> Just do a reinterpret_cast or a C-style cast.
> 

Sure - that's what the OP is doing.  It's not the cast that is his 
problem - it is the compiler warning that he'd like to avoid.

[toc] | [prev] | [next] | [standalone]

#118856

Am 23.04.2024 um 16:44 schrieb David Brown:

> You /could/, if you don't mind the undefined behaviour - type-punning 
> unions are not defined behaviour in C++.

Actually all compiler support that. But MSVC++ isn't that efficient
with that like clang or g++; MSVC often does a store and load round-
trip. But there's bit_cast with C++20, which also works efficient
with MSVC++. But actually he neither needs bit_cast nor unions for
his purpose, but just a reinterpret_cast or a C-style cast, which
I prefer for readability.

[toc] | [prev] | [next] | [standalone]

#118860

On 24/04/2024 13:10, Bonita Montero wrote:
> Am 23.04.2024 um 16:44 schrieb David Brown:
> 
>> You /could/, if you don't mind the undefined behaviour - type-punning 
>> unions are not defined behaviour in C++.
> 
> Actually all compiler support that. 

That may be true - but I am entirely confident that you don't know it is 
true.  You live in a little world where the only compiler is MSVC++ - 
you know nothing about the hundred other C++ compilers out there.  (I 
know more of them than you - and more importantly, I know my knowledge 
is limited.)

Compiler extensions can be useful - and sometimes essential.  It's fine 
to write non-portable code when you have to do so.  It is a much worse 
idea to use non-portable code when it is needless to do so.  There's no 
need to use type-punning unions in C++, so don't do it - even if it 
happens to work on the compilers you tested.

> But MSVC++ isn't that efficient
> with that like clang or g++; MSVC often does a store and load round-
> trip. But there's bit_cast with C++20, which also works efficient
> with MSVC++.

Yes, std::bit_cast<> is (as I said) a good and well-defined alternative 
to type-punning unions in C++20.  And if you have to use a poor-quality 
compiler that can't do a decent job of optimising memcpy, then it's 
definitely the way to go for general type-punning uses.

> But actually he neither needs bit_cast nor unions for
> his purpose, but just a reinterpret_cast or a C-style cast, which
> I prefer for readability.
> 

Agreed, in this particular case - and reinterpret_cast<> was the OP's 
original choice.

[toc] | [prev] | [next] | [standalone]

#118864

Am 24.04.2024 um 13:23 schrieb David Brown:

> That may be true - but I am entirely confident that you don't know it is 
> true.  You live in a little world where the only compiler is MSVC++ - 
> you know nothing about the hundred other C++ compilers out there.  (I 
> know more of them than you - and more importantly, I know my knowledge 
> is limited.)

Any C++ compiler supports that since this is very common and you
coudln't port a lot of code to compilers who wouldn't understand
that. I've no problem using a union since this feature is required
for any compiler to be conformant with a lot of software.

[toc] | [prev] | [next] | [standalone]

#118867

On 24/04/2024 17:06, Bonita Montero wrote:
> Am 24.04.2024 um 13:23 schrieb David Brown:
> 
>> That may be true - but I am entirely confident that you don't know it 
>> is true.  You live in a little world where the only compiler is MSVC++ 
>> - you know nothing about the hundred other C++ compilers out there.  
>> (I know more of them than you - and more importantly, I know my 
>> knowledge is limited.)
> 
> Any C++ compiler supports that since this is very common

That is clearly wrong.  I am reasonably confident that my ancient copy 
of a Microtek C++ compiler for the 68k supported type-punning in 
practice (not by design, but simply because it did little in the way of 
optimisation) - that does not imply that the compiler was very common.

What you are trying to say is that the most common C++ compilers support 
it.  I believe that is true, but I am not sure if they all /document/ 
that they support it - and if they don't document it as a guaranteed 
feature, you are relying on luck.  Can you point to where MSVC++ 
documents that type-punning unions are supported in C++?

> and you
> coudln't port a lot of code to compilers who wouldn't understand
> that. I've no problem using a union since this feature is required
> for any compiler to be conformant with a lot of software.

It is certainly the case that a large proportion of code is 
non-portable, and uses extensions or platform-specific features.  Mostly 
it is for good reason - you are using Linux system calls, or Windows API 
functions, or need MSVC "cdecl" or gcc "__attribute__" for some purpose. 
  That's fine.

What is /not/ fine, in my book, is /pointless/ non-portability.

I think it is quite uncommon to do type-punning using unions - type 
punning is very rarely needed, no matter how it is done.  And even if 
some lazy or ignorant programmers do so, there is no good reason for 
/you/ to do it or recommend it.  You are no longer ignorant about the 
issue - you now know it is non-portable.  And surely you are not 
suggesting that it is a good thing to be lazy rather than using 
well-defined code?

[toc] | [prev] | [next] | [standalone]

#118869

Am 24.04.2024 um 17:59 schrieb David Brown:

> That is clearly wrong.  I am reasonably confident that my ancient
> copy  of a Microtek C++ compiler for the 68k supported type-punning in 
> practice (not by design, but simply because it did little in the way of 
> optimisation) - that does not imply that the compiler was very common.

It's a common pattern for decades and because of that any compiler does
support that.

Rest unread

[toc] | [prev] | [next] | [standalone]

#118844

23.04.2024 15:23 Markus Schaaf kirjutas:
> Am 23.04.24 um 13:31 schrieb Paavo Helde:
>>
>> There is an old third-party library where some function pointers are
>> casted to another type, then back to the original type before use. C++
>> standard says this is kosher, and there have never been any problems
>> with actual behavior. Alas, different versions and compile modes of g++
>> still produce warnings. What would be the best way to silence them
>> (without just switching off warnings)?
> 
> You could use a union, if you know all possible function types beforehand.

Right, I could use union, it's just extra work and some danger of 
introducing new bugs in this old third-party code.

> 
>> typedef double (*Func)(double);
>> typedef double (*DoubleFunc_2_args)(double, double);
>>
>> Func FuncCast2(DoubleFunc_2_args fp) {
>>     return reinterpret_cast<Func>(fp);
>> }
>>
>> $ g++ test1.cpp -Wall -Wextra
>> test1.cpp: In function ‘double (* FuncCast2(DoubleFunc_2_args))(double)’:
>> test1.cpp:26:34: warning: cast between incompatible function types from
>> ‘DoubleFunc_2_args’ {aka ‘double (*)(double, double)’} to ‘Func’ {aka
>> ‘double (*)(double)’} [-Wcast-function-type]
>>     return reinterpret_cast<Func>(fp);
> 
> You could wonder why you are asking for non-standard (extra) warnings in 
> the first place.

Because using -Wall -Wextra (and sometimes more) has been encouraged by 
people in this group and elsewhere.

I suspect -Wcast-function-type has been added into -Wextra during some 
last 10 years, I'm pretty sure earlier this code used to compile without 
warnings, it has been relatively recently when this has started to 
irritate me (mostly because we have managed to get the rest of the 
codebase almost warning-free ;-).

> 
> Out of curiosity I have fiddled with g++, asking myself if there is a 
> type like (void*) for objects, that the compiler is happy converting 
> function pointers into. And alas, there is! And it is the type one would 
> guess:
> 
> typedef void (*UniversalFunctionPointer)();

Adding an intermediate reinterpret_cast to this type indeed seems to get 
rid of the warning! Thanks a lot!

[toc] | [prev] | [next] | [standalone]

#118845

Am 23.04.24 um 20:50 schrieb Paavo Helde:

>> typedef void (*UniversalFunctionPointer)();
> 
> Adding an intermediate reinterpret_cast to this type indeed seems to get
> rid of the warning! Thanks a lot!

Wouldn't it be better to change the storage type of these 
function pointers in your registry to above type, making the 
intention clear to those you recognize its special property? 
Instead of introducing obscure cast chains everywhere.

BR

[toc] | [prev] | [next] | [standalone]

#118846

Am 23.04.24 um 22:18 schrieb Markus Schaaf:

> intention clear to those you recognize its special property?

... to those who recognize ...

(Phonetic typing error, interesting.)

BR

[toc] | [prev] | [next] | [standalone]

#118847

23.04.2024 23:18 Markus Schaaf kirjutas:
> Am 23.04.24 um 20:50 schrieb Paavo Helde:
> 
>>> typedef void (*UniversalFunctionPointer)();
>>
>> Adding an intermediate reinterpret_cast to this type indeed seems to get
>> rid of the warning! Thanks a lot!
> 
> Wouldn't it be better to change the storage type of these function 
> pointers in your registry to above type, making the intention clear to 
> those you recognize its special property? Instead of introducing obscure 
> cast chains everywhere.

Yes, it would be better or at least more symmetric, assuming that 
somebody will read this third-party code some day. This has not happened 
in the last 20 years, but you never know. I will think about that.

BR

[toc] | [prev] | [next] | [standalone]

#118838

On 23/04/2024 13:31, Paavo Helde wrote:
> 
> There is an old third-party library where some function pointers are 
> casted to another type, then back to the original type before use. C++ 
> standard says this is kosher, and there have never been any problems 
> with actual behavior. Alas, different versions and compile modes of g++ 
> still produce warnings. What would be the best way to silence them 
> (without just switching off warnings)?
> 
> 
> Simplified example:
> 
> typedef double (*Func)(double);
> typedef double (*DoubleFunc_2_args)(double, double);
> 
> Func FuncCast2(DoubleFunc_2_args fp) {
>      return reinterpret_cast<Func>(fp);
> }
> 
> $ g++ test1.cpp -Wall -Wextra
> test1.cpp: In function ‘double (* FuncCast2(DoubleFunc_2_args))(double)’:
> test1.cpp:26:34: warning: cast between incompatible function types from 
> ‘DoubleFunc_2_args’ {aka ‘double (*)(double, double)’} to ‘Func’ {aka 
> ‘double (*)(double)’} [-Wcast-function-type]
>    return reinterpret_cast<Func>(fp);
> 
> 
> If I change the function to use more indirection, then there is a 
> warning with -O2 only:
> 
> Func FuncCast2(DoubleFunc_2_args fp) {
>      return *reinterpret_cast<Func*>(&fp);
> }
> 
> $ g++ test1.cpp -Wall -Wextra -O2
> test1.cpp: In function ‘double (* FuncCast2(DoubleFunc_2_args))(double)’:
> test1.cpp:22:10: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules [-Wstrict-aliasing]
>    return *reinterpret_cast<Func*>(&fp);
>            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> $ g++ --version
> g++ (Debian 10.2.1-6) 10.2.1 20210110


The compiler is warning here about casting incompatible function types 
because usually such casts are a bad idea.  In particular, casting to a 
different function type, then calling through this new type, is 
undefined behaviour.  About the only useful thing you can do with your 
cast pointer is cast it back to the original type before calling it.  So 
g++ with -Wextra warns you that you have either made a mistake in your 
code, or are trying to do something that is potentially dangerous.

The compiler then helpfully tells you exactly why you got the warning, 
and makes it obvious what you can do to hide the warning, by giving you 
the specific flag - "-Wcast-function-type".  You disable that warning by 
using "-Wno-cast-function-type", or by using the appropriate pragma:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wcast-function-type"
inline Func FuncCast2(DoubleFunc_2_args fp) {
       return reinterpret_cast<Func>(fp);
}
#pragma GCC diagnostic pop

[toc] | [prev] | [next] | [standalone]

#118855

Am 23.04.2024 um 16:44 schrieb David Brown:

> The compiler is warning here about casting incompatible function types 
> because usually such casts are a bad idea.  In particular, casting to
> a  different function type, then calling through this new type, is 
> undefined behaviour.  About the only useful thing you can do with your 
> cast pointer is cast it back to the original type before calling it.
> So  g++ with -Wextra warns you that you have either made a mistake in
> your code, or are trying to do something that is potentially dangerous.

He needs to store different function-pointers with a common type;
why not as a void-pointer ?

[toc] | [prev] | [next] | [standalone]

#118858

On 24/04/2024 11:27, Bonita Montero wrote:
> Am 23.04.2024 um 16:44 schrieb David Brown:
> 
>> The compiler is warning here about casting incompatible function types 
>> because usually such casts are a bad idea.  In particular, casting to
>> a  different function type, then calling through this new type, is 
>> undefined behaviour.  About the only useful thing you can do with your 
>> cast pointer is cast it back to the original type before calling it.
>> So  g++ with -Wextra warns you that you have either made a mistake in
>> your code, or are trying to do something that is potentially dangerous.
> 
> He needs to store different function-pointers with a common type;
> why not as a void-pointer ?

As far as I know, the standards do not define the behaviour of casting 
between function pointers and void pointers (or any object pointers). 
The C standards are clear about the matter - it is not defined 
behaviour.  But I don't know the C++ standards well enough to say.

For C, you can happily use "void (*)(void)" as a universal function 
pointer type, rather than "* void" which is only for object pointers.

The compiler warning here is a good idea for most code, but sometimes 
you need code that is potentially risky but you know is correct - such 
as converting function pointer types before storing them, and converting 
them back before using them.  The OP just needs to disable the warning 
around the code that does this conversion.

[toc] | [prev] | [next] | [standalone]

#118861

On 2024-04-24 at 13:14, David Brown wrote:
> On 24/04/2024 11:27, Bonita Montero wrote:
>> Am 23.04.2024 um 16:44 schrieb David Brown:
>>
>>> The compiler is warning here about casting incompatible function 
>>> types because usually such casts are a bad idea.  In particular, 
>>> casting to
>>> a  different function type, then calling through this new type, is 
>>> undefined behaviour.  About the only useful thing you can do with 
>>> your cast pointer is cast it back to the original type before calling 
>>> it.
>>> So  g++ with -Wextra warns you that you have either made a mistake in
>>> your code, or are trying to do something that is potentially dangerous.
>>
>> He needs to store different function-pointers with a common type;
>> why not as a void-pointer ?
> 
> As far as I know, the standards do not define the behaviour of casting 
> between function pointers and void pointers (or any object pointers). 
> The C standards are clear about the matter - it is not defined 
> behaviour.  But I don't know the C++ standards well enough to say.
> 

This is something about theory and practice. A function pointer is 
allowed to be larger than a void*.

In practice both Linux/Posix and Windows will use void* for returning 
function pointers into dynamic libraries. So on those systems it will 
obviously work.

[toc] | [prev] | [next] | [standalone]

#118863

On 24/04/2024 14:00, Bo Persson wrote:
> On 2024-04-24 at 13:14, David Brown wrote:
>> On 24/04/2024 11:27, Bonita Montero wrote:
>>> Am 23.04.2024 um 16:44 schrieb David Brown:
>>>
>>>> The compiler is warning here about casting incompatible function 
>>>> types because usually such casts are a bad idea.  In particular, 
>>>> casting to
>>>> a  different function type, then calling through this new type, is 
>>>> undefined behaviour.  About the only useful thing you can do with 
>>>> your cast pointer is cast it back to the original type before 
>>>> calling it.
>>>> So  g++ with -Wextra warns you that you have either made a mistake in
>>>> your code, or are trying to do something that is potentially dangerous.
>>>
>>> He needs to store different function-pointers with a common type;
>>> why not as a void-pointer ?
>>
>> As far as I know, the standards do not define the behaviour of casting 
>> between function pointers and void pointers (or any object pointers). 
>> The C standards are clear about the matter - it is not defined 
>> behaviour.  But I don't know the C++ standards well enough to say.
>>
> 
> This is something about theory and practice. A function pointer is 
> allowed to be larger than a void*.
> 
> In practice both Linux/Posix and Windows will use void* for returning 
> function pointers into dynamic libraries. So on those systems it will 
> obviously work.
> 

Sure.  But I saw nothing in the OP's posts to indicate that he was using 
POSIX or Windows.  And it is silly to use "void *" pointers for generic 
function pointers when "void (*)(void)" will work be design, rather than 
luck, and is in no way more difficult or less efficient.  (Note that 
this is what the OP is already doing.)

[toc] | [prev] | [next] | [standalone]

#118865

Am 24.04.2024 um 13:14 schrieb David Brown:

> As far as I know, the standards do not define the behaviour of casting 
> between function pointers and void pointers (or any object pointers). 
> The C standards are clear about the matter - it is not defined 
> behaviour.  But I don't know the C++ standards well enough to say.

There's for sure no compiler which doesn't support that.

[toc] | [prev] | [next] | [standalone]

#118868

On 24/04/2024 17:07, Bonita Montero wrote:
> Am 24.04.2024 um 13:14 schrieb David Brown:
> 
>> As far as I know, the standards do not define the behaviour of casting 
>> between function pointers and void pointers (or any object pointers). 
>> The C standards are clear about the matter - it is not defined 
>> behaviour.  But I don't know the C++ standards well enough to say.
> 
> There's for sure no compiler which doesn't support that.
> 

Incorrect.

On the AVR (which is supported by gcc), code pointers can have different 
sizes from data pointers.  The same goes for the msp430, depending on 
the memory model you use.  The same goes for DOS compilers - if you have 
a memory model with 16-bit data pointers and 32-bit code pointers, they 
are not interchangeable.

The C and C++ standards don't restrict this kind of thing just to be 
awkward - they do so to make it clear that such mixing may be 
non-portable, and is completely unnecessary in coding.

[toc] | [prev] | [next] | [standalone]

#118870

Am 24.04.2024 um 18:02 schrieb David Brown:

> On the AVR (which is supported by gcc), code pointers can have different 
> sizes from data pointers. ...
No one aliases code through a union.

[toc] | [prev] | [next] | [standalone]

#118873

On 24/04/2024 19:36, Bonita Montero wrote:
> Am 24.04.2024 um 18:02 schrieb David Brown:
> 
>> On the AVR (which is supported by gcc), code pointers can have 
>> different sizes from data pointers. ...
> No one aliases code through a union.
> 

What are you talking about?

The point here was that function pointers and object pointers do not 
have standards-defined conversion behaviour (that fact is indisputable). 
  You claimed that all compilers support it anyway - I gave a few 
examples where it could be problematic.  (As usual, your idea of "all 
compilers" is that only modern MSVC is important, with perhaps a brief 
nod to the existence of gcc and clang, only on x86-64.)

Discussions with you are always difficult - you haven't any idea what 
you are talking about, beyond the world of x86-64 programming with MSVC 
on Windows.  But that never stops you making wild claims and 
generalisations, then changing the goalposts whenever challenged.

So if you have something useful to say, or questions to ask, go ahead. 
If you just want to spout nonsense about what "all compilers" do, and 
recommend pointlessly non-portable code instead of easy, portable and 
well-defined alternatives, please don't bother.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web