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

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

well GetProcAddress uses FARPROC which is defined as:

int (FAR WINAPI * FARPROC) ()

"Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
news:eMtSTgwiFHA.3656@xxxxxxxxxxxxxxxxxxxxxxx
> 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. ... > A function pointer may have a special format on some architectures ... second restriction on IA64. ...
    (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: 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)
  • Re: operator+ overload resolution
    ... > My standard is not currently is not within arm's reach, ... 'C2::operator+' a conversion from explicit argument type 'C2' to ... argument type 'C2' to explicit parameter type 'C1&'. ... > 'implied object argument'. ...
    (comp.lang.cpp)