Re: bug in visual studio .net 2003 - breakpoints and memcpy

"Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
news:uDUo0HviFHA.1948@xxxxxxxxxxxxxxxxxxxxxxx
> Alexander Grigoriev wrote:
>> According to ANSI C and standard C++, there is no standard conversion
>> from a function pointer to void*, and vice versa. It's just not
>> listed among the possible conversions.
>
> Sounds like "undefined by omission" to me.

It's not. The C++ Standard says, in [expr.reinterpret.cast]: "Conversions
that can be performed explicitly using reinterpret_cast are listed below. No
other conversion can be performed explicitly using reinterpret_cast." In
[expr.cast], it also says "Any type conversion not mentioned below and not
explicitly defined by the user (12.3) is ill-formed."

So neither reinterpret_cast nor the explicit cast notation can be used to
convert pointer-to-function to pointer-to-object in standard C++.

VC7, in the standard conformance mode, rejects such conversions; it does
support them when language extensions are enabled.

[...]

> If it works on certain platforms but not others the behavior should be
> undefined.

Indeed, why would anyone want to stick with a standard?

>> A function pointer can be
>> converted to an integer of an appropriate size, though, which you may
>> (or may not) be able then convert to a void* (the size of the
>> necessary integer may be different from the required void* size).
>
> Now this is something I would definitely avoid doing. If a direct cast
> works it works. Otherwise the conversion is an error and the "double cast"
> doesn't help.

Nevertheless, this double conversion technique is the only one that the
standard recognizes [ibid]: "A pointer can be explicitly converted to any
integral type large enough to hold it. The mapping function is
implementation-defined [Note: it is intended to be unsurprising to those who
know the addressing structure of the underlying machine.] A value of
integral type or enumeration type can be explicitly converted to a pointer.
[...] mappings between pointers and integers are [...]
implementation-defined."

The "unsurprising" clause says all there is to say about the portability of
the technique; it is still "defined", albeit by the implementation.

S


.

Relevant Pages

  • Re: Explicit conversion
    ... > Docs says that "The compiler does not use an explicit constructor to ... > implement an implied conversion of types. ... the "explicit" keyword deals with constructors declarations only withing ... > into ExClass type? ...
    (comp.lang.cpp)
  • Re: inserting textbox value into bookmark
    ... What is happening if you omit the CStr function is that an implicit type ... because the implicit type conversion does what I expect. ... I'm not laying this down as a law - "Thou shalt use explicit type ...
    (microsoft.public.word.vba.general)
  • Re: cast to void *
    ...     return 0; ... Except that conversion between void* and struct tm is a constraint ... Conversion between void* and a function pointer, ...
    (comp.lang.c)
  • Re: bug in visual studio .net 2003 - breakpoints and memcpy
    ... According to ANSI C and standard C++, there is no standard conversion from a ... function pointer to void*, and vice versa. ... Both Win32 and Posix define the conversion. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Some pointer quiestions again
    ... in any system on which one conversion preserves ... >>void pointer reliably, if not then there would appear to be no portable ... >>way to print the value of a function pointer. ...
    (comp.lang.c)
Loading