Closed Bug 410396 Opened 17 years ago Closed 6 years ago

narcissus - reduce strict warnings

Categories

(Other Applications Graveyard :: Narcissus, enhancement)

x86
All
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bc, Unassigned)

References

Details

Attachments

(2 files)

Attached patch patch (deleted) — Splinter Review
Several JavaScript warnings in Narcissus cause pain when run in debug builds. This eliminates them at the cost of some performance.
Flags: in-testsuite-
Flags: in-litmus-
Attachment #295011 - Flags: review?(mrbkap)
Comment on attachment 295011 [details] [diff] [review] patch I'm against adding runtime costs to work around strict warnings -- often there's a cheaper or compile-time way. More below, but thanks for filing this, you may have found a bug or two. > get token() { >- return this.tokens[this.tokenIndex]; >+ return this.tokenIndex < this.tokens.length ? this.tokens[this.tokenIndex] : undefined; If we get a strict warning here, we are indexing out of bounds, evaluating to undefined -- no memory safety problems of course -- but still I'd like to know the minimal testcase and debug a bit. Seems like we could initialize this.tokens to avoid the strict warning. >- } while (ss[i].label != label); >+ } while ('label' in ss[i] && ss[i].label != label); >- if (ss[i].label == label) >+ if ('label' in ss[i] && ss[i].label == label) >- while (opPrecedence[operators.top().type] > opPrecedence[tt] || >+ while (operators.top() && operators.top().type in opPrecedence && opPrecedence[operators.top().type] > opPrecedence[tt] || >- while (opPrecedence[operators.top().type] >= opPrecedence[tt]) >+ while (operators.top() && operators.top().type in opPrecedence && opPrecedence[operators.top().type] >= >- while (opPrecedence[operators.top().type] > opPrecedence[tt]) >+ while (operators.top() && operators.top().type in opPrecedence && opPrecedence[operators.top().type] > opPrecedence[tt]) >- while (opPrecedence[operators.top().type] > opPrecedence[NEW]) >+ while (operators.top() && operators.top().type in opPrecedence && opPrecedence[operators.top().type] > opPrecedence[NEW]) In all of these cases, I bet there's a prototype object (or one we could introduce) with an explicit undefined default value. /be
Attachment #295011 - Attachment is patch: true
Attachment #295011 - Flags: review?(mrbkap) → review-
Attached file google.js (unreduced testcase) (deleted) —
With the previous patch applied plus the following modification to get token return this.tokenIndex < this.tokens.length ? this.tokens[this.tokenIndex] : (print('TOKEN ERROR'),undefined); js> load('js.js') js> load('/home/bclary/tmp/google.js') TOKEN ERROR
Assignee: bclary → general
Status: ASSIGNED → NEW
Seems to be the first token in the script at least. s="1"; f=""; l=1; parse(s,f,l);
Blocks: 296661
Assignee: general → nobody
Component: JavaScript Engine → Narcissus
Flags: in-testsuite-
Flags: in-litmus-
Product: Core → Other Applications
Closing as Narcissus isn't maintained anymore.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: