Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

some more fixes #3136

Merged
merged 19 commits into from
Feb 4, 2025
Merged

some more fixes #3136

merged 19 commits into from
Feb 4, 2025

Conversation

neheb
Copy link
Collaborator

@neheb neheb commented Jan 29, 2025

I'm not sure about the shared_ptr change. Cyclic references are avoided by passing by value. I doubt there's much overhead here.

src/preview.cpp Fixed Show resolved Hide resolved
src/preview.cpp Fixed Show fixed Hide fixed
@neheb
Copy link
Collaborator Author

neheb commented Jan 29, 2025

more false positives. unique_ptr is not a vector.

ping @kevinbackhouse

@neheb
Copy link
Collaborator Author

neheb commented Jan 30, 2025

some more make_uniques. Let's see if it complains now.

@neheb neheb force-pushed the 4 branch 4 times, most recently from 2f35ca3 to 25423f4 Compare January 30, 2025 01:56
@kevinbackhouse
Copy link
Collaborator

@neheb: The "Unsafe Vector Access" CodeQL query is something that I wrote myself and it's definitely not perfect. The fuzzer found quite a few crashes that could have been prevented by using vector::at() because it does a bounds check and throws an exception. So my goal was just to find all the calls to vector::operator[] and replace them with vector::at().

Are some of these changes just attempts to silence the CodeQL alerts? For example, is replacing std::vector<char> with std::make_unique<char[]> a good change, or is it just silencing a warning? If it's just to silence a warning, then I would say it's unnecessary. I'm also not sure about replacing SharedPtr with UniquePtr. Isn't it better to use UniquePtr whenever possible? It makes the ownership easier to understand.

@neheb
Copy link
Collaborator Author

neheb commented Jan 30, 2025

The last commit changes to unique_ptr as only a raw pointer is used. No vector functionality like push_back. Probably uses less memory.

As for the first, it looks like get() is just used to avoid having a second smart pointer. I don’t know if that’s a good idea.

@kevinbackhouse
Copy link
Collaborator

@neheb: I think #3137 will help. It removes the field so there's no need for a shared pointer.

@neheb
Copy link
Collaborator Author

neheb commented Jan 30, 2025

I'll rebase once that's merged.

@neheb neheb force-pushed the 4 branch 6 times, most recently from 4016077 to e07c40f Compare January 31, 2025 18:31
@kevinbackhouse
Copy link
Collaborator

The decodeHexTable change looks unnecessary to me. Other than that, everything else is good.

@neheb neheb force-pushed the 4 branch 8 times, most recently from fbd7334 to 3a3d02a Compare February 3, 2025 02:05
neheb added 14 commits February 2, 2025 19:27
Signed-off-by: Rosen Penev <[email protected]>
Signed-off-by: Rosen Penev <[email protected]>
No need to initialize the base class for copy constructors.

Signed-off-by: Rosen Penev <[email protected]>
Signed-off-by: Rosen Penev <[email protected]>
unique_ptr does not have at()

Signed-off-by: Rosen Penev <[email protected]>
Signed-off-by: Rosen Penev <[email protected]>
Some platforms such as Fedora use zlib-ng instead of zlib, which has
different compressed output. Compressed output shouldn't be tested
anyway.

Signed-off-by: Rosen Penev <[email protected]>
Signed-off-by: Rosen Penev <[email protected]>
No need for it.

Signed-off-by: Rosen Penev <[email protected]>
E2513: Invalid unescaped character esc, use "\x1B" instead. (invalid-character-esc)

Signed-off-by: Rosen Penev <[email protected]>
It's only used in a single function. No need to have it in the class.

Signed-off-by: Rosen Penev <[email protected]>
Signed-off-by: Rosen Penev <[email protected]>
When calling std::vector::resize(0), Cygwin warns on it. Add a check to
avoid that.

warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

Signed-off-by: Rosen Penev <[email protected]>
@neheb
Copy link
Collaborator Author

neheb commented Feb 3, 2025

@kevinbackhouse I was right to question this get() usage. clang-analyzer complains with:

../src/crwimage_int.cpp:577:3: warning: Use of memory after it is freed [clang-analyzer-cplusplus.NewDelete]
  577 |   return cc;
      |   ^
