Our website uses cookies to enhance your browsing experience.
Accept
to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
* By clicking this button you agree to our Privacy Policy statement

close form
Free PVS‑Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

close form
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

close form
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

close form
check circle
Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
It's difficult to make it right (of one…

It's difficult to make it right (of one subtle error)

Mar 22 2011

Our PVS-Studio analyzer has existed for several years. But we are still coming across "initial" errors in it, i.e. errors that have existed there for the whole life-cycle. We have checked the source code of the Chromium project recently (the archive with source code only occupies a bit less than 1Gbyte). This is a solution with about 450 projects. One of the projects would not get checked and generated strange errors at the preprocessing stage. We are using Visual C++ as the preprocessor, so we cannot analyze code without preprocessing.

Well, we found out that cl.exe incorrectly processes a line enclosed into double quote marks with a space. For instance:

/D "" WEBCORE_NAVIGATOR_VENDOR=\"Google Inc.\" ""

When cl.exe came across this command line argument, it processed it incorrectly as well as all the further arguments. And most likely, it is not the fault of cl.exe but such is just the approach to processing command line arguments in general. But it is not that important. What is of interest to us is that in order to recall this error, we must have a project that:

  • has user define;
  • and not just define but with a specified value;
  • and not just a value but a string value;
  • and not just a string value but with a space inside it;
  • and of course it must be enclosed in quote marks.

Sure, this thing actually could (and must) have been provided for at the stage of developing, but it had not been done. And the error was detected only now.

Detecting such an error in a project with a long life-cycle means that it is very difficult to provide for every possible kind of external input data. This is a very hard yet interesting task.

Popular related articles


Comments (0)

Next comments next comments
close comment form