Why do built-in JScript functions not appear in the typeinfo?

A reader sent me an email over the weekend asking about some odd behaviour in the guts of the JScript engine. Unfortunately, they didn't include an email address that worked; I just got a bounce message back, Ben. Therefore I'll just answer the question here.

To briefly describe the problem: the user fetches the JScript "Math" object from the script engine by calling ParseScriptText to evaluate the expression "Math". This returns an IDispatch object. The dispatch object can be queried for dispatch ids for "sin" and "cos" and all that. It can be successfully invoked. Everything appears to be good. But when the user calls GetTypeInfo, the type description structure says that the object has zero functions. What's up with that?

Clearly the typeinfo is out of step with reality. The user has in fact found two bugs. The first is that the typeinfo building code only adds to the typeinfo those functions which have already been dereferenced. So, had you called "sin" once already, "sin" would be added but nothing else.

However, the second bug trumps the first one; built-in functions are automatically skipped when adding function descriptions to the typeinfo. I'm not sure what I was thinking when I wrote that logic; it was a long time ago. So even if you have already dereferenced a built-in function object, it won't get added to the typeinfo.

User-defined functions should be always correctly added to the typeinfo; they are automatically dereferenced when they are created.

I wrote almost all the typelibrary code, and I regret the errors. However, it's unlikely that either of these flaws will ever be fixed, and clearly both would have to be fixed in order to make the given scenario work correctly. Both fixes would touch a lot of complex code and are therefore quite risky. We try to not apply risky fixes to fix a problem that, to my knowledge, only one person has ever noticed in the last seven or eight years! If there's a massive outcry to make typeinfos for built-in objects work correctly, I'll pass that along to the sustaining engineering team; I wouldn't hold my breath waiting for a fix if I were you.

Thanks for bringing this to my attention.

Comments

• Anonymous
  December 06, 2004
  Was GetTypeInfo trying to implement the ECMAScript semantics that say builtin functions are not returned by the for..in operator? Yeah, that's the ticket!
  
  
• Anonymous
  December 06, 2004
  That might have had something to do with it, but if so, it's not very good logic. The type info and the dispatch object should be consistent; that some propertys are DontEnum should not imply that they are omitted from the type info.
  
  More likely is that it was just a straightforward mistake. The scenario we were going for was a bunch of "macro" user-defined functions exposed to a host. So I implemented and tested the code to meet that scenario, and did not consider the more general applicability of the operation. That's my best guess.
  
• Anonymous
  December 06, 2004
  > We try to not apply risky fixes to fix a
  > problem that, to my knowledge, only one
  > person has ever noticed in the last seven or
  > eight years!
  
  Don't count on that. What you have observed is that only one person reported it to you through your blog. There might have been thousands seven or eight years ago, who refused to pay Microsoft's fees to report Microsoft's bugs to Microsoft, who didn't know how to slide one past them and e-mail you directly.
  
  For comparison, to the best of my knowledge only one person harps noisily about the amount of damage that Windows 95 did in destroying all files in SCSI disk partitions, but that doesn't mean there was only one victim. In those days external SCSI disks were flying off the shelves of computer stores just as USB2 disks do now, and PCMCIA-SCSI interface cards were flying off the shelves. One vendor of PCMCIA-SCSI interface cards was aware of the brokenness of Windows 95 FDISK and they distributed their own formatter with it (but they aren't the vendor of any of the cards I bought). Some other vendors gradually became aware of the problem and belatedly added similar tools, but some didn't. How is it that Microsoft remained unaware? (And how is it that Windows 98 FDISK didn't have the same disastrous bug, considering that Microsoft remained unaware of it in Windows 95?) No one paid your company's fee to inform your company about it, but that sure doesn't mean the number of victims was zero (or one).
• Anonymous
  December 06, 2004
  > There might have been thousands seven or eight years ago, who didn't know how to e-mail you directly.
  
  Presumably these thousands of people also did not post to newsgroups, which Peter Torr and I read religiously looking for exactly such problems. Presumably they also did not send email to the publically available "report a bug against scripting" email address. And presumably they didn't go to msdn.microsoft.com/scripting, where they could read Andrew Clinick's Scripting Clinic, and email him directly as well.
  
  We did our best to make it easy for people to report bugs to us.
• Anonymous
  December 07, 2004
  Out of curiosity, what is the test suite for the scripting infrastructure like? It seems like a decent set of automated unit tests would make this sort of fix effortless.
  
  I agree that the bug is too trivial and the feature too rarely unused to bother with though. Plus I've heard what the MS validation team is like.