../src/crwimage_int.cpp:992:7: note: Assuming the condition is true
  992 |   if (!buf.empty()) {
      |       ^~~~~~~~~~~~
../src/crwimage_int.cpp:992:3: note: Taking true branch
  992 |   if (!buf.empty()) {
      |   ^
../src/crwimage_int.cpp:993:5: note: Calling 'CiffHeader::add'
  993 |     pHead.add(pCrwMapping.crwTagId_, pCrwMapping.crwDir_, std::move(buf));
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/crwimage_int.cpp:516:3: note: Taking false branch
  516 |   if (!pRootDir_) {
      |   ^
../src/crwimage_int.cpp:519:20: note: Calling 'CiffComponent::add'
  519 |   if (auto child = pRootDir_->add(crwDirs, crwTagId)) {
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/crwimage_int.cpp:525:10: note: Calling 'CiffDirectory::doAdd'
  525 |   return doAdd(crwDirs, crwTagId);
      |          ^~~~~~~~~~~~~~~~~~~~~~~~
../src/crwimage_int.cpp:546:7: note: Assuming the condition is false
  546 |   if (!crwDirs.empty()) {
      |       ^~~~~~~~~~~~~~~~
../src/crwimage_int.cpp:546:3: note: Taking false branch
  546 |   if (!crwDirs.empty()) {
      |   ^
../src/crwimage_int.cpp:571:8: note: 'cc' is null
  571 |   if (!cc) {
      |        ^~
../src/crwimage_int.cpp:571:3: note: Taking true branch
  571 |   if (!cc) {
      |   ^
../src/crwimage_int.cpp:573:14: note: Calling 'make_unique<Exiv2::Internal::CiffEntry, unsigned short &, unsigned short>'
  573 |     auto m = std::make_unique<CiffEntry>(crwTagId, tag());
      |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:962:30: note: Memory is allocated
  962 |     { return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); }
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/crwimage_int.cpp:573:14: note: Returned allocated memory
  573 |     auto m = std::make_unique<CiffEntry>(crwTagId, tag());
      |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/crwimage_int.cpp:575:5: note: Calling 'CiffComponent::add'
  575 |     add(std::move(m));
      |     ^~~~~~~~~~~~~~~~~
../src/crwimage_int.cpp:144:28: note: Calling '~unique_ptr'
  144 |   doAdd(std::move(component));
      |                            ^
/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:360:2: note: Taking true branch
  360 |         if (__ptr != nullptr)
      |         ^
/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:361:4: note: Calling 'default_delete::operator()'
  361 |           get_deleter()(std::move(__ptr));
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:85:2: note: Memory is released
   85 |         delete __ptr;
      |         ^~~~~~~~~~~~
/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:361:4: note: Returning; memory was released via 2nd parameter
  361 |           get_deleter()(std::move(__ptr));
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/crwimage_int.cpp:144:28: note: Returning from '~unique_ptr'
  144 |   doAdd(std::move(component));
      |                            ^
../src/crwimage_int.cpp:575:5: note: Returning; memory was released
  575 |     add(std::move(m));
      |     ^~~~~~~~~~~~~~~~~
../src/crwimage_int.cpp:577:3: note: Use of memory after it is freed
  577 |   return cc;

add() eventually calls release() on the pointer which also ends up freeing it. so m.get() returns garbage. Supposedly.

@kevinbackhouse
Copy link
Collaborator

@kevinbackhouse I was right to question this get() usage. clang-analyzer complains with:

@neheb: which log file is this in? Or can you give me instructions to reproduce it locally?

@neheb
Copy link
Collaborator Author

neheb commented Feb 3, 2025

@kevinbackhouse I was right to question this get() usage. clang-analyzer complains with:

@neheb: which log file is this in? Or can you give me instructions to reproduce it locally?

assuming your cmake configuration includes -DCMAKE_EXPORT_COMPILE_COMMANDS=ON , run

run-clang-tidy -header-filter=../ -checks=clang-analyzer\* ../src/crwimage_int.cpp

@neheb neheb force-pushed the 4 branch 2 times, most recently from 8715d78 to 4899a94 Compare February 3, 2025 18:48
neheb added 2 commits February 3, 2025 11:21
Signed-off-by: Rosen Penev <[email protected]>
add calls doAdd which calls push_back and release(). It's more reliable
to call back() in this case as the formerly unique_ptr is at the end.

Signed-off-by: Rosen Penev <[email protected]>
Signed-off-by: Rosen Penev <[email protected]>
@kevinbackhouse
Copy link
Collaborator

@kevinbackhouse I was right to question this get() usage. clang-analyzer complains with:

@neheb: which log file is this in? Or can you give me instructions to reproduce it locally?

assuming your cmake configuration includes -DCMAKE_EXPORT_COMPILE_COMMANDS=ON , run

run-clang-tidy -header-filter=../ -checks=clang-analyzer\* ../src/crwimage_int.cpp

@neheb: you already fixed it in f81fd33, right?

@neheb
Copy link
Collaborator Author

neheb commented Feb 3, 2025

Yes

Copy link
Collaborator

@kevinbackhouse kevinbackhouse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks good now. In future though, please could you not bundle so many unrelated changes into one PR? I find smaller PRs easier to review. Also, if a change causes a regression, I find it's easier to track down what caused it if each individual PR is smaller.

@neheb neheb merged commit 73885ef into Exiv2:main Feb 4, 2025
60 checks passed
@neheb neheb deleted the 4 branch February 4, 2025 00:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants