Universal CRT. Am I “nitpicking”?

Universal CRT  (UCRT).There is no escaping from it. Rummaging through the source code (of UCRT) leaves few fundamental questions in every seasoned C/C++ developers soul. How and why?

As an illustration. This is copy/paste from strnlen.cpp as present in UCRT source available for debugging. I have added this to my Visual Studio 2017 yesterday (17SEP2017).

“..plain C..” ?

I do not know about you but it seems to me this is not (any kind of) C. And now the “nitpicking” part.

I do not like when people say to me “this is how it should look like”. But this time I have to say exactly that: “this is how it should look like”. Presented for you just if you follow this link to the proper, simple, robust and mature strnlen writen in plain C indeed.

Is the ucrt strnlen version  written by seasoned top notch developer? As they all should be on the UCRT team one likes to think. If author of this comment believes this is “plain C” are we opened to all sorts of “funny features” coming from good people of UCRT?

Ok wht do I think then?  I think UCRT team had a meeting. Decision has been made to use C++, (not C) to write UCRT.  This (I might think) makes all sorts of other WIN10 API’s easier to write and use. But. Opposite of what the team claims,  UCRT C++ code might (and will) generate all sorts of ABI issues to be solved. So why not just staying with C for a truly rock solid CRT as in decades before?

Disclaimer: I do like modern C++. A  lot.

This is why I am wondering why is this modern c++ version not inside, since ucrt has to be c++?


What is the history behind the “let’s go C++” decision? Who were the decision makers? Perhaps Windows unicode fiasco, was a reason to try and find the shelter in  ISO C++ shack? Or,  is it a deep dread of WIN XP (or even pre XP) legacy code, that was “skillfully” transformed into an real API minefield by the Longhorn “funky bunch”.  Peppered with C++/CX vagaries. Which has left a mountain of technical debt inside.  Feeling us API users to feel just like on the proverbial “path with glass shards on it”

Thus no, all has not worked simply and beautifully since the days of primordial windows soup. Which by the way is still not very healthy soup to slurp, if one is WIN32 lemming that is, believing into anything mixed into this API.

WIN32 lemming is the one peculiar kind following (slurping) it along the time line of decades past. With an unhealthy dose of exposure to MSDN high priests of the API documentation. And that documentation can make the grownup cry like a baby. With no baby sleep after.

Thankfully almost all of that pain, was thankfully somehow solved by top C developers delivering MSVC CRT.

And now that CRT it is not any more.

I am thinking on this seemingly esoteric themes, because my  legacy code calling _snprintf_s is all of a sudden throwing an exception. Unhanded exception is being thrown on a for loop above. Line 14. Of the said strnlen function inside ucrt.

As this poor maintainer of legacy codes says, I can feel  the long path peppered with a broken glass, if I proceed the way of trying to fix this.

And yes this was “fixed”, “just” by updating the VS 2017. Restart included.  Thankfully on my desktop machine, not on the production server this time. Fixed. But left (worried) me with this heavy dread of near future when such an unexplained fix, perhaps will not be working any more.

What then?

ucrt problems
ucrt problems  provoke seasoned developers to think of a “path peppered with a glass”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.