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

"Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
news:uq4RfhxiFHA.3288@xxxxxxxxxxxxxxxxxxxxxxx
> Slava M. Usov wrote:
>> "Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
>> news:uBtSIrwiFHA.1460@xxxxxxxxxxxxxxxxxxxxxxx
>>
>> [...]
>>
>>>> Indeed, why would anyone want to stick with a standard?
>>>
>>> Indeed why in this particular case?
>>
>> And C++ compilers must also compile VB code, right?
>
> I don't see what your analogy has to do with this issue. Why in this
> particular case sticking to the standard is good?

Before we start arguing about "sticking with a standard in a particular
case", I'd like to hear when you think "sticking with a standard" is good.
My opinion is very simple: stick with the standard by default, and justify
each and every case when non-standard behavior is necessary.

>>> Well the standard is obviously out of sync with reality.
>>
>> Out of sync with reality is somebody else. Your perception of reality
>> breaks down even on certain IA32 platforms, and the reality of the
>> standard is far more diverse.
>
> I am not sure what you argue about. Again: GetProcAddress() can return a
> pointer to data. dlsym() can return pointer to function. Ergo, on Win32
> and Posix (modern versions) the pointers are interchangeable.

I was arguing with this:

[begin quote]

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

[end quote]

That remark of yours was not about win32 or POSIX; it was about Standard
C++. Now you are somehow arguing about win32 and POSIX only. If you're so
flexible with your arguments, you might as well say "pointers-to-code and
pointers-to-data are not interchangeable in contemporary Standard C++; any
code that uses that relies on a non-standard language extension". That would
signify, for me, the end of this discussion.

> I am not sure where 'my perception of reality' breaks on IA32 so perhaps
> you could educate me.

E.g., most early 90's IA32 platforms in certain "memory models".

>>> Googling on this issue reveals that even the standard comitteee
>>> members say so.
>>
>> Looking at the standard is a much more straightforward way of
>> listening to the committee members.
>
> I see. So the standard was given to us on mount Sinai as the world of god
> rather than being written by these same committee members.

If your confession accepts standards only from that authority, it conflicts
with your profession [I presume writing C++ code is part of your
profession].

If we stay away from religious issues, then I'd like to draw your attention
to the fact that the standard committee members _do_not_ "say so". What they
do say on this issue is that an entirely new concept of
"conditionally-supported behavior" is required to support this conversion.
For more details, see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html , defect no.
195; http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1564.pdf .

> No. If a pointer is say 128 bit and the largest integer only 64, there is
> no way you can implement such conversion.

The standard mentions this case. A sensible implementation will introduce an
integer type big enough for the largest pointer type, anyway.

> Again I am not sure what exactly do you argue about.

See above.

> Please show me how
>
> (void*)(int)pf;
>
> leads to better code than
>
> (void*)pf;

If the latter is supported by a language extension, then it will probably
lead to exactly the same code as the former, if 'int' is big enough. But it
will be via an extension, not even undefined behavior. This is my whole
point.

S


.

Relevant Pages

  • Re: A C++ Whishlist
    ... In the vast majority of member functions the first thing you will do ... If I feel it needs an extra check because it won't crash cleanly I may ... >> unless you also check the this pointer you aren't checking every ... The standard does not say "the this pointer cannot be NULL". ...
    (comp.lang.cpp)
  • Errata for The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie
    ... Today I found out that the official page of errata for The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie is down: ... The first printing of the book was made before the Standard was finalized; these copies say "Based on Draft-Proposed ANSI C" on the front cover. ... ``A pointer may be converted to another pointer whose type is the same except for the addition or removal of qualifiers of the object type to which the pointer refers. ...
    (comp.lang.c)
  • Errata for The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie
    ... Today I found out that the official page of errata for The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie is down: ... The first printing of the book was made before the Standard was finalized; these copies say "Based on Draft-Proposed ANSI C" on the front cover. ... ``A pointer may be converted to another pointer whose type is the same except for the addition or removal of qualifiers of the object type to which the pointer refers. ...
    (comp.std.c)
  • Re: why cannot assign to function call
    ... hypothetical C-like languages, ... sizeof business would still indicate that a pointer was being passed. ... talk about variables of an array type. ... the earlier version of the standard didn't have numbered ...
    (comp.lang.python)
  • Re: Pointer equality and dereferencing
    ... exact replica of the representation of a pointer is guaranteed to be ... sufficient to produce a semantically equivalent pointer, and if not, then ... Reading the C standard and this newsgroup I think that an exact replica ... dereference it with a defined behavior. ...
    (comp.std.c)