https://clang.llvm.org/extra/clang-tidy/checks/bugprone-suspicious-string-compare.html
Find suspicious usage of runtime string comparison functions.
This check is valid in C and C++.
Checks for calls with implicit comparator and proposed to
explicitly add it:
if (strcmp(...)) // Implicitly compare to zero
if (!strcmp(...)) // Won't warn
if (strcmp(...) != 0) // Won't warn
Checks that compare function results (i,e, strcmp) are compared to valid
constant. The resulting value is
< 0 when lower than,
> 0 when greater than,
== 0 when equals.
A common mistake is to compare the result to 1 or -1:
if (strcmp(...) == -1) // Incorrect usage of the returned value.
Additionally, the check warns if the results value is implicitly cast
to a suspicious non-integer type. It’s happening when the returned
value is used in a wrong context:
if (strcmp(...) < 0.) // Incorrect usage of the returned value.
Change-Id: I001b88d06cc4f3eb5846103885be675f9b78e126
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/310761
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:9280
Change-Id: Id8253baa6ca387b6f2f0583f29b2c25cc1005545
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/230880
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Current strategy: everything from the top
Things to look at first are the manual changes:
- added tools/rewrite_includes.py
- removed -Idirectives from BUILD.gn
- various compile.sh simplifications
- tweak tools/embed_resources.py
- update gn/find_headers.py to write paths from the top
- update gn/gn_to_bp.py SkUserConfig.h layout
so that #include "include/config/SkUserConfig.h" always
gets the header we want.
No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
sk_tool_utils doesn't really fit the naming convention
the rest of code under tools/ tends to use.
Change-Id: I45326a174101c6eb4b6149e9c742f658f2fd23b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202313
Auto-Submit: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
SkRefCntBase is an implementation detail of SkRefCnt, so let's not
mention it in SkContext_Compute.h. While I'm here, I notice SkNVRefCnt
would work fine too.
No one else calls internal_dispose_restore_refcnt_to_1(), so we can
inline it. While here, I notice it's resetting the ref count to 1 even
in release builds. I'm not sure if that is/can be optimized away, but
in any case I think we can wrap with #ifdef SK_DEBUG, if only to make it
clear that it's only there to support the assert in the destructor.
I've removed validate(). Most of the places it's called read pretty
weird, and I think suggest some sort of class-specific validation than
just checking that we're holding a ref. SkWeakRefCnt::validate() isn't
called anywhere.
There were few users of getRefCnt() outside SkRefCnt itself, so I
removed the rest and made it private.
I've added a few this-> to self calls while at it.
Change-Id: I98be06677a6e8b8e66f44cbb17d14e38b0f39d38
Reviewed-on: https://skia-review.googlesource.com/c/167160
Auto-Submit: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Before this CL, the new test would write out 2 copies of each typeface,
since each one is referenced twice in the picture.
Bug: skia:
Change-Id: I6ebfe6b5ea0bb0cca2869ef0cccad21a51e48411
Reviewed-on: https://skia-review.googlesource.com/151667
Auto-Submit: Mike Reed <reed@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
New behavior is to *always* call the client's deserial image proc for all data.
This allows the client to make decisions even on "std" image data like PNG.
The change also means that if there is no client deserial image proc, Skia will
still attempt to create an image from the data, even if it was written by a
custom serial proc.
Bug: skia:7706
Change-Id: Ia58bdd10b86d497f02187082c6373c029e9c8293
Reviewed-on: https://skia-review.googlesource.com/113302
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Reed <reed@google.com>
This reverts commit c822672854.
Reason for revert: broke old skps
Original change's description:
> impl SkSerial picture procs
>
> The picture serialization code is a bit of a mess, with duplicated functions for streams and buffers.
> Could not see how to fix that and land this at the same time, but I will try to circle back and
> simplify if possible afterwards.
>
> Bug: skia:
> Change-Id: I9053fdc476c60f483df013d021e248258181c199
> Reviewed-on: https://skia-review.googlesource.com/83943
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Commit-Queue: Mike Reed <reed@google.com>
TBR=mtklein@google.com,fmalita@chromium.org,reed@google.com
Change-Id: I68ae019a286691b65cc373cb29c941d6620fd34a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/84460
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
The picture serialization code is a bit of a mess, with duplicated functions for streams and buffers.
Could not see how to fix that and land this at the same time, but I will try to circle back and
simplify if possible afterwards.
Bug: skia:
Change-Id: I9053fdc476c60f483df013d021e248258181c199
Reviewed-on: https://skia-review.googlesource.com/83943
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
Should make it easier to ask just for images.
Change-Id: If821743dc924c4bfbc6b2b2d29b14affde7b3afd
Reviewed-on: https://skia-review.googlesource.com/82684
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
