Office Noir Chapter II: The Ribbon Bar

Comment removed at user's request.
Ion Todirel wrote:with what price come this 'safe'?
martynl wrote:The title of this thread should really say 'Safe Libraries'. Sorry about that, there was confusion about the naming and an 'internal codename' got used for the thread.
Safe Libraries (Safe CRT, Safe ATL, Safe MFC) is the general initiative for all this stuff.
Martyn
Great video. It is cool to see what they implemented. The secure functions are great: finally a hope that buffer overruns are going to decrease It is worth the little speed impact for most of the scenarios.
_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES
in C++ code will engage this mapping. You can do similar mappings for functions taking counts (strncpy) with
_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT
Obviously, both these extensions provide template overloads of standard functions, and so aren't strictly conformant to the standard. So we turn them off by default. But you can turn them on when if you want them. We foudn that the significantly reduced the
effort to secure existing code.
There's no general way for us to correctly determine at compile time the intended buffer size of a buffer passed to strcpy, so we can't apply these techniques all the time. But when C++ is used, we can do some cases.
You also mentioned the issue of the warnings using the word "deprecated", even though these functions are not deprecated in the relevant standard. We never intended this to imply deprecation in the standard sense, but it's caused a lot of concern and confusion,
so in service pack 1 of our product we've removed the word 'deprecate' from the warnings associated with this, and replaced it with a text message that explains in more detail what we're doing here.
Although the _s functions are not part of the C standard, we have worked very closely with the C committee on their design for the past 3 years, and a technical report of the C committee that includes many of them is under voting right now. I also know that
a couple of other library implementers have portable implementations of these functions, so they should start turning up on other platforms. We wanted to try to help secure C code across the whole development community (not just Windows), which is why we worked
so closely with the C committee on this issue.
If you get a chance, take a look at the latest C committee document and let me (or the editor) know what you think:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf
Martyn
Slackmaster,
Neat monitors I've never had more than 2 at once on one machine - both for desk space and angle reasons. Plus, my display card budget is limited... I'm looking forward to the improved multimon support in Remote Desktop in Windows Vista.
Martyn
martynl wrote:Leigh,
I wish I could give you a better answer to this question, but we don't have a good list of which ATL functions work right with ATL_MIN_CRT. The original intention of the ATL_MIN_CRT feature was that you could only use a 'minimal' subset of ATL that had no CRT dependencies, but this term 'minimal' was not strictly defined. As a result, as ATL has evolved, we've occasionally accidentally broken people with changes we've made. If you report these, we'll try to fix them.
Additionally, ATL has picked up new unavoidable CRT dependencies in some cases, where you now need the CRT.
If you have specific cases you're seeing and need help with, do let me know
Personally, I generally recommend against the use of ATL_MIN_CRT. It's still appropriate for a small number of situations where you're still dealing with very small redists, but for lots of cases it's an easier develop with a CRT DLL dependency. What's making you choose ATL_MIN_CRT?
Martyn
leighsword wrote:
Thanks, MS seems evil, but their employees have always been care about their customers.
leighsword wrote:
Here I have a problem on sizeof. the following foo shows szDen[] and strDen[] both are the same array, why sz != sz1?
leighsword wrote:
And what’s the difference between strcpy_s and strncpy and memcpy?
int i;
memcpy(&i, "Hello, world", sizeof(i));
Which you just about never want to do. If you know you're copying strings, use the string functions--the compiler can do more type checking for you.leighsword wrote:
char* strcopy(char strDen[]/*char* strDen*/, const char* strSou)
{
size_t sz1 = sizeof(strDen); //sz1 always be 4?
_ASSERT(szDen && sizeof(strDen) >= strlen(strSou));
char* p = NULL;
for(p = strDen;*strDen++ = *strSou++; );
return p;
}
int _tmain(int argc, _TCHAR* argv[])
{
char szDen[6];
size_t sz = sizeof(szDen); //sz == 6
memset(szDen, 0, sizeof(szDen))
strcopy(szDen, "hello");
return 0;
}
leighsword wrote:
errno_t strcpy_s(
char *strDestination,
size_t sizeInBytes,
const char *strSource
);
I think the sizeInBytes and _countof() is unnecessary, because we already have sizeof operator, that also means strcpy_s is unnecessary too.
--------------------------------------------------------------
It is so unfortunate to read someone write such nonsense so bluntly and with so much confidence when just a few messages later that very same person writes something like:
leighsword wrote:
"Here I have a problem on sizeof. the following foo shows szDen[] and strDen[] both are the same array, why sz != sz1? And what’s the difference between strcpy_s and strncpy and memcpy?"
--------------------------------------------------------------
Kind of reminds me when some famous girl said once:
"I know it's Tuna.. but is it a chicken?"
Please.. please.. back your comments with knowledge.
martynl wrote:First, my reading of the standard is that the function at is required to do bounds checking, but operator at is also allowed to, because the behaviour of operator [] is said to be undefined outside of the valid ranges for the container. If I'm missing a standard paragraph, perhaps you can point me to it?
martynl wrote:We recommend this approach because we generally think it's unsafe to continue running code in a process once that process is in an unknown state - lots of security exploits use such lax-ness to their advantage.
martynl wrote:Your final point was about performance. I encourage you to post (or send me) your test code. Our experience was that most code recompiled with very little performance loss, and cases where there was perf loss were pretty easy to resolve. Because we put checking in every iterator operation, it's definitely possible to build 'worst-case' tiny examples where the cost looks very high. But for real world code I've worked with, the cost has mostly been pretty small, and certainly worth the improved safety. Of course, we provide _SECURE_SCL=0 for those cases where you really need all the perf and can do the error-checking yourself up front. But in our internal code we've rarely needed to use it.
martynl wrote:If you look at the code in our copy of <algorithm> you can see how this works - the algorithm code takes a checked iterator, does appropriate initial condition checking, and then gets an unchecked iterator from that checked iterator. It can then pass this unchecked iterator on to the core of the algorithm.
Sven,
You're absolutely right, and this is why we have worked with the C standard committee on the C functions, and hope, based on experience gained from this relase, to work with the C++ committee on improving the safety of those libraries.
For the default containers, algorithms and iterators, you end up being safer, performant and portable with little or no code change.
However, if you start using custom algorithms or iterators, you end up with these choices, as the standard is currently. We support all three:
You can be safer and portable, with performance loss in some cases. (usual constructs -- default is safe and portable)
You can portable and performant, with a loss of safety (_SECURE_SCL=0)
You can be safer and performant, with a portability loss (use _CHECKED_BASE, stdext::checked_array_iterator and so on).
Though we can't always deliver all three simultaneously, we did work hard to make sure you could choose any point in the solution space you prefer, and to make sure that our default was both safe and portable as far as possible.
Martyn
Hey, do not try to “civilize” C too much! It _should_ be a knife. Everyone admires performances right, so if you make it too “safe” you may kill some of it.
I think this effort to enhance standards is a good one. Especially nowadays when there is a lot of mediocre code accessible via internet.
Regarding the functions like _countof, I don’t see it as a problem, we can always create something similar (re-write LOL) should we decide move to other platforms etc. it’s not a black-box, that’s a beauty of native code.
I think many people are interested to hear about the plans for Visual Studio IDE. Right now, it’s not religiously C/C++-centric.
Can you make EXCLUSEIVE C/C++/MFC IDE, super fast on usage (it is not only compilation time that matters – but how fast it responses to our inputs), keyboard-usage friendly and “smart”. “Smart” means – when you hit Project/Settings -> do not display the first panel (which reads NET) but the last panel used, and stuff like that.
I think many people would like to see that.