# Just a Few Bugs in 514K Lines of Code \- Amazon Web Services SDK for C\+\+

Amazon Web Services open\-sourced C\+\+ SDK, a modern C\+\+ interface with lightweight dependencies\. This prompted our team to apply PVS\-Studio static analysis tool to the source code in order to try to reveal some interesting code fragments\.

![0378_AmazonSDK/image1.png](https://import.viva64.com/docx/blog/0378_AmazonSDK/image1.png)

The developers of AWS SDK for C\+\+ state that it is meant to be fully functioning, with both low\-level and high\-level interfaces; at the same time having minimum dependencies and providing platform portability \(Windows, OSX, Linux, and mobile\)\.The source code is available at GitHub [repository](https://github.com/aws/aws-sdk-cpp)\. 

[PVS\-Studio](https://pvs-studio.com/en/pvs-studio/) is a static analyzer for bug detection in the source code of programs, written in C, C\+\+ and C\#\. 

The size of the project to be analyzed is 5415 files, more than 514 thousand lines of code\. Usually projects of that size contain a significant number of high and low\-severity bugs, making a nice addition to our [error collection](https://pvs-studio.com/en/blog/examples/)\. 

This time, there is nothing much to say, but to give a big round of applause to the **AW**e**S**ome developers for the quality of this project\. They really did a great job: the analyzer managed to detect only a couple of low\-severity bugs\. Here they are, with the analyzer warnings: 

[V547](https://pvs-studio.com/en/docs/warnings/v547/) Expression 'pathname\_\.c\_str\(\) \=\= 0' is always false\. Pointer 'pathname\_\.c\_str\(\)' \!\= NULL\. gtest\-all\.cc 8189

```cpp
std::string pathname_;
void FilePath::Normalize() {
  if (pathname_.c_str() == NULL) {  // <=
    pathname_ = "";
    return;
  }
  const char* src = pathname_.c_str();
  char* const dest = new char[pathname_.length() + 1];
  ....
}
```

The string::c\_str\(\) function returns the pointer to the c\-string that cannot be equal to NULL\. Even if an empty string will be created \- like "string buf;", for instance; then the "buf\.c\_str\(\)" will return a valid pointer to the empty string\. 

Thus, the condition "pathname\_\.c\_str\(\) \=\= NULL" will always be false and the function will never exit in this fragment\. Most likely this function has to be exited if the "pathname\_" string is empty\. Then the check should be as follows:

```cpp
std::string pathname_;
void FilePath::Normalize() {
  if (pathname_.empty()) {
    return;
  }
  ....
}
```

Two more similar fragments:

* V547 Expression 'output\_file\_\.c\_str\(\) \=\= 0' is always false\. Pointer 'output\_file\_\.c\_str\(\)' \!\= NULL\. gtest\-all\.cc 4575
* V547 Expression 'os\_stack\_trace\.c\_str\(\) \!\= 0' is always true\. Pointer 'os\_stack\_trace\.c\_str\(\)' \!\= NULL\. gtest\-all\.cc 5286

That's it\! Just a couple of suspicious fragments in a project with more than 514 k lines of code\. There were several examples of fragments that seemed a little strange, but they aren't even worth mentioning here\. That is truly impressive\. We have to admit \- having checked more than [200 projects](https://pvs-studio.com/en/blog/inspections/) we are more than surprised to see such a tiny number of bugs\. Way to go, Amazon\!