• Anonymous
  December 07, 2004
  "It seems like a decent set of automated unit tests would make this sort of fix effortless. "
  
  I think that getting "a decent set of automated unit tests" is quite difficult. I'm in the middle of writing such a suite for a small Scheme-like interpreter with limited external interfacing capabilities. Right now I'm at about 1000 test cases, and that's a small fraction of what it'll need to be to be comprehensive.
  
  As an example, take the (to-upper-case <x>) function. It takes a string and converts it to uppercase. Here's what I'm looking for in my test suite for this function:
  
  * The input string isn't changed
  * Upper case and non-alphabetic letters are left alone
  * Lower case letters are converted to their correct match
  * It handles the empty string
  * It correctly handles the first character of the string
  * It correctly handles the last character of the string
  * It handles very long strings
  
  At this point, I look at the code and write test cases for code paths I haven't hit yet in my more functional testing.
  
  That's one test script for one simple function out of over three hundered in my base library. I don't handle internationalization, or fancy character sets, and I don't have multiple string formats to test.
  
  I can't even begin to imagine what a comprehensive test suite for JScript would look like. I'd be fascinated to find out more, though. I'm sure that Microsoft has the resources to develop a test system that boggles the mind.
• Anonymous
  December 07, 2004
  "Effortless"???
  
  Ha ha ha ha ha ha ha!
  
  Oh, wait, you're serious.
  
  The script team testers developed several hundred thousand automated test cases which verify that the language and runtime behave as specified. We also have access to the IE team's compatibility suite, which contains on the order of several million real-life web pages culled from the web over the last decade.
  
  However, we have almost no tests which test the script engines at the COM interface level.
  
  We devoted our big-in-talent-few-in-number test team to verifying the behaviour of the part of the engines that affects hundreds of millions of end users: the language itself. The behaviour of the engines at the interface level is of interest to only those few people who develop custom hosts; there are hardly any tests that target specifically those interfaces. For all I know, there might be zero tests which test the type library generation behaviour.
• Anonymous
  December 07, 2004
  "The script team testers developed several hundred thousand automated test cases which verify that the language and runtime behave as specified."
  
  If this is propriatary, I understand, but I have a couple questions:
  
  * Do you target a 100% success rate?
  * When Microsoft develops script engine test cases, are you looking for code coverage, requirements coverage, or both? Are there seperate suites for code and requirenments coverage?
  * How do you test something like floating point addition? I assume that JScript floating point depends on the underlying library, so do you focus on the behavior of the JScript engine's math code, or do you actually test the behavior of the underlying math logic?
  
  Thanks,
  Mike
• Anonymous
  December 07, 2004
  Before a release goes out to the public we do a complete test pass -- which takes a couple days -- and investigate all failures and regressions. We are hard-core about not introducing accidental regressions in the language.
  
  Primarily we design the tests to cover the specified behaviour. However, at some point during the test case development process we do a coverage run to figure out whether there are large areas of untested code or not.
  
  I don't know the details of our specific floating-point library tests, but there is a LOT of JScript-specific float logic in there, which must be tested. Clearly something as basic as addition is going to be done by the FPU, but stuff like converting floats to strings, etc, is all custom code.
• Anonymous
  December 07, 2004
  The comment has been removed
• Anonymous
  December 07, 2004
  12/6/2004 5:48 PM Eric Lippert
  
  >> There might have been thousands seven or
  >> eight years ago, who didn't know how to
  >> e-mail you directly.
  >
  > Presumably these thousands of people also
  > did not post to newsgroups, which Peter Torr
  > and I read religiously looking for exactly
  > such problems.
  
  Then you are right. Also I congratulate you and Mr. Torr for your dedication. Imagine how much different your company's reputation could be if your colleagues on other products (e.g. Windows 95) had done the same.
• Anonymous
  December 12, 2004
  By the way, again re. 12/6/2004 5:48 PM Eric Lippert
  
  > newsgroups, which Peter Torr and I read religiously
  
  Does that mean newsgroups that are hosted by Microsoft's servers or Usenet newsgroups that are hosted by most ISPs? Most ISPs carry things like alt.os.windows-xp and carried comp.os.ms-windows.win95.moderated in its day, but I rarely saw postings from Microsoft. There were a lot of people whose corporate firewalls didn't pass NNTP and/or for other reasons weren't accustomed to Microsoft-hosted newsgroups, but had access to ordinary newsgroups. Which kind did you read?
• Anonymous
  December 13, 2004
  I don't remember the exact list -- this was like five years ago -- but pretty much every newsgroup that had "Javascript" in the title somewhere.
  
  One day I was reading the newsgroups and someone asked a really complicated question. I was going to answer it myself but then I though no, let's wait and see if that hard-core guy in Australia answers it for me. And sure enough, he gave a more complete and cogent answer than I would have. So I sent him an email and asked if he wanted to work for us. Fortunately we managed to convince Peter to move from Australia to beautiful Redmond, and the world has never been the same since.
  
  
• Anonymous
  December 19, 2004
  The comment has been removed