--- In jslint_com@yahoogroups.com, "silver_7402" <silver_7402@...> wrote:
>
> If a script is entered into JSLint.com[1] containing a destructuring
assignment[2], JSLint gives a strange error message[3] that has little or
nothing to do with the actual cause of the error, then dies -- i.e. doesn't
produce any more results. The message appears to indicate a problem in the
script at that position, but is I think actually an error message from JSLint
itself.
>
> I guess I'd like to see one of two things: either JSLint supporting this
assignment syntax (nice, but will take a while, probably); or JSLint at any rate
not crashing on it.
>     [p2, p1] = [p1, p2 + p1];


Thanks. JSLint now reports "Bad assignment."

There has been a problem with http://www.jslint.com/rhino/rhino.js for a while.
It adds one to the reported line number returned from jslint.

And also, it doesn´t pass jslint, because it has a deprecated external
declaration instead of global.

I spotted the last one thanks to flymake-jslint for Emacs, a great tool for
Emacs users. http://www.emacswiki.org/emacs/FlymakeJavaScript

I also have a question: why not the dot in regexps?

Thanks,
Henrik Hjelte

--- In jslint_com@yahoogroups.com, "jagarenbraperson" <jagarenbraperson@...>
wrote:
>
> There has been a problem with http://www.jslint.com/rhino/rhino.js for a
while. It adds one to the reported line number returned from jslint.
>
> And also, it doesn´t pass jslint, because it has a deprecated
> external declaration instead of global.

Thanks.

> I spotted the last one thanks to flymake-jslint for Emacs, a great
> tool for Emacs users.
> http://www.emacswiki.org/emacs/FlymakeJavaScript

Very cool. Did all you Emacs users see that?

> I also have a question: why not the dot in regexps?

In secure input validation applications, . is an invitation to sloppiness, and
sloppiness aids the enemy. The . tends to match more than you expect, and so can
create holes.

Would it be possible to get JSLint to warn if you call the escape()
function?  The bad behaviour of this function has caused me problems this
morning.  It encodes characters as %uXXXX instead of UTF-8 bytes.  Plus, it
doesn't handle plus characters.  I think that most instances of this
function should be replaced by encodeURIComponent().
What do you think?

Thanks,
-Dom


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Dominic Mitchell <dom@...> wrote:
>
> Would it be possible to get JSLint to warn if you call the escape()
> function?  The bad behaviour of this function has caused me problems this
> morning.  It encodes characters as %uXXXX instead of UTF-8 bytes.  Plus, it
> doesn't handle plus characters.  I think that most instances of this
> function should be replaced by encodeURIComponent().

Depending on the options you choose, you current get either

Error:

Implied global: escape

or

Error:

Problem at line 1 character 1: 'escape' is not defined.


Why isn't that sufficient?

--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
> Thanks. JSLint now reports "Bad assignment."
>
Ah, much better. Now I can actually check the rest of the script.... Many
thanks.

On Fri, Sep 11, 2009 at 8:37 PM, douglascrockford <douglas@...>wrote:

> --- In jslint_com@yahoogroups.com, Dominic Mitchell <dom@...> wrote:
> >
> > Would it be possible to get JSLint to warn if you call the escape()
> > function?  The bad behaviour of this function has caused me problems this
> > morning.  It encodes characters as %uXXXX instead of UTF-8 bytes.  Plus,
> it
> > doesn't handle plus characters.  I think that most instances of this
> > function should be replaced by encodeURIComponent().
>
> Depending on the options you choose, you current get either
>
> Error:
>
> Implied global: escape
>
> or
>
> Error:
>
> Problem at line 1 character 1: 'escape' is not defined.
>
>
> Why isn't that sufficient?
>

Because it's quite likely that people would simply add /*global escape */
and carry on.  Whereas a specific warning that escape() should be replaced
by encodeURIComponent() (at least, in a browser environment) would be a lot
more helpful.

