[PATCH] D45050: [clang-tidy] New checker for not null-terminated result caused by strlen(), size() or equal length

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

In https://reviews.llvm.org/D45050#1281178, @whisperity wrote:

> I have installed said Ubuntu in a virtual machine for testing this, but unfortunately only the following Clangs are available in the package manager for `Trusty`:
>
>   clang - C, C++ and Objective-C compiler (LLVM based)
>   clang-3.3 - C, C++ and Objective-C compiler (LLVM based)
>   clang-3.4 - C, C++ and Objective-C compiler (LLVM based)
>   clang-3.5 - C, C++ and Objective-C compiler (LLVM based)
>   clang-3.6 - C, C++ and Objective-C compiler (LLVM based)
>   clang-3.8 - C, C++ and Objective-C compiler (LLVM based)
>   clang-3.9 - C, C++ and Objective-C compiler (LLVM based)
>
>
> (Where `clang` is just a synonym for `clang-3.4`.) **There is no Clang 3.7 in the package upstream, it seems.**


Hi, I did not initially setup the machine that hit the failure, so I cannot say for certain where it got clang. I did notice though that the llvm.org releases page does seem to include a download link for clang 3.7.1 for ubuntu 14.04 (http://releases.llvm.org/3.7.1/clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz).

>  ------
> 
> However, **`16.04 LTS (Xenial)`** at the time of writing this comment has an `clang-3.7` package, specifically this version:
> 
>   Ubuntu clang version 3.7.1-2ubuntu2 (tags/RELEASE_371/final) (based on LLVM 3.7.1)
>   Target: x86_64-pc-linux-gnu
>   Thread model: posix
> 
> 
> With this I can confirm I get a huge trace and the template depth overflow failure.
> 
> However, from the filename-line mappings of the preprocessed output, I can see that the `type_traits` header comes from `/usr/include/c++/4.8/type_traits`, which is a version **4.8** standard library, but installing the `clang-3.7` package (through some transitivity in `libasan` and such) depended on `gcc-`**`5`**`-base`, upgrading it from the system-default `5.3.1` to `5.4.0`.
> 
> Isn't this a discrepancy, relying on an older standard library than what is seemingly available on the system?

Again, I'm not sure how the toolchain was installed on the system, and if it was installed by simply unzipping the tarball above (or similar) then I could see how dependencies could go unmet. Offhand I do not even know if gcc 5+ is installed on the machine, but I can check if you think it is important.


https://reviews.llvm.org/D45050