_setmaxstdio() crash

[John E]

To my astonishment, I just realised that the following line will crash a program in both Windows 7 and 8.1

_setmaxstdio(2049);

I do realise that the maximum limit is 2048 - but I didn't expect a higher number to actually crash! Does this need to get flagged up to Microsoft..?

[VictorN]

You can try to provide your feedback here: https://docs.microsoft.com/en-us/cpp...o?view=vs-2017

[John E]

Oops - I just realised this is in an old version of Visual C++ (VS2005). It's probably been fixed since then !

[John E]

You can try to provide your feedback here: https://docs.microsoft.com/en-us/cpp...o?view=vs-2017

I'm hoping this isn't a bad sign but I followed that link and clicked on the button to leave feedback (which required me to log into GitHub for some reason). A couple of minutes later I got an email from GitHub, telling me:-

docs.microsoft.com with scopes was recently authorized to access your GitHub account

Time to change my GitHub password maybe?

[2kaud]

To my astonishment, I just realised that the following line will crash a program in both Windows 7 and 8.1

_setmaxstdio(2049);

I do realise that the maximum limit is 2048 - but I didn't expect a higher number to actually crash! Does this need to get flagged up to Microsoft..?

This behaviour is as designed and documented - and not a bug! For an invalid parameter, by default the Invalid Parameter Handler routine calls the internal function _invoke_watson() which causes the application 'to crash'. To avoid this, you need to set your own invalid parameter handler using _set_invalid_parameter_handler(). See

https://msdn.microsoft.com/en-us/library/ksazx244.aspx
https://msdn.microsoft.com/en-us/library/a9yf33zb.aspx

PS. To report a problem with the current version of VS/runtime/WIN32 etc, from VS2017/Help/Send Feedback/Report A Problem. You will be asked to create/sign in with a MS account (nothing to do with Github!) where you can search for reported problems, fixed problems, outstanding etc etc and raise your own. You can track the status of any reported problem from being raised, to being evaluated and if found to be a bug through to it being fixed in a particular VS release. So far I've had 4 reported problems acknowledged as bugs and fixed in various release of VS2017.

[John E]

Thanks guys - what brought this to my attention initially was that I wondered if 2048 is still the upper limit (which it does seem to be). I know that Windows offers alternative functions (CreateFile() / OpenFile() etc) which have a much higher limit but unfortunately they're Windows-specific. For cross-platform apps it's still necessary to use open() etc which has this unbelievably small limit. 2048 open files (across all running apps) is a ludicrous limitation for a modern OS

[2kaud]

is a ludicrous limitation for a modern OS

Yes, but it's not the limit of the OS - its an historical limit of the c library! If you want more than 2048 open files you can't use the c library functions - you need to use the underlying OS functions.

[John E]

Yes, but it's not the limit of the OS - its an historical limit of the c library! If you want more than 2048 open files you can't use the c library functions - you need to use the underlying OS functions.

Hmmm... that's not the case on Linux or Mac as far as I know. Both OS's still use open() etc but they aren't limited to 2048 files (not AFAIK anyway...)

[2kaud]

Hmmm... that's not the case on Linux or Mac as far as I know. Both OS's still use open() etc but they aren't limited to 2048 files (not AFAIK anyway...)

If you're right - and I don't use Linux or Mac so I don't know - then they're upped the limit and MS haven't..... Doh! - or MS have just chosen 2048 for their c library implementation.

PS I think the original limit under MS-DOS v2 was around the 20 mark - then it went to 255 and then to 2048 under Windows xxx, so it's improved!

[John E]

Bit of a long shot... but given that the limit of 2048 is pretty low, is there a function that'll tell me how many file handles are still remaining? (i.e. how many more files could theoretically be opened?)

[2kaud]

Not that I know of - but if you encapsulate file open/close into a RAII class with a static count, then you'll be able to determine how many files are open and hence how many handles still remain.

Just out of interest - why does the application need so many concurrent open files?

[John E]

It's a Digital Audio Workstation (a computerised representation of the old multi-track tape machines). Each user can be running dozens of tracks and each track will typically contain 80 or more sound clips. Back in the days when RAM was expensive it was common practice to just keep hundreds of files permanently open and only load the data in small chunks, as needed. But I guess with memory being so cheap nowadays it'd probably be viable now to just keep everything permanently in RAM. Unfortunately though, I've a feeling that'd mean a major design change...