-Dom


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Dominic Mitchell <dom@...> wrote:
>
> On Fri, Sep 11, 2009 at 8:37 PM, douglascrockford <douglas@...>wrote:
>
> > --- In jslint_com@yahoogroups.com, Dominic Mitchell <dom@> wrote:
> > >
> > > Would it be possible to get JSLint to warn if you call the escape()
> > > function?  The bad behaviour of this function has caused me problems this
> > > morning.  It encodes characters as %uXXXX instead of UTF-8 bytes.  Plus,
> > it
> > > doesn't handle plus characters.  I think that most instances of this
> > > function should be replaced by encodeURIComponent().
> >
> > Depending on the options you choose, you current get either
> >
> > Error:
> >
> > Implied global: escape
> >
> > or
> >
> > Error:
> >
> > Problem at line 1 character 1: 'escape' is not defined.
> >
> >
> > Why isn't that sufficient?
> >
>
> Because it's quite likely that people would simply add /*global escape */
> and carry on.  Whereas a specific warning that escape() should be replaced
> by encodeURIComponent() (at least, in a browser environment) would be a lot
> more helpful.
>
> -Dom
>
>
> [Non-text portions of this message have been removed]
>


I agree with Dom that adding a suggestion to use encodeURIcomponent would be
helpful, especially in light of its security implications.

- philip

--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "jagarenbraperson" <jagarenbraperson@>
wrote:
> >
> > There has been a problem with http://www.jslint.com/rhino/rhino.js for a
while. It adds one to the reported line number returned from jslint.
> >
> > And also, it doesn´t pass jslint, because it has a deprecated
> > external declaration instead of global.
>
> Thanks.
>
> > I spotted the last one thanks to flymake-jslint for Emacs, a great
> > tool for Emacs users.
> > http://www.emacswiki.org/emacs/FlymakeJavaScript
>
> Very cool. Did all you Emacs users see that?
>
> > I also have a question: why not the dot in regexps?
>
> In secure input validation applications, . is an invitation to sloppiness, and
sloppiness aids the enemy. The . tends to match more than you expect, and so can
create holes.
>
In additon to .* , you might want to flag things of the form [^x]* , which tend
to match more than expected -- yes, I've been burned by this before.

--- In jslint_com@yahoogroups.com, "tsepez" <tsepez@...> wrote:
>
> In additon to .* , you might want to flag things of the form [^x]* , which
tend to match more than expected -- yes, I've been burned by this before.
>

Why? [^x]* matches everything except for x. When it says "everything" it means
EVERYthing. That is the exact literal and precise interpretation of it. If you
don't want that broad of scale, use something different, like [abc]*

Would we need an option saying "tolerate regular expressions that contain
imprecise (but very useful) expressions"?

There are a bunch of regular expressions that literally NEED the form [^x]*.
Consider matching a string, for instance:

