Possible bad parsing in SVGNumberList::SetValueFromString()

RESOLVED FIXED in mozilla17

Status

()

Core
SVG
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Dolske, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
mozilla17
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pvs-studio])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
From http://www.viva64.com/en/a/0078/

Example 7. A non-dereferenced pointer

nsresult
SVGNumberList::SetValueFromString(const nsAString& aValue)
{
  ...
  const char *token = str.get();
  if (token == '\0') {
    return NS_ERROR_DOM_SYNTAX_ERR; // nothing between commas
  }
  ...
}

PVS-Studio diagnostic message: V528 It is odd that pointer to 'char' type is compared with the '\0' value. Probably meant: *token == '\0'. svgnumberlist.cpp 96

The code checking that there's nothing between the commas does not work. To find out whether or not the string is empty, we can compare the first character to '\0'. But it is the pointer which is compared to null instead of the first character. This pointer is never equal to zero. This is the correct check: (*token == '\0').
(Reporter)

Updated

6 years ago
Blocks: 710966
This was introduced in bug 589439.
Blocks: 589439
Created attachment 581917 [details] [diff] [review]
patch v1

Trivial patch.
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Attachment #581917 - Flags: review?(dholbert)
Whiteboard: [pvs-studio] → [pvs-studio][good first bug][lang=c++]
Sorry, I didn't realize this was already taken.
Whiteboard: [pvs-studio][good first bug][lang=c++] → [pvs-studio]
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
Comment on attachment 581917 [details] [diff] [review]
patch v1

Good catch!

(Side note: It looks like this isn't dangerous at all, nor does it even affect behavior, I think.  In cases where we *should* take the early-return but fail to do so, we'll just end up taking the slightly-later early return a few lines later, because (*end != '\0') will be true.)
Attachment #581917 - Flags: review?(dholbert) → review+
oh, I misread the (*end != '\0') as being == instead of !=.  So maybe this does affect behavior, not sure.  If so, we should add a test for it.
Has a patch and needs a test! I won't have the time to work on this anytime soon, though.
Assignee: ttaubert → nobody
Status: ASSIGNED → NEW

Comment 7

5 years ago
Created attachment 646953 [details] [diff] [review]
tests

Updated

5 years ago
Attachment #646953 - Flags: review?(dholbert)
Comment on attachment 646953 [details] [diff] [review]
tests

>diff --git a/content/svg/content/test/test_SVGLengthList.xhtml b/content/svg/content/test/test_SVGLengthList.xhtml
>+  // -- Invalid attribute
>+  eventChecker.expect("modify");
>+  text.setAttribute("x", ",20");
>+  is(lengths.numberOfItems, 0, 'Checking numberOfItems');

In the event that this fails, "Checking numberOfItems" is a bit of a cryptic error message. Maybe "Checking that invalid values won't successfully parse" or something?

r=me with something like that. :) Thanks!
Attachment #646953 - Flags: review?(dholbert) → review+

Comment 9

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/b6ecb2b4a5a5
https://hg.mozilla.org/integration/mozilla-inbound/rev/cad2a6ac68ca
Flags: in-testsuite+
Target Milestone: --- → mozilla17
https://hg.mozilla.org/mozilla-central/rev/b6ecb2b4a5a5
https://hg.mozilla.org/mozilla-central/rev/cad2a6ac68ca
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.