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

"Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
news:OVcIFZ%23iFHA.3012@xxxxxxxxxxxxxxxxxxxxxxx

[...]

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

I did read that. I disagree. And I am not alone here. The "committee
members" also say that the intent is to make it perfectly well defined when
the conversion can be supported and also perfectly well defined
[=ill-formed] when it cannot be supported. You seem to want it just
undefined, as in C. I do not regard that as an improvement -- and the
"committee members" are not likely to regard it that way, too, given that
the feature was knowingly removed during standardization.

[...]

> 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();

If you drop ::, it will be Standard C with undefined behaviour, which will
nevertheless work OK by the virtue of the implementation. Which makes it
portable just between win32 and POSIX. If you leave ::, it will be
non-standard C++, with the same properties. Either way its use is safe and
well-defined on the above mentioned platforms. I like the return type of
basic GetProcAddress() better than that of the wrapper or dlsym(), because
the former does not require C++ extensions [or future
conditionally-supported something] in typical use and it generally "means
what it says". I like the name of dlsym() better than that of Get*Address()
[win32 naming is just horrible; NT naming is a tad better because it is
slightly more systematic, but still inadequate].

So, basically, it is all broken. Seemingly, beyond repair.

S


.

Relevant Pages

  • Re: bind()
    ... > Microsoft employees and others DO think that MSDN is the Win32 ... SDK or .NET SDK portion of MSDN. ... given implementation against a standard and decide whether it conforms. ... differently from MSDN it is usually a bug in MSDN rather than Win32. ...
    (microsoft.public.win32.programmer.networks)
  • Re: double-checked locking in C
    ... I'm saying a situation where you have a test suite, ... >> the standard will still work with my code so long as they comply with the ... If you want to ignore stuff that's strictly not Posix ... >> would be precisely the same if we were talking about WIN32 threads. ...
    (comp.programming.threads)
  • Re: Going back to Delphi 7
    ... IBM was still the dominant player in the market in 1987, but by then the ISA Bus was a standard used by hundreds of manufacturers. ... I'm not implying that Microsoft will become a minor player; I am saying that Microsoft has lost some control in setting the standards for Windows. ... So many computers are using the Win32 standard, that unless there is a pressing need to change to something else, it won't happen. ...
    (borland.public.delphi.non-technical)
  • Re: GetStdHandle .NET
    ... It encapsulates most of the Win32 Console API ... | I ran into trouble with GetStdHandle API. ... There is the same problem with standard error, ...
    (microsoft.public.dotnet.languages.vb)