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

Tech-Archive recommends: Speed Up your PC by fixing your registry

"Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote in message news:%23zAdNqviFHA.2444@xxxxxxxxxxxxxxxxxxxxxxx
"Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message news:uDUo0HviFHA.1948@xxxxxxxxxxxxxxxxxxxxxxx

Sounds like "undefined by omission" to me.

Yes. I had thought it was a constraint violation, but when I looked for it the standard really left it undefined by omission, and an appendix lists it as a popular extension.

In any case even if the standards explicitly disallowed such casts this would be just a case of useless and pointless standard restriction.

I can't imagine why you think that. A constraint would force the compiler to issue a diagnostic, but would still allow the compiler to produce executable code with the extended meaning that you like (i.e. the diagnostic can be a warning instead of error). This way programmers would know that they're doing something that is risky and not guaranteed to work, which is exactly the truth.

I've worked with a programmer who was keeping calback pointers in void*. Couldn't convince him to use properly defined pointer.

Yup, sad, isn't it. By the way have you seen a DDK sample that keeps callback pointers in void*? Or a DDK API that keeps callback pointers in void*? From Mr. Brugiolo's posting I understand why this doesn't break in IA64, but it still looks incredibly fragile. 

.