Is there a 2048 character limit for OFN_ALLOWMULTISELECT in MFC or isn’t there?

The MFC documentation for CFile­Dialog contains the following strange warning:

When the user allocates their own buffer to accommodate OFN_ALLOW­MULTI­SELECT, the buffer can't be larger than 2048 or else everything gets corrupted (2048 is the maximum size).

The sudden informality of the phrase "or else everything gets corrupted" is surprising but also sounds vaguely familiar to me. I think I was the one who wrote that phrase over a decade ago as part of my investigation into a defect in the common dialog functions. Somebody must have forwarded my analysis to the MFC documentation team (since the problem was originally in an MFC application), who just copied and pasted it into the official documentation.

The limitation in question existed in Windows 95 and was fixed in Windows NT 4 and Windows 98, so the remarks do not apply to any modern version of Windows.

What struck me is that the MFC documentation picked up this limitation rather than deferring to the Platform SDK team to document the issue. It means that when the bug is fixed in the platform, the MFC documentation becomes wrong.

The limitation is not mentioned in the Visual Studio 2008 version of the CFile­Dialog documentation, which suggests either that the Visual Studio folks deferred documenting the issue to the Platform SDK team, or they somehow figured out that the issue no longer applied and removed the offending text.

Comments (17)
  1. Cesar says:

    Documentation is always a problem.

    Unless it is right next to the code (like Doxygen comments), you can count on it to get out-of-date. And even if it is right next to the code, you cannot be sure it will be kept up-to-date.

  2. henke37 says:

    I am willing to bet that the phrase "or else everything gets corrupted" was what made it catch their attention and start investigating the issue. If anything it is quite vague and at the same time seems to indicate serious results.

    As for anyone wanting to complain about it being unprofessional, remember the expected receiver and not where it ended up.

  3. DrkMatter says:

    "the buffer can't be larger than 2048 or else everything gets corrupted (2048 is the maximum size)"

    This sounds like this was written by the same person that wrote the documentation for the Holy Hand Grenade.

  4. dave says:

    re: Cesar

    There is an inverse square law relating documentation accuracy to distance from that which is documented.

  5. Daniel says:

    DrkMatter, wonderful, I had the same feeling! "2048 be the number, neither be it 2047" etc.

  6. Joshua says:

    We have a quote at my company. "Documentation always wrong."

    It recalls the faux Chinese proverb "Fortune cookie always wrong."

  7. JustSomeGuy says:

    This is why Python fans (Monty, not Guido) should never be allowed to communicate with each other :-)

  8. JM says:

    "Once the number 2048, being 2^11, be reached, then overflowest thou the buffer towards the direction of the system structures, which, being unprotected by memory management, shall snuff it."

    Now if only they'd copy-pasted *that* into the documentation.

  9. ThomasX says:

    So it got fixed in Windows 98 and NT4. Did you make sure that nobody relied on the corruption? If yes, how?

  10. Pi says:

    I've been laughing out loud at the holy hand grenade parallels for the last three minutes.

  11. rgove says:

    "What struck me is that the MFC documentation picked up this limitation rather than deferring to the Platform SDK team to document the issue."

    Since the whole point of MFC was to insulate you from the platform, surely deferring to the platform documentation would be the wrong thing to do. It would instantly double the amount of documentation you had to read to be sure you understood a given MFC API.

  12. Anonymous Coward says:

    Software that relies on catastrophic failure. I'd like to see that.

  13. I wish there was an upvote option for JM's comment.

  14. Gabe says:

    One man's catastrophic failure is another man's predictable setting of an otherwise uninitialized variable.

  15. Random832 says:

    How exactly does this error work? The only way I can think of that making a buffer too large can cause corruption is if that buffer's size controls an overflow check that is being relied on to avoid overflowing a different (fixed size of 2048, presumably) buffer – but then what's the point of allowing the user to allocate a buffer at all if there's already an internal buffer?

    The other possibility is that it's causing an arithmetic overflow in some sort of allocation of [again] an internal buffer. But what would it be being multiplied by that would overflow?

  16. Walter says:

    The VS 2008 version (…/dk77e5e7(VS.90).aspx) does have the 2048 limit. The vs 2010 version (…/dk77e5e7(v=VS.100).aspx) does not.

  17. Gabe says:

    Random832: Assume that there is a function which stack-allocates a buffer of size 2048, but initializes nMaxFile of it. This works fine if nMaxFile <= 2048, but corrupts the stack otherwise. The reason you have to allocate your own buffer is that the function can't return a pointer to its buffer on the stack.

    I don't have the source handy, but surely somebody who reads this can find the source for MFC from 1995 and find out exactly what the problem was.

Comments are closed.

Skip to main content