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

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Alexander Grigoriev wrote:
> The standard need not list all cases to disallow them.

Well I don't have the standards to argue. What I know is that there is a
general principle "all which is not explicitly mentioned is undefined". No
idea whether it applies in this case.
In any case I think arguing about the standard is besides the point. On
platforms where it makes sense, all most widely used compilers allow the
conversion (sometimes with a warning). Some system APIs (Win32, Posix)
prescribe that the conversion must work. See for example GetProcAddress()
and dlsym(). De-facto this is undefined behavior with clear definitions on
Win32 and Posix. The C and C++ standards can either mark it as such or be
out of sync with reality.

> A function pointer may have a special format on some architectures
> and may not even have a real address inside. Or the code address
> space may be different from data space (and have different
> organization altogether).

Note that these are two different issues. The first issue completely
prohibits the conversion while the second only restricts what you can do
with the converted value. I beleive Ivan Brugiolo meant something like the
second restriction on IA64 (but I may be wrong). In any case the fact that
certain architectures prohibit the conversions doesn't mean that the
conversion has to be prohibited *everywhere*.

> I've worked with a programmer who was keeping calback pointers in
> void*. Couldn't convince him to use properly defined pointer.

Well this is a different issue. If all you have is a function pointer you
should call it 'function pointer'. The interesting question is what should
GetProcAddress return?


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


.

Relevant Pages

  • Re: bug in visual studio .net 2003 - breakpoints and memcpy
    ... > In any case I think arguing about the standard is besides the point. ... > prescribe that the conversion must work. ... See for example GetProcAddress() ... >> A function pointer may have a special format on some architectures ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Casting double to int produces inconsistent results from VS 2003 to VS 2008
    ... Some things in the standard are ... 4.8p1 An rvalue of floating point type can be converted to an rvalue of ... another floating point type. ... the result of the conversion is ...
    (microsoft.public.vc.language)
  • Re: casting constant value from float to unsigned short - compiler bugs?
    ... the conversion that sparked this thread. ... floating to integer types "truncates towards zero". ... Since the C standard provides no ... truncation clause clarifies which one of the multiple definitions ...
    (comp.lang.c)
  • Re: Function Pointers
    ... Just a heads-up - you don't need the cast. ... lossless conversion between void * and function pointers, ... I thought you couldn't have a generic function pointer like the 'void ... there is no generic function pointer type. ...
    (comp.lang.c)
  • Re: Converting fixed-to-free format
    ... just not source code which is defined as ending at 72. ... The question is whether something is "standard conforming". ... Besides, Fortran compilers are normally full of extensions, which makes it more valuable to understand the numerous type of non-conformance. ... is to say that a conversion utility will convert standard code only, ...
    (comp.lang.fortran)