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

Slava M. Usov wrote:
> "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."

Ok that adds the "what is not mentioned is prohibited" restriction. (BTW
does the C standard say the same?).

> 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.

Ok. Though I doubt anything even marginally useful can be compiled in such
mode.

> [...]
>
>> If it works on certain platforms but not others the behavior should
>> be undefined.
>
> Indeed, why would anyone want to stick with a standard?

Indeed why in this particular case?

>>> 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]:

[...]

Well the standard is obviously out of sync with reality. Googling on this
issue reveals that even the standard comitteee members say so.
http://groups-beta.google.com/group/comp.lang.c++.moderated/msg/546501834bcbcc01?hl=en&;

<quote>
....
This extension is so wide-spread as to be a
de facto standard, even though C explicitly forbids it, and X Open
System does nothing to even suggest that they differ from C here. One
could argue that a good compiler would not support it, but given the
ubiquity of the extension, I'm not sure; banning it would probably
break a lot of user code
....
</quote>

I still stand by what I wrote earlier. Either cast once and the cast will
work or don't cast at all. The double cast doesn't buy anything here.


--
Eugene
http://www.gershnik.com




.

Relevant Pages

  • Re: Terminology : casting/conversion
    ... Is this an "explicit" cast? ... and `void*', the conversion is implicit. ... (all operators are explicit). ...
    (comp.lang.c)
  • Re: cast to void *
    ... A cast is an explicit conversion. ... int main ...
    (comp.lang.c)
  • Re: On "type casting"
    ... whether used in reference to an implicit conversion or an explicit ... of people on this newsgroup who think type casting is only what ... The Standard explicitly defines "cast" as an explicit conversion, ...
    (comp.lang.c)
  • Re: malloc and free
    ... I would call this type of conversion an implicit ... A cast is a defined as an explicit operation ... The standard also defines when types get ... restriction saying *only* the programmer can do this (using only this ...
    (comp.lang.c)
  • 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)
Loading