/"(?:\\"|[^"])*"/

In this case the [^"] part is very necessary. You can't use a lazy star because
of escapement. Just keep in mind that when you have a regular expression that
has the form [^x] it means, *ANYTHING* other than 'x'. If you don't want to
select *ANYTHING* other than 'x', then use a different form. That's what they're
there for.

Why would you expect [^x]* to mean something other than "anything except x"?

--- In jslint_com@yahoogroups.com, "tsepez" <tsepez@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@> wrote:
> >
> > --- In jslint_com@yahoogroups.com, "jagarenbraperson" <jagarenbraperson@>
wrote:

> > > I also have a question: why not the dot in regexps?

> > In secure input validation applications, . is an invitation to sloppiness,
and sloppiness aids the enemy. The . tends to match more than you expect, and so
can create holes.
> >
> In additon to .* , you might want to flag things of the form [^x]* , which
tend to match more than expected -- yes, I've been burned by this before.

Good point. I have been burned too.

On Fri, Sep 11, 2009 at 8:28 AM, douglascrockford <douglas@...> wrote:
> --- In jslint_com@yahoogroups.com, "jagarenbraperson" <jagarenbraperson@...>
wrote:
> > flymake-jslint for Emacs, a great tool for Emacs users.
> > http://www.emacswiki.org/emacs/FlymakeJavaScript
>
> Very cool. Did all you Emacs users see that?

Not to go too far off-topic, but I think fans of JSLint would also
appreciate FlymakeCSS, which is also fantastic, and very easy to set
up for any platform, using the W3 CSS Validator .jar file.

http://www.emacswiki.org/emacs/FlymakeCSS

There's also FlymakeHTML (using Tidy), or the FlymakeXML mode (using
XMLStar) works pretty well with HTML too.

http://www.emacswiki.org/emacs/FlyMake#toc6
http://flymake.sourceforge.net/

I'll also just point out that, whether or not you use Emacs, it's
pretty straightforward to set up JSLint to work with continuous
testing tool like ZenTest (sorry, no link for that) which would get
you a JSLint test that happens in the background whenever you save
changes to a .js file.

http://www.zenspider.com/ZSS/Products/ZenTest/





--
Noah Sussman
nerdabout.com
noah at onemorebug dot com

Software is fiction, it is imagination.  Not many rules apply.
              -- Richard Gabriel

douglascrockford wrote:
>
> tsepez wrote:
>
> > In additon to .* , you might want to flag things of the form [^x]* , which
tend to match more than expected -- yes, I've been burned by this before.
>
> Good point. I have been burned too.

I think you should have a more verbose message than "unexpected '.'". There are
real-life situations where . is probably OK, like a Greasemonkey script that
pulls the name after the # out of a URL with /.*#(.*)/.exec(url)[1].

--- In jslint_com@yahoogroups.com, "iain_dalton" <iain.dalton@...> wrote:
>
> douglascrockford wrote:
> >
> > tsepez wrote:
> >
> > > In additon to .* , you might want to flag things of the form [^x]* , which
tend to match more than expected -- yes, I've been burned by this before.
> >
> > Good point. I have been burned too.
>
> I think you should have a more verbose message than "unexpected '.'". There
are real-life situations where . is probably OK

Good. So it now warns about insecure, rather than unexpected, usage.

JSLint counts all of the occurrences of property names for its
/*members*/ report. It does that by making an object with a
property for each name that it sees. The value of each property
is its count.

Running JSLint on this script caused it to fail only on Firefox:

     Field.prototype.__iterator__ = function Field___iterator__ () {
         return new FieldIter(this);
     };

Firefox has a non-standard feature that causes for..in to fail
if an object has an __iterator__ property that is not a function.
These experimental extensions are a hazard to reliability and
portability.

So JSLint now issues a reserved property name warning when it sees
such names, and excludes them from the /*members*/ report.

I'm not an expert in JS coding, and this problems looks esoteric for me.

"The body of a for in should be wrapped in an if statement to filter unwanted
properties from the prototype."
<code>
for(var c in this.colorcount.onboard) {
    set_count_onboard(c,this.colorcount.onboard[c]);
}
</code>
the colorcount = { onboard: {'R':0, 'G':0, 'B':0, 'Y':0, 'M':0 }, blown: 
{'R':0, 'G':0, 'B':0, 'Y':0, 'M':0 } };

Another problem:
"Be careful when making functions within a loop. Consider putting the function
in a closure."
<code>
var h = m.map(function(e){return{s: e.s, d: e.d};});
</code>

Thanks in advance.

On Sun, Sep 20, 2009 at 10:02 AM, qmaxa <qwiglydee@...> wrote:
> I'm not an expert in JS coding,

Then you want "the Rhino Book" (JavaScript: The Definitive Guide)
http://oreilly.com/catalog/9780596000486/

> this problems looks esoteric for me.
>
> "The body of a for in should be wrapped in an if statement to filter unwanted
properties from the prototype."

See http://yuiblog.com/blog/2006/09/26/for-in-intrigue/

> Another problem:
> "Be careful when making functions within a loop. Consider putting the function
in a closure."

For a quick solution, see
http://www.cjboco.com/post.cfm/javascript-and-i-need-some-closure

For an explanation of the problem, see
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/54ab90e\
2d778dc14

--
Noah Sussman
nerdabout.com
noah at one more bug dot com

Software is fiction, it is imagination.  Not many rules apply.
              -- Richard Gabriel

Hello,

I have an example base64 encoding function.  As messages in this group
are sometimes displayed in a variable-width font, and that may make my
question harder to understand, I have placed a copy of this function
with its current white space / indentation here: http://jsbin.com/enolu
   <http://jsbin.com/enolu>
JSLint issues a warning: "Missing space after '+='." about this section:

// those four 6-bit numbers are used as indices into the
// base64 character list
r +=
      chars[n[0]] +
      chars[n[1]] +
      chars[n[2]] +
      chars[n[3]];

However, it does not issue a warning about this section, which is
similarly formatted:

// these three 8-bit (ASCII) characters become one 24-bit number
n =
      (s.charCodeAt(c) << 16) +
      (s.charCodeAt(c + 1) << 8) +
      s.charCodeAt(c + 2);


Both sections have a line break after the equal sign.  I don't opine on
whether this is a good idea or not. I merely wonder whether JSLint
should warn about the second section, since it warns about the first, or
perhaps it should ignore the first, as it ignores the second.

Thanks!

- Chris



[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, "Chris" <Nielsen.Chris@...> wrote:
>
> Hello,
>
> I have an example base64 encoding function.  As messages in this group
> are sometimes displayed in a variable-width font, and that may make my
> question harder to understand, I have placed a copy of this function
> with its current white space / indentation here: http://jsbin.com/enolu
>   <http://jsbin.com/enolu>
> JSLint issues a warning: "Missing space after '+='." about this section:
>
> // those four 6-bit numbers are used as indices into the
> // base64 character list
> r +=
>      chars[n[0]] +
>      chars[n[1]] +
>      chars[n[2]] +
>      chars[n[3]];
>
> However, it does not issue a warning about this section, which is
> similarly formatted:
>
> // these three 8-bit (ASCII) characters become one 24-bit number
> n =
>      (s.charCodeAt(c) << 16) +
>      (s.charCodeAt(c + 1) << 8) +
>      s.charCodeAt(c + 2);
>
>
> Both sections have a line break after the equal sign.  I don't opine on
> whether this is a good idea or not. I merely wonder whether JSLint
> should warn about the second section, since it warns about the first, or
> perhaps it should ignore the first, as it ignores the second.

When I lint this code with strict white space checking:

var c, chars, n, r, s;
r +=
      chars[n[0]] +
      chars[n[1]] +
      chars[n[2]] +
      chars[n[3]];
n =
      (s.charCodeAt(c) << 16) +
      (s.charCodeAt(c + 1) << 8) +
      s.charCodeAt(c + 2);

I see no warnings.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> When I lint this code with strict white space checking:
>
> var c, chars, n, r, s;
> r +=
>      chars[n[0]] +
>      chars[n[1]] +
>      chars[n[2]] +
>      chars[n[3]];
> n =
>      (s.charCodeAt(c) << 16) +
>      (s.charCodeAt(c + 1) << 8) +
>      s.charCodeAt(c + 2);
>
> I see no warnings.
>

The warning message can be generated when ONLY "Strict white space" is checked.
Unchecking "Strict white space" will prevent the warning message.  Other options
do not appear to have an effect.

The warning message is not generated if spaces are used as indentation.

The warning message is not generated if `chars[n[0]] +` is indented to the same
level as `r +=`

The warning message is not generated if `chars[n[0]] +` is indented two tabs
beyond the level of `r +=`

The warning message is generated in your example code if the following sequence
is present:

var c, chars, n, r, s;[line break]
[line break]
r +=[line break]
[tab]chars[n[0]] +[line break]
[tab]chars[n[1]] +[line break]
[tab]chars[n[2]] +[line break]
[tab]chars[n[3]];[line break]
[line break]
n =[line break]
[tab](s.charCodeAt(c) << 16) +[line break]
[tab](s.charCodeAt(c + 1) << 8) +[line break]
[tab]s.charCodeAt(c + 2);[line break]

--- In jslint_com@yahoogroups.com, "Chris" <Nielsen.Chris@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > When I lint this code with strict white space checking:
> >
> > var c, chars, n, r, s;
> > r +=
> >      chars[n[0]] +
> >      chars[n[1]] +
> >      chars[n[2]] +
> >      chars[n[3]];
> > n =
> >      (s.charCodeAt(c) << 16) +
> >      (s.charCodeAt(c + 1) << 8) +
> >      s.charCodeAt(c + 2);
> >
> > I see no warnings.
> >
>
> The warning message can be generated when ONLY "Strict white space" is
checked. Unchecking "Strict white space" will prevent the warning message. 
Other options do not appear to have an effect.
>
> The warning message is not generated if spaces are used as indentation.
>
> The warning message is not generated if `chars[n[0]] +` is indented to the
same level as `r +=`
>
> The warning message is not generated if `chars[n[0]] +` is indented two tabs
beyond the level of `r +=`
>
> The warning message is generated in your example code if the following
sequence is present:
>
> var c, chars, n, r, s;[line break]
> [line break]
> r +=[line break]
> [tab]chars[n[0]] +[line break]
> [tab]chars[n[1]] +[line break]
> [tab]chars[n[2]] +[line break]
> [tab]chars[n[3]];[line break]
> [line break]
> n =[line break]
> [tab](s.charCodeAt(c) << 16) +[line break]
> [tab](s.charCodeAt(c + 1) << 8) +[line break]
> [tab]s.charCodeAt(c + 2);[line break]

Got it, thanks. Having a conversation about whitespace is really difficult when
the conversation is conducted in HTML.

Hallo, I have a really really little bug to report.
Using Rhino I have to explicitly write that I want to use the . in regular
expressions (instead of leaving the option away):

/*jslint regexp: false */
/.*/.test("it's a dot");

Otherwise I get this:

Lint at line 1 character 2: Insecure '.'.
/.*/.test("it's a dot");


That does not happen using the input mask on the website; and I think that's the
way it should be, because the option is called "Disallow insecure . and [^...]
in /RegExp/"

Christian

--- In jslint_com@yahoogroups.com, "Christian" <christian.wirkus@...> wrote:
>
> Hallo, I have a really really little bug to report.
> Using Rhino I have to explicitly write that I want to use the .
> in regular expressions (instead of leaving the option away):
>
> /*jslint regexp: false */
> /.*/.test("it's a dot");
>
> Otherwise I get this:
>
> Lint at line 1 character 2: Insecure '.'.
> /.*/.test("it's a dot");

rhino.js contains

     if (!JSLINT(input, {bitwise: true, eqeqeq: true, immed: true,
             newcap: true, nomen: true, onevar: true, plusplus: true,
             regexp: true, rhino: true, undef: true, white: true})) {

which sets the options. You are free to set it any way you like,
or to override it with the /*jslint*/ comment.

Thank you for explanations and references.

Already got caught in both of these problems.
Now it is much cleaner :)

The book is found and awaits reading.

Hi there,

Can you please explain why this is a "strict violation"?

"use strict";
(function (window) {
// ...
}(this));

I've seen this as a common technique used by various libraries (incl. jQuery) to
allow munging of the window name inside the closure.

Is it some bad use of the global object? Thanks!

Aseem

--- In jslint_com@yahoogroups.com, "Aseem" <aseem.kishore@...> wrote:

> Can you please explain why this is a "strict violation"?
>
> "use strict";
> (function (window) {
> // ...
> }(this));
>
> I've seen this as a common technique used by various libraries (incl.
> jQuery) to allow munging of the window name inside the closure.

Strict mode does not allow use of top-level this. you may want to turn off the
strict option.

Just found a nasty bug, in Adobe Spry Tabbed Panels:

http://labs.adobe.com/technologies/spry/widgets/tabbedpanels/SpryTabbedPanels.js

The bug is here:
     if (!tpIndex < 0 || tpIndex >= this.getTabbedPanelCount())
         return;

The error is:
!tpIndex < 0
instead of:
tpIndex < 0

Could JsLint be able to send a warning in this case ?

JC


[Non-text portions of this message have been removed]

OK, we use a product which embeds Rhino, version 1_5R5.

I was looking at running jslint over the scripts written for this tool, however
when I used the jslint.js downloaded from the site I keep getting an error in
jslint itself when a problem in a script exists -

js: "C:\workspace\rhino\jslint.js", line 462: The undefined value has no
properties.

Questions:
1. Do previous versions of jslint.js exist which may be compatible with that
version of Rhino ? If so where can I get them from?

2. If I utilise a more recent  version of Rhino which makes JSLint work, how
confident can I be that I'm testing like for like, i.e. sure the script is fine
in a newer Rhino but a problem may occur on 1_5R5?

thanks

Tim

--- In jslint_com@yahoogroups.com, Jean-Charles Meyrignac <jcmeyrignac@...>
wrote:
>
> Just found a nasty bug, in Adobe Spry Tabbed Panels:
>
>
http://labs.adobe.com/technologies/spry/widgets/tabbedpanels/SpryTabbedPanels.js
>
> The bug is here:
>     if (!tpIndex < 0 || tpIndex >= this.getTabbedPanelCount())
>         return;
>
> The error is:
> !tpIndex < 0
> instead of:
> tpIndex < 0
>
> Could JsLint be able to send a warning in this case ?


JSLint could complain when an operand of a relational operator is a !
expression. And it could complain when a relational expression is an
operand of a ! expression.
comparison operator.

If I were to do this,

     !(x === y)     // bad
     !x === y       // bad

I don't know that that should increase your confidence about Spry.
A naive fix of the warning will make things worse, producing
something, like

     if (tpIndex >= 0 || tpIndex >= this.getTabbedPanelCount())

Comments?

I think it would be sufficient to warn only about using ! in an operand
of <, >, <=, and >=, where (generally speaking) it is clearly unintended.

So:
    !x < y // bad

Warning about the same for ==, ===, !=, and !==, and warning about !(x
== y) would be OK if you want, but hypothetically those construct might
be used for good.

-jamie

Douglas Crockford wrote:
>
>
> --- In jslint_com@yahoogroups.com <mailto:jslint_com%40yahoogroups.com>,
> Jean-Charles Meyrignac <jcmeyrignac@...> wrote:
>  >
>  > Just found a nasty bug, in Adobe Spry Tabbed Panels:
>  >
>  >
>
http://labs.adobe.com/technologies/spry/widgets/tabbedpanels/SpryTabbedPanels.js
>
<http://labs.adobe.com/technologies/spry/widgets/tabbedpanels/SpryTabbedPanels.j\
s>
>  >
>  > The bug is here:
>  > if (!tpIndex < 0 || tpIndex >= this.getTabbedPanelCount())
>  > return;
>  >
>  > The error is:
>  > !tpIndex < 0
>  > instead of:
>  > tpIndex < 0
>  >
>  > Could JsLint be able to send a warning in this case ?
>
> JSLint could complain when an operand of a relational operator is a !
> expression. And it could complain when a relational expression is an
> operand of a ! expression.
> comparison operator.
>
> If I were to do this,
>
> !(x === y) // bad
> !x === y // bad
>
> I don't know that that should increase your confidence about Spry.
> A naive fix of the warning will make things worse, producing
> something, like
>
> if (tpIndex >= 0 || tpIndex >= this.getTabbedPanelCount())
>
> Comments?
>
>
>
> ------------------------------------------------------------------------
> *This message has been 'sanitized'. This means that potentially
> dangerous content has been rewritten or removed. The following log
> describes which actions were taken. *
>
>
> Sanitizer (start="1254155399"):
>   Split unusually long word(s) in header.
>   Part (pos="3362"):
>     SanitizeFile (filename="unnamed.txt", mimetype="text/plain"):
>       Match (names="unnamed.txt", rule="2"):
>         Enforced policy: accept
>
>     Total modifications so far: 1
>
>   Part (pos="4495"):
>     SanitizeFile (filename="unnamed.html, filetype.html",
mimetype="text/html"):
>       Match (names="unnamed.html, filetype.html", rule="4"):
>         ScanFile (file="/home/antivirus/quarantine/att-unnamed.html.1FX"):
>           Scan succeeded, file is clean.
>
>         Enforced policy: accept
>
>
>
> Anomy 0.0.0 : Sanitizer.pm $Id: Sanitizer.pm,v 1.94 2006/01/02 16:43:10
> bre Exp $
>