I kinda doubt it. This applies to Windows 8.1 and no earlier or later version. So the problem was introduced in Windows 8.1. Furthermore, Windows never really had utilities passing data as text doing maintenance stuff in the core operating system. That's not how Windows works. There are APIs for everything, not command-line tools. And they sure as hell didn't "move an old Unix app to Windows" in 2013.

As other have said, maybe Raymond Chen will some day do a blog post on this, although, considering that the bug is in DFPCommon.dll, i.e. the "Disk Footprint Utility Library", I doubt it really belongs to the shell and thus he won't know more than we do.

Alternatively, Windows has a fair amount of kludges - put there to fix poorly coded software. This could be an example case and, not knowing what has become dependant on the behaviour, it can't be removed.

This is a cool theory, but why would it call the function again? Shouldn't it just give up? It's not like it would get a different result next time.

You could image code like this:

  for (pos = 0; !found; pos++) {
    row = get_next_row();
    if (strstr(row, "user") {
      // this is obviously a header row
      continue
    }
    if (strstr(row, user_name)) {
      found = 1;
    }
  }

    for (pos = 0; !found; pos++)

This is so cool, I have never thought about this in like a decade of programming. I mean using a bool variable within a for loop.

It doesn't apply to that sample code but maybe this is generally safer:

   for (pos = 0; !found || pos < limit; pos++)

but there is nothing wrong in using an iterator and break out of the loop, especially if the language or the library gives you iterators.

That should be logical AND, not logical OR, because if you go over the limit and the right side is False, the left side will always be True if the item is not found, and True || False is still True, and the loop continues infinitely.

When you are over the iteration limit you want to trigger True && False which is False to break out of the loop where the right side False is the condition when pos > limit

Btw this is covered in Code Complete Second Edition by Microsoft Press on page 378-380

You are right. I believed I didn't need a test for that. See what happens? :-)

Don't do it in production code - indeed try to avoid languages where "for" allows such arbitrary constructs.

> Don't do it in production code

I'd say fair, but...

> indeed try to avoid languages where "for" allows such arbitrary constructs.

... come on. I'd say - go for such languages, they give you if a tiny bit more expressive power than ones who don't let you write such a loop.

Allowing the same statement to do any kind of arbitrary nonsense is not the good kind of expressiveness. Far better to separate your concerns, and keep the orthogonal parts orthogonal. C-style for mixes too many different things.

Semantics of the C-style for loop are pretty well defined - it's: for(initialize form ; condition form ; step form) { loop body forms }. Ascribing any different meaning to it, like e.g. that all three forms in the loop header must be present or must refer to the same set of variables, is a mistake.

That said, if one has an alternative that can express their intention better (like e.g. mapcar, foreach loop, Lisp's dotimes, etc.), one should use it instead.

Well, you also have to consider greater debugging costs of you use a loop comprehension. Expression of intention isn't the only issue to consider.

I disagree - debugging costs usually come directly from choosing a construct that does not express programmer's intentions (like using a naked for when foreach would be more adequate - or, conversely, by messing with conditionals inside loop body when putting the condition in the loop header would be more adequate).

Debugging a higher order function application is harder than stepping through a loop, at least in most debuggers I've used. I use them only when the logic called indirectly is not complicated to require much debugging (and I still wind up converting comprehensions into loops because they are too much trouble).

Oh ok, I can imagine more complex expressions being harder to debug from machine code level.

That said, I rarely if ever have to resort to low-level debugging in such cases. I'm yet to encounter a problem that couldn't be solved by looking at the code and (very occasionally) stepping it through in the debugger. Here, using higher-order constructs in code is actually very helpful - the closer your code gets to expressing your intent, the smaller the set of possible bugs is. For instance, you can't make an off-by-one error in a foreach or a mapcar.

There are many other things to debug beyond the basics. I admire those people who can do all the computer simulation in their head, but many of us want good debugging support, ever since the mid 90s (well, it really started with Microsoft's CodeView in the late 80s). PL abstractions should consider that in their designs, not just elegant conciseness. Code isn't just read.

What you call "Arbitrary nonsense" is for others good practice. For loops allow you to check all the conditions of the loop in one single line, without having to read the body of the loop, which i consider good practice.

Speak the truth, brother. Sadly I've seen production code (I do not work at Microsoft) that contains assumptions that are really that bad..

Calling the function again when the user doesn't exist could in fact be nonsensical and wrong. It could be due to failing to break out of some loop or whatever, not necessary an explicit "we don't have the user; let's branch backwards" logic. Perhaps that looping was not discovered simply because that case doesn't arise: the user always exists. Except, oops, when it appears not to exist due to being pruned because of the "user" substring; then the incorrect backwards branch problem is exposed.

Calling the function again may be entirely logical and may be because of independent state, e.g. locks or security. Think of the famous problem we had for decades with file deletion hanging for 10 seconds or so if you tried to delete a file in use. Somebody traced and disassembled the code; it was literally a hardcoded loop that did 10 iterations of attempting to get a lock on the file followed by sleeping one second if failed... The loop-and-sleep combo there might have been a hack, but it was excusable.

The programmers evidently didn't consider this failure mode. I guess they did consider others. Code could look like this:

   while(!done)
   {
     try
     {
       foo();
       baz();
       done = true;
     }
     catch(...) {}
   }

with baz failing, but the retry present to handle cases where foo fails.

Let's assume that it has a set number of attempts each with some delay.

Let's also assume that whatever this is has multiple instances for some reason; maybe it's something called as part of an update process for system accounting information.

If every process on the machine did this every time it got re-scheduled? Yeah, I can see that.

Oddly specific "guess". Is there something you want to tell us? :)

Yeah it sounds like some kind of "injection".