Statement limit bug
JoeOtto
JScript/javascript language DLL has a bug in the number of statements
accepted in a script file.
To reproduce: Create a file test.js with 32768 repetions of the statement "x
= 3;". They can be on separate lines or on the same line. Attempting to
execute the file throws a syntax error.
Replacing the 1st ";" with a "," to create a file with 32767 statements
prevents the error from being thrown.
The bug isn't confined to the Windows Script Host. We actually discovered
it in IE7 and then reproduced it in WSH.
Also, it isn't confined to the top execution context. It's easily
reproduced inside a function. But it does seem to be confined to individual
execution contexts. In other words if the 32768 statements are broken up
into 2 functions, the error goes away.
This is mainly a problem for server-side functionality that automatically
generates code which is fed to the clients. For instance, a server-side
object that generates a large array of data may (and in many cases does)
generate individual statements assigning one array element per statement.
Does anyone know if this is going to be fixed?
Michael Harris (MVP)
> Apparently a new jscript.dll was shipped with IE7. This new version
> of the JScript/javascript language DLL has a bug in the number of
> statements accepted in a script file.
>
> To reproduce: Create a file test.js with 32768 repetions of the
> statement "x = 3;". They can be on separate lines or on the same
> line. Attempting to execute the file throws a syntax error.
Doesn't repro for me on xp sp2 (2gb ram) with IE7, even 64K or 128K
statements...
>
> Replacing the 1st ";" with a "," to create a file with 32767
> statements prevents the error from being thrown.
>
> The bug isn't confined to the Windows Script Host. We actually
> discovered it in IE7 and then reproduced it in WSH.
>
> Also, it isn't confined to the top execution context. It's easily
> reproduced inside a function. But it does seem to be confined to
> individual execution contexts. In other words if the 32768
> statements are broken up into 2 functions, the error goes away.
>
> This is mainly a problem for server-side functionality that
> automatically generates code which is fed to the clients. For
> instance, a server-side object that generates a large array of data
> may (and in many cases does) generate individual statements assigning
> one array element per statement.
>
> Does anyone know if this is going to be fixed?
--
Michael Harris
Microsoft.MVP.Scripting
Randy Webb
> JoeOtto wrote:
>> Apparently a new jscript.dll was shipped with IE7. This new version
>> of the JScript/javascript language DLL has a bug in the number of
>> statements accepted in a script file.
>>
>> To reproduce: Create a file test.js with 32768 repetions of the
>> statement "x = 3;". They can be on separate lines or on the same
>> line. Attempting to execute the file throws a syntax error.
>
> Doesn't repro for me on xp sp2 (2gb ram) with IE7, even 64K or 128K
> statements...
I can't reproduce it either. XP SP2 IE7 with 440,000 lines it won't
error out.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
JoeOtto
> JoeOtto wrote:
> > Apparently a new jscript.dll was shipped with IE7. This new version
> > of the JScript/javascript language DLL has a bug in the number of
> > statements accepted in a script file.
> >
> > To reproduce: Create a file test.js with 32768 repetions of the
> > statement "x = 3;". They can be on separate lines or on the same
> > line. Attempting to execute the file throws a syntax error.
>
> Doesn't repro for me on xp sp2 (2gb ram) with IE7, even 64K or 128K
> statements...
>
Weird. I've got xpsp2 (1gb ram) /IE7. You did understand that I meant
32768 statements - not bytes, characters, or lines. Right?
Perhaps there is a new algorithm that chooses the size of its statement
table based on available memory...?
I've reproduced this on several systems upgraded to IE7 although none had
2gb ram. They all had 1gb or less.
I was unable to reproduce it at all with IE6.
Michael Harris (MVP)
> meant 32768 statements - not bytes, characters, or lines. Right?
Yes I understood the repro case (and I assume Randy did as well :-).
>
> Perhaps there is a new algorithm that chooses the size of its
> statement table based on available memory...?
>
> I've reproduced this on several systems upgraded to IE7 although none
> had 2gb ram. They all had 1gb or less.
>
> I was unable to reproduce it at all with IE6.
I take it you have no systems with more than 1gb ram???
Note the Randy can't repro either but didn't state amount of ram...
--
Michael Harris
Microsoft.MVP.Scripting
JoeOtto
"Michael Harris (MVP)" wrote:
> I take it you have no systems with more than 1gb ram???
That's correct. But I'll have the guys set something up in the lab tomorrow.
> Note the Randy can't repro either but didn't state amount of ram...
Noted. Hopefully he can repost with that detail.
I appreciate both your and Randy's responses. I'll reply again after
testing with more RAM.
Randy Webb
>> Weird. I've got xpsp2 (1gb ram) /IE7. You did understand that I
>> meant 32768 statements - not bytes, characters, or lines. Right?
>
> Yes I understood the repro case (and I assume Randy did as well :-).
I did, or I thought I did, at first. When I re-tested with 800,000 lines
of x=3; I got no errors, nothing. No indication of a problem.
So, I added a second script block to alert(x) and I didn't get the
alert. Going back to the 32768 statements, with an alert statement
afterwards, I can duplicate it in 2 different machines.
32767 statements - alert.
32768 statements - no alert.
I did not get a syntax error though, it seems to have simply ignored the
file.
>> Perhaps there is a new algorithm that chooses the size of its
>> statement table based on available memory...?
>>
>> I've reproduced this on several systems upgraded to IE7 although none
>> had 2gb ram. They all had 1gb or less.
>>
>> I was unable to reproduce it at all with IE6.
>
> I take it you have no systems with more than 1gb ram???
>
> Note the Randy can't repro either but didn't state amount of ram...
First test machine: 4gb Ram
Second test machine: 512 mbs Ram
So I don't think it's Ram related. Try adding an alert(x) either to the
end of the file or in a second script block and see if you get the alert.
JoeOtto
> Michael Harris (MVP) said the following on 2/11/2007 4:36 PM:
> >> Weird. I've got xpsp2 (1gb ram) /IE7. You did understand that I
> >> meant 32768 statements - not bytes, characters, or lines. Right?
> >
> > Yes I understood the repro case (and I assume Randy did as well :-).
>
> I did, or I thought I did, at first. When I re-tested with 800,000 lines
> of x=3; I got no errors, nothing. No indication of a problem.
Yikes! I just reread my original post. My aplogogies to you and Michael
for the confusion. I didn't make it clear that I was directly executing
test.js with Windows Script Host - not just including it in a web page.
Although IE tends to suppress many errors, WSH doesn't. That's how I saw the
errors I posted about.
Randy Webb
> "Randy Webb" wrote:
>
>> Michael Harris (MVP) said the following on 2/11/2007 4:36 PM:
>>>> Weird. I've got xpsp2 (1gb ram) /IE7. You did understand that I
>>>> meant 32768 statements - not bytes, characters, or lines. Right?
>>> Yes I understood the repro case (and I assume Randy did as well :-).
>> I did, or I thought I did, at first. When I re-tested with 800,000 lines
>> of x=3; I got no errors, nothing. No indication of a problem.
>
> Yikes! I just reread my original post. My aplogogies to you and Michael
> for the confusion. I didn't make it clear that I was directly executing
> test.js with Windows Script Host - not just including it in a web page.
> Although IE tends to suppress many errors, WSH doesn't. That's how I saw the
> errors I posted about.
Yes, I thought you were using IE as the platform. When testing it with
both CScript and WScript I can duplicate the errors at lines 32767/32768
lines of code. And that is still on both machines.
Michael?
JoeOtto
>
> Yes, I thought you were using IE as the platform. When testing it with
> both CScript and WScript I can duplicate the errors at lines 32767/32768
> lines of code. And that is still on both machines.
Thanks for the confirmation. That's consistent with my presumption that the
bug isn't in IE7 per se, but in jscript.dll version 7, which ships with IE7.
The bug is in the language dll - not in the host.
> Michael?
Hopefully Michael - or anyone else reading this - has connections within the
development team and can point out the problem to them for resolution.
Michael Harris (MVP)
> both CScript and WScript I can duplicate the errors at lines
> 32767/32768 lines of code. And that is still on both machines.
>
> Michael?
(WSH hosted test jscript)
jscript.dll version 5.6.0.8831
x = 3;
x = 3;
x = 3;
x = 3;
...repeated for a total of n 'x = 3;'statements
...for n = 32767, 32768, 64K, and 128K
x = 3;
WScript.echo(x);
In no cases do I get any errors and the WScript.echo always worked...
--
Michael Harris
Microsoft.MVP.Scripting
JoeOtto
> > Yes, I thought you were using IE as the platform. When testing it with
> > both CScript and WScript I can duplicate the errors at lines
> > 32767/32768 lines of code. And that is still on both machines.
> >
> > Michael?
>
> (WSH hosted test jscript)
> jscript.dll version 5.6.0.8831
That explains it. IE7 upgraded my jscript.dll to 5.7.0.5730. That's where
I think the bug is. Did you reinstall WSH, etc. after the IE7 install to get
that version back?
Michael Harris (MVP)
>> jscript.dll version 5.6.0.8831
>
> That explains it. IE7 upgraded my jscript.dll to 5.7.0.5730. That's
> where I think the bug is. Did you reinstall WSH, etc. after the IE7
> install to get that version back?
Yes, per...
MS06-023: Vulnerability in Microsoft JScript could allow remote code
execution
http://support.microsoft.com/kb/917344
...which appears to simply backlevel jscript.dll to a prior version/build.
--
Michael Harris
Microsoft.MVP.Scripting
JoeOtto
> >> (WSH hosted test jscript)
> >> jscript.dll version 5.6.0.8831
> >
> > That explains it. IE7 upgraded my jscript.dll to 5.7.0.5730. That's
> > where I think the bug is. Did you reinstall WSH, etc. after the IE7
> > install to get that version back?
>
> Yes, per...
>
> MS06-023: Vulnerability in Microsoft JScript could allow remote code
> execution
> http://support.microsoft.com/kb/917344
>
> ....which appears to simply backlevel jscript.dll to a prior version/build.
??? You must have been running a beta/rc build for your IE7 install to
predate this patch.
It just doesn't seem rational that jscript.dll (5.6.0.8831/12-May-2006) is a
fix for a problem in jscript.dll (5.7.0.5730/17-Oct-2006).
I just checked and I installed the KB917344 update on 6/15/2006 - 2 days
after it was released. IE7 replaced the jscript.dll and vbscript.dll files
with the 5.7.0.5730 versions when I installed it on 12/11/2006.
Are you recommending that I reinstall the June update? Will it even replace
an obviously newer file?
> --
> Michael Harris
> Microsoft.MVP.Scripting
>
>
>
Michael Harris (MVP)
> to predate this patch.
>
> It just doesn't seem rational that jscript.dll
> (5.6.0.8831/12-May-2006) is a fix for a problem in jscript.dll
> (5.7.0.5730/17-Oct-2006).
>
> I just checked and I installed the KB917344 update on 6/15/2006 - 2
> days after it was released. IE7 replaced the jscript.dll and
> vbscript.dll files with the 5.7.0.5730 versions when I installed it
> on 12/11/2006.
>
> Are you recommending that I reinstall the June update? Will it even
> replace an obviously newer file?
I installed via WindowsXP-KB917344-x86-ENU.exe, not the latest WSH RTW
version for XP.
The fact that I did was probably part of applying/installing things I had
done on an older box when I got a new box in December (with IE7 already on
it) without thinking about the fact that I had a newer jscript.dll via IE7.
In any case, that install package apparently will downgrade by design, not
like the normal WSH install package which probably wouldn't. So the fact
that I have an older jscript.dll than IE7's is probably inadvertent ;-)...
As I recall whern snooping on the old box when I installed IE7 myself, only
a newer jscript.dll came via IE7. Other WSH binaries were still the 5.6.x.x
versions.
What route you should take is up to you. Running with with a jscript.dll
5.6.x.x rather than 5.7.x.x certainly hasn't caused me any grief...
As an FYI, on another xp sp2 box with ie7 and the 5.7.x.x version of
jscript.dll, I can repro the problem.
--
Michael Harris
Microsoft.MVP.Scripting
JoeOtto
> I installed via WindowsXP-KB917344-x86-ENU.exe, not the latest WSH RTW
> version for XP.
>
> The fact that I did was probably part of applying/installing things I had
> done on an older box when I got a new box in December (with IE7 already on
> it) without thinking about the fact that I had a newer jscript.dll via IE7.
>
> In any case, that install package apparently will downgrade by design, not
> like the normal WSH install package which probably wouldn't. So the fact
> that I have an older jscript.dll than IE7's is probably inadvertent ;-)...
Makes sense.
> As I recall whern snooping on the old box when I installed IE7 myself, only
> a newer jscript.dll came via IE7. Other WSH binaries were still the 5.6.x.x
> versions.
On mine they're all 5.6 except for jscript.dll and vbscript.dll.
> What route you should take is up to you. Running with with a jscript.dll
> 5.6.x.x rather than 5.7.x.x certainly hasn't caused me any grief...
I've got ~10,000 internal desktops that I need to decide for. But that's
just the beginning. There are countless desktops that hit our web sites that
aren't under my control.
This is obviously a limitation that wasn't present in the 5.6 language.
I've tested those up to over a million lines successfully.
The way I see it is if Microsoft doesn't fix this and deploy publicly we're
going to have to recode many of our web apps. In other words a hotfix from
them won't be adequate due to our external customers.
The really hideous thing about this bug is the way it fails silently in a
web browser. The only way it's detectable is to already know the app
intimately enough to realize that some of the code didn't execute.
> As an FYI, on another xp sp2 box with ie7 and the 5.7.x.x version of
> jscript.dll, I can repro the problem.
Thank you for your trouble confirming the bug.
Please, if you know any of the MS developers can you point them at this
thread?
> --
> Michael Harris
> Microsoft.MVP.Scripting
Michael Harris (MVP)
>> jscript.dll, I can repro the problem.
>
> Thank you for your trouble confirming the bug.
>
> Please, if you know any of the MS developers can you point them at
> this thread?
>
I did before I even replied to your first post though I haven't gotten a
response yet.
--
Michael Harris
Microsoft.MVP.Scripting
JoeOtto
> > Please, if you know any of the MS developers can you point them at
> > this thread?
> >
>
> I did before I even replied to your first post though I haven't gotten a
> response yet.
Thank you. I really appreciate it.
> --
> Michael Harris
> Microsoft.MVP.Scripting
Dr J R Stockton
585CA3...@microsoft.com>, Mon, 12 Feb 2007 20:22:00, JoeOtto
<Joe...@discussions.microsoft.com> posted:
>
>The really hideous thing about this bug is the way it fails silently in a
>web browser. The only way it's detectable is to already know the app
>intimately enough to realize that some of the code didn't execute.
>
The bug is that the tail of the code is lost?
If you put var EndOfFred=1 at the end of fred.js then a page
calling fred.js can test that it is complete.
Or you can write your Jscript so that a stub function at the very end
calls a real function preceding it.
If you put at the head of the HTML a link to an anchor at the end, a
suitable links-check can verify that the end is there.
Perhaps something of that general nature could detect what you're
concerned about. IIRC, such have found an FTP incomplete transfer and
an HTML auto-editing failure in my work.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
JoeOtto
> The bug is that the tail of the code is lost?
Not really. The bug is that if jscript.dll tries to parse a code block with
>32K statements, it aborts the execution. This effectively loses *all* the
code in that block.
> If you put var EndOfFred=1 at the end of fred.js then a page
> calling fred.js can test that it is complete.
>
> Or you can write your Jscript so that a stub function at the very end
> calls a real function preceding it.
>
> If you put at the head of the HTML a link to an anchor at the end, a
> suitable links-check can verify that the end is there.
>
> Perhaps something of that general nature could detect what you're
> concerned about. IIRC, such have found an FTP incomplete transfer and
> an HTML auto-editing failure in my work.
You're of course correct that there are several methods available that can
detect if a piece of code didn't execute. Although code like this may be
necessary in rare circumstances, it should hardly be the norm.
Anyway... If it's absolutely necessary, new apps could employ such methods.
But many of our existing apps would still require remediation. This would
be a considerable effort.
My point is that it did work under IE6. In fact IE6 would allow over a
million lines in a code block. The new jscript.dll distributed with IE7 has
broken it by imposing a 32K statement limit.
If Microsoft were to fix this and distribute it via their monthly updates,
no further remediation would be necessary.
Michael Harris (MVP)
>>> this thread?
>>>
>>
>> I did before I even replied to your first post though I haven't
>> gotten a response yet.
I got a reply ackowledging this as a bug, not a deliberate limitation,
inadvertently introduced with a security patch.
They also committed to a fix in the near future (tentatively in March). How
it will be made available is still open but hopefully via the monthly
security patch cycle.
--
Michael Harris
Microsoft.MVP.Scripting
JoeOtto
> I got a reply ackowledging this as a bug, not a deliberate limitation,
> inadvertently introduced with a security patch.
>
> They also committed to a fix in the near future (tentatively in March). How
> it will be made available is still open but hopefully via the monthly
> security patch cycle.
That's great news! Thank you again for all your help.
> --
> Michael Harris
> Microsoft.MVP.Scripting
VK
> Apparently a new jscript.dll was shipped with IE7. This new version of the
> JScript/javascript language DLL has a bug in the number of statements
> accepted in a script file.
That is not nice to make a panic like that - I nearly got a heart
attach of reading the title - by taking into account a deployment in
progress we are making right now.
:-(
There are not any limits in statements contained in the source text -
unless you have a XXX Mb .js file made, then maybe.
There are limitations on stack size, so one can break the execution or
even hang up browsers with say for-in loops especially with host
object and/or DOM calls in each loop. For the "desired" effect 32767
is even overkill on this matter. Because you are referring to WSHost
works then one of opportunities - just one of them - could be that you
are getting the common jscript.dll slash:
JScript engine is not attached to browser installation but in fact a
native Windows system resource where serving HTML pages scripts is
just one of shared tasks. It is true that each newer IE version is
coming with new jscript.dll - but it is easy and often happens to
override it with old crap while playing with WSHost.
So the first target is to ensure that these are 32767 or more
hardcoded statements in the source and not some occasionally crafted
stack vulnerability check with "for (var i=0; i<32767; i++){..."
The second one is to see if admins are not eating their doughnuts for
nothing :-) thus no one IE 7 is running under JScript 5.6 or 5.1 - the
latter happens either and much more often than it should.
Basically you need the result of execution
ScriptEngineMajorVersion() + '.' + ScriptEngineMinorVersion() + '.' +
ScriptEngineBuildVersion()
followed by clientCaps study results. IE major has to correspond to
jscript.dll minor (7.0 - 5.7) and lesser-minor the same for both
(7.0.xxxx - 5.7.xxxx)
Make an auto-submit page and ensure that all involved users will visit
it in 48 hrs under the risk of death penalty for non-obeyance :-)
As an option send bulk mail "Easter holidays schedule update" or
similar with necessary URL in it. It works better than "Pamela
Anderson naked" lesser risk of sexual harassment issues.
P.S.
Windows XP SP2
1.8GHz / 512Mb RAM
IE 7.0.5730.11
JScript 5.7.5730
<http://www.geocities.com/schools_ring/ie.html>
probe.js file contains 32767+X statements (for sake of it I added a
dousen or so at the end by copy and past). Plus Y amount of Yahoo auto-
inserted scripting crap.
No problems of any kind.
It also alerts "start", "end" and full JScript version. Pay attention
to yours.
VK
The original engine limits set by Brendan Eich for JavaScript 1.0 are:
1) No more than 2^20 (1,048,576) symbols among all scopes.
2) No more than 2^16 (65,536) atoms - identifiers, numeric literals,
string literals - referred to by source loaded at any instant into one
context (window).
3) 1e6 (1,000,000) continuous control flow transfers before system
alert.
By taking the statement i = 3; as containing two atoms (identifier +
numeric literal) one might expect some troubles for more than 32768 of
such statements by limitation #2... back in 1996.
It is not true anymore at our days AFAIK. So many time passed, so many
memory corruption and stack overflow fixes are made ever since.
Also all modern engines are made by ECMAScript specs where all exact
physical limits are left to the development team.
Out of curiosity one may try to contact Eric Lippert to ask if he used
Netscape's limits for the original JScript engine: so the fact that
IE6/IE7 doesn't care, is it a later extension or such limits were
never in effect for JScript.
Randy Webb
> P.P.S.
>
> The original engine limits set by Brendan Eich for JavaScript 1.0 are:
Totally irrelevant. Maybe you should try reading the entire thread and
understanding what has and has not been shown to date before you babble
incoherently about something that is irrelevant.
VK
> Totally irrelevant.
Here is even more of irrelevance: I guess I cannot sleep anymore. It's
good I have free Monday today.
> Maybe you should try reading the entire thread and
> understanding what has and has not been shown to date before you babble
> incoherently about something that is irrelevant.
Randy, it is not clj here, it is mpsj - so be _soft_ ;-)
Of course I read all thread - why do you think I broke my informal
rule to avoid discussions on microsoft.* ? Exactly because the subject
and some posts made me panic for my particular project.
What made me suspicious though is the lack of any testcases. All "work
- doesn't work" were based on undisclosed testcases. Because making a
test file with 32767 identical statements is a troublesome process, my
primary suspicion remains that everyone used "lazy test" with for()
loops which is all another problem irrelevant to statements' limit.
A full testcase is posted at <http://www.geocities.com/schools_ring/
ie.html>
If anyone can confirm the OP's problem on IE 7 with JScript 5.7.5730
then of course I sorrily wrong.
Otherwise it is another proof of how important is to make a full
scaled testcase to properly identify the problem.
Note: IE 7.0.5730.11 / JScript 5.7.5730 is the result of the latest
security autoupdate for IE distributed in January (beginning of
February? need to look at the journal) for VML engine overflow
vulnerability fix.
The pre-historic JavaScript engine limits are just FYI as I explained
in my post: like "are there any official or half-official documents
where limit of 32767 of something would mean anything important?"
JoeOtto
> On Feb 26, 4:37 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> > Totally irrelevant.
> Here is even more of irrelevance: I guess I cannot sleep anymore. It's
> good I have free Monday today.
>
> > Maybe you should try reading the entire thread and
> > understanding what has and has not been shown to date before you babble
> > incoherently about something that is irrelevant.
>
> Randy, it is not clj here, it is mpsj - so be _soft_ ;-)
> Of course I read all thread - why do you think I broke my informal
> rule to avoid discussions on microsoft.* ? Exactly because the subject
> and some posts made me panic for my particular project.
Please re-read the thread. You've obviously missed it - or you're trolling.
> What made me suspicious though is the lack of any testcases. All "work
> - doesn't work" were based on undisclosed testcases. Because making a
> test file with 32767 identical statements is a troublesome process, my
> primary suspicion remains that everyone used "lazy test" with for()
> loops which is all another problem irrelevant to statements' limit.
I posted details that were adequate enough for 2 MSVPs to reproduce the
problem. Please read the thread. (And please learn the art of copy/paste.
It takes less than a minute to build a file of this size.)
> A full testcase is posted at <http://www.geocities.com/schools_ring/
> ie.html>
Not really. At 32548 statements, the probe.js file is 200 statements short
of what I documented. To see the bug, add a few hundred lines.
> If anyone can confirm the OP's problem on IE 7 with JScript 5.7.5730
> then of course I sorrily wrong.
> Otherwise it is another proof of how important is to make a full
> scaled testcase to properly identify the problem.
It was confirmed twice more than a week before your post.
> Note: IE 7.0.5730.11 / JScript 5.7.5730 is the result of the latest
> security autoupdate for IE distributed in January (beginning of
> February? need to look at the journal) for VML engine overflow
> vulnerability fix.
No. JScript.dll is dated Oct 17, 2006. It was released last year with IE7.
Are you researching any of this? Or just making it up?
> The pre-historic JavaScript engine limits are just FYI as I explained
> in my post: like "are there any official or half-official documents
> where limit of 32767 of something would mean anything important?"
It's not important unless you happen to have a code block that long. Then
it's really important.
To all: I apologize for wasting your time reading this. I have little
experience dealing with trolls. If the troll responds to this post as I
expect, I won't respond again.
Randy Webb
> On Feb 26, 4:37 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> Totally irrelevant.
> Here is even more of irrelevance: I guess I cannot sleep anymore. It's
> good I have free Monday today.
Not only is it irrelevant but it ranks right up there with a flying
rat's ass.
>> Maybe you should try reading the entire thread and
>> understanding what has and has not been shown to date before you babble
>> incoherently about something that is irrelevant.
>
> Randy, it is not clj here, it is mpsj - so be _soft_ ;-)
Only you could be dumb enough not to make that distinction. I am well
aware of where I am posting.
> Of course I read all thread - why do you think I broke my informal
> rule to avoid discussions on microsoft.* ? Exactly because the subject
> and some posts made me panic for my particular project.
Then you obviously failed to understand what was said.,
> What made me suspicious though is the lack of any testcases. All "work
> - doesn't work" were based on undisclosed testcases.
Nonsense. The testcases were very well disclosed.
> Because making a test file with 32767 identical statements is a
> troublesome process, my primary suspicion remains that everyone
> used "lazy test" with for() loops which is all another problem
> irrelevant to statements' limit.
It is a "troublesome process" to create a test file with 32767
statements? Let's see:
for (i=0;i<32767;i++){
document.write('x = 3;<br>')
}
Copy/paste to a text file. Save it.
How much easier do you want it to be? That is *precisely* how I created
my two .js files. By changing the < to <=
> A full testcase is posted at <http://www.geocities.com/schools_ring/
> ie.html>
Nope, you don't have enough statements.
> If anyone can confirm the OP's problem on IE 7 with JScript 5.7.5730
> then of course I sorrily wrong.
It has already been confirmed as a bug by at least 3 people. Did you
fail to comprehend this thread?
> Otherwise it is another proof of how important is to make a full
> scaled testcase to properly identify the problem.
More VK BS?
> Note: IE 7.0.5730.11 / JScript 5.7.5730 is the result of the latest
> security autoupdate for IE distributed in January (beginning of
> February? need to look at the journal) for VML engine overflow
> vulnerability fix.
And it that version that has the bug in it. Re-read the thread, slowly,
and try to comprehend what you read.
> The pre-historic JavaScript engine limits are just FYI as I explained
> in my post: like "are there any official or half-official documents
> where limit of 32767 of something would mean anything important?"
You just don't get it do you? There is a bug in the JScript DLL file
that any file with over 32767 statements will not execute the
statements. The simplest way around it is to include a simple line:
var x=3;
var x=3;
function IEFix() {};
var x=3;
var x=3;
You still wonder why people think you are an idiot, don't you?
Randy Webb
> "VK" wrote:
>> On Feb 26, 4:37 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>> Totally irrelevant.
>> Here is even more of irrelevance: I guess I cannot sleep anymore. It's
>> good I have free Monday today.
>>
>>> Maybe you should try reading the entire thread and
>>> understanding what has and has not been shown to date before you babble
>>> incoherently about something that is irrelevant.
>> Randy, it is not clj here, it is mpsj - so be _soft_ ;-)
>> Of course I read all thread - why do you think I broke my informal
>> rule to avoid discussions on microsoft.* ? Exactly because the subject
>> and some posts made me panic for my particular project.
>
> Please re-read the thread. You've obviously missed it - or you're trolling.
Joe, meet VK. He is the resident Village Idiot in comp.lang.javascript
If it weren't for VK, I would probably have twice as much free time on
my hands.
VK
> Joe, meet VK. He is the resident Village Idiot in comp.lang.javascript
> If it weren't for VK, I would probably have twice as much free time on
> my hands.
Randy, stop showing up around and come back home to clj. Moreover you
are making people all scared around - a troll is one thing, an a la
clj "free speaking" with IQ and idiotism observations is another one.
VK
> Please re-read the thread. You've obviously missed it - or you're trolling.
Neither. Somehow the testcase got shorter then should - a typo in my
Perl proc. After my revelations on "proper testcase preparation" it is
utterly funny on public. As a gentleman I should kill myself, but
after some long internal fight I decided to try to overcome it. :-)
Your observation was correct - with 32768 or more statements IE7 with
native jscript.dll (5.7.x) produce "Syntax error" code 0
So on the real project I happened to stop right before the deadly
line: in summary on config it happened to be ~ 31,000 statements.
Lucky.
The problem has a funny numerical correlation with the original
JavaScript 1.0 limit I quoted earlier. But in the updated probe.js I
replaced the first statement with "NOP"; instead of x=3; and it still
errors out. Thus the deadly count goes by statements and not by atoms:
so it is some Microsoft very own recent oops. Must be a side effect of
some overflow vulnerability fix.
> To all: I apologize for wasting your time reading this. I have little
> experience dealing with trolls.
First try do not panic and do not try to run. If you have a window
open hearby - jump into it (first floor in mind of course). Otherwise
try to stay in the door frame - that is the most secure area in the
room. As soon as the trolling paused leave the house.
Randy Webb
<snip>
> So on the real project I happened to stop right before the deadly
> line: in summary on config it happened to be ~ 31,000 statements.
It is not "~31,000" statements, it is exactly 32,768 statements.
Randy Webb
> On Feb 26, 9:30 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> Joe, meet VK. He is the resident Village Idiot in comp.lang.javascript
>> If it weren't for VK, I would probably have twice as much free time on
>> my hands.
>
> Randy, stop showing up around and come back home to clj.
You couldn't be so lucky.
> Moreover you are making people all scared around
If the truth does that, then so be it.