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

"Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
news:uE9RUa8iFHA.1968@xxxxxxxxxxxxxxxxxxxxxxx

[...]

> In this particular case there are three such justifications. First one is
> 'what standard'? Posix is a standard too with no less (some would say
> more) importance than C++.

I fail to see the relevance of this standard in a win32 forum.

> The second problem is that the standard prohibition is non-sensical on
> platforms that support the conversion.

Not nonsensical, simply inconvenient.

> The final argument is that the workaround required to be standard
> compatible produces bad code.

See below.

[...]

> I mentioned Win32 and Posix to show that the reality contains
> implementations (indeed, extremely widely used implementations) that allow
> or even require the conversion.

Your very first message in this thread said "Not illegal, just undefined."
Flatly and generically. I might also say that neither win32 nor POSIX are
C++ implementations. Win32 is, at best, compatible with certain C -- alas,
not C++ -- implementations. C++ does not have to allow for this conversion
to make GetProcAddress() useful; it is just the proprietor of both the
platform and the C++ implementation does not want to make them conformant
[which, granted, may be unnecessary if the new standard proposal passes].

> Your assumtion about what constitutes my perception of reality and that I
> am flexible arguments doesn't follow from anything I have written.

Original argument: "Not illegal, just undefined" [this is implementation and
platform independent]. Recent argument: something about win32 and POSIX. If
that is not flexibility, then what is that?

>> 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".
>
> Not exactly. Any code that uses that relies on some platform guarantees
> that are usually accompanied by a language extension.

Can you explain how code can rely on platform guarantees NOT accompanied by
a language extension if the code construct is non-standard according to the
first clause, which, I presume, is accepted?

[...]

> My point is that first variant is worse code plain and simple. It is not
> because it generates different machine code. They both should produce the
> same result as you mentioned. The problem with the first variant is that
> it doesn't add anything to portability. Either you can convert function
> pointers to data ones on a platform or you cannot.

Conversion between code pointers to integers does not exist for the sole
purpose of converting between code pointers and data pointers. Even if there
is no conversion between code and data pointers, conversion between code
pointers and integers is still useful. The usage of the latter to convert
between data and code pointers is a by-product, not its raison d'etre.

Having said that, the integer-in-the-middle technique is still useful even
if direct conversion is unavailable. For example, in one of the DOS "memory
models", one pointer kind could be 16 bit ['near', segment offset] and the
other 32 bit ['far', selector + offset]. Direct conversion is only possible
from near to far, not the other way around. You can, however, convert a far
pointer into a 32 bit integer and extract a near pointer, which can be used
when an appropriate execution context is established.

I do not think portability is even remotely relevant here. The fact that the
C-declaration of GetProcAddress() relies on this "portable extension" means
just that the API is not portable to begin with. Conversion between code and
data pointers is only required when you want to treat code as data or data
as code, which in itself can be used to illustrate, if not define, what
'non-portable' means.

S



.

Relevant Pages

  • Re: ptr conversions and values
    ... That's why the standard explicitly ... > representation, without providing an explanation of what pairs of values are ... So I have given an explanation how to connect integers to pointers ... > won't have any more or any less issues than conversion does. ...
    (comp.std.c)
  • Re: fscanf and input failure after the first conversion
    ... a contradiction between POSIX.1-2008 and the ISO C standard. ... Unlucky timing - the Austin Group discussed the issue in a conference ... glibc seems to follow POSIX on this point). ... conversion, as required by the C Standard. ...
    (comp.std.c)
  • Re: multibyte length
    ... If you have the POSIX version of mbstowcs, you can pass it a NULL ... The reason for this was to be able to perform the conversion into memory ... that is from malloc while calling malloc only once. ... It's beyond me why Standard ...
    (comp.lang.c)
  • Re: Is this valid C statement?
    ... Pointers to functions cannot be converted ... >> Undefined behaviour due to lack of specification in the standard. ... Invoking undefined behaviour doesn't require any warning. ... the C standard does not define the conversion between void pointers and ...
    (comp.lang.c)
  • Re: c question
    ... Please quote C&V in the Standard where this is guaranteed. ... perhaps 6.3.2.3:6 in C99. ... That only allows pointers to be converted to integers; ... that the conversion occurs automatically, ...
    (comp.lang.c)