It is valid in JavaScript at least, and for once even returns a sensible value: NaN. I half expected it to return 0 or something equally stupid.
Meanwhile, I'm kind of disappointed that the rage thread was closed down, because after working on my dissertation research more today I legitimately wanted to throw my computer many times. I was tasked with adding some profiling code to a popular genetic database search tool known as BLAST, which is written in an amalgamation of C and C++. I just had to time two things:
1. The amount of time spent doing some string tokenization / comparison.
2. The amount of time spent reading database records off of the disk.
After 10 hours I nearly gave up. It took me 5 hours to figure out how to just compile the single binary I needed to work on instead of the whole thing, which was necessary because the regular build took 90 minutes to complete and generates 4.2GB of binaries. I only needed 1 out of the 31 programs compiled. It took me those 5 hours to figure out that there were 75 separate internally built libraries without comprehensive makefile coverage, meaning that updating the source file didn't rebuild anything, much less the internal libraries and final binary. So I wrote a shell script that deleted several files and ran multiple make commands, and it still takes several minutes to compile.
After figuring that out, getting step 1 above was simple at least.
Step 2 I nearly gave up on after 4 hours of searching files for fread() or ifstream or fstream or any other indication of code that was doing file reads, running it in GDB and stepping through call stacks in vain hope of finding something. After I hit 18 levels deep in a call stack that ended up in several .hpp template headers, I finally gave up and just ran it through Valgrind with the Callgrind tool so I could look at a call graph and figure out where the disk reads were happening. Oh... at that point I realized it was all mmap()ed, so of course I'd never see any fread()s or the equivalent.
I screamed internally a lot and ended up wrapping timing code around what I hoped was the code that read the mmap()ed file, which is now giving me fishy looking numbers. I guess it's possible that it can read a 3.7 GB database file's contents in 12 seconds, but I don't know if I trust it.
Worse yet, I discovered that this thing has some kind of software managed cache and garbage collector, which I really need to disable or cripple so I can compare the results against my own research.
I wouldn't wish this on my worst enemy. I can't comprehend how anyone on the NCBI team even managed to put this thing together, much less maintain it. It's truly terrifying - so many C macros and faux C++ objects and inheritance using function pointers... and it's even mashed up with real C++ code. I don't know why they have this horrible mix when it could all be C++.
It's also little wonder nobody learns C or C++ in college anymore. Who would want to deal with this unless they had no choice?