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

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

It is very relevant if you are talking about standards and therefore
portability. In any case Posix is just an example. Win32, though not an
official 'standard' exhibits the same problem.

>> The second problem is that the standard prohibition is non-sensical
>> on platforms that support the conversion.
>
> Not nonsensical, simply inconvenient.

IMHO inconvenient == non-sensical as far as programming languages go.

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

Which, according to the links you have provided, is true for C. Nevertheless
I meant C++ too when writing this and I was wrong. Which I have also
acknowleged in my reply to your standard quotes.

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

What you have missed is this

<quote>
In any case even
if the standards explicitly disallowed such casts this would be just a case
of useless and pointless standard restriction. If it works on certain
platforms but not others the behavior should be undefined.
</quote

The Win32 and Posix example was about the later issue. For whatever reason
you took it to be a continuation of the orginal claim. Had you actually read
what I have written we probably could have avoided this whole exchange.

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

These are two different issues.
a) a platform can guarantee that pointers to functions and data are
interchangeable.
b) a compiler can provide an extension that allows direct casting of
pointers to functions and data.
These two are independent. A (bad) compiler can just trucate pointers on a
platform that doesn't provide (a). An equally bad compiler can not provide
the extension on a platform that does support (a). What happens in reality
is that (a) is causes (b) which is partly why the change of standard is a
good idea. Then there is also issue
c) a different standard or API spec may require compiler to provide an
extension

[...]

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

Consider the following extremely portable function and its usage. If you
don't like the types involved please suggest a better approach.

void * GetExportAddress(dll_handle_t h, const char * name)
{
#ifdef _WIN32
return (void*)::GetProcAddress(h, name);
#elif defined(POSIX)
return ::dlsym(h, name);
#else
#error Yadda yadda
#endif
}


typedef void func();

func * pf = (func*)GetExportAddres(h, "func");
pf();


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


.

Relevant Pages

  • POSIX 1003.1 Frequently Asked Questions
    ... This is the Frequently Asked Questions file for the POSIX 1003.1 ... Where can I download the 1003.1 standard from? ... Although originated to refer to the original IEEE Std 1003.1-1988, ... What about POSIX Certification?* ...
    (comp.unix.questions)
  • POSIX 1003.1 Frequently Asked Questions
    ... This is the Frequently Asked Questions file for the POSIX 1003.1 ... Where can I download the 1003.1 standard from? ... Although originated to refer to the original IEEE Std 1003.1-1988, ... What about POSIX Certification?* ...
    (comp.unix.questions)
  • POSIX 1003.1 Frequently Asked Questions
    ... This is the Frequently Asked Questions file for the POSIX 1003.1 ... Where can I download the 1003.1 standard from? ... Although originated to refer to the original IEEE Std 1003.1-1988, ... What about POSIX Certification?* ...
    (comp.unix.programmer)
  • POSIX 1003.1 Frequently Asked Questions
    ... This is the Frequently Asked Questions file for the POSIX 1003.1 ... Where can I download the 1003.1 standard from? ... Although originated to refer to the original IEEE Std 1003.1-1988, ... What about POSIX Certification?* ...
    (comp.unix.programmer)
  • POSIX.1 Frequently Asked Questions
    ... This is the Frequently Asked Questions file for the POSIX 1003.1 standard ... Where can I download the 1003.1 standard from? ... Although originated to refer to the original IEEE Std 1003.1-1988, ... What about POSIX Certification?* ...
    (comp.unix.questions)