Clang static analyzer - `Past-the-end iterator dereferenced` in ranged based for loop

[tgurriet]

Hello,

I'm using the latest clang-18, and the static-analyzer/clang-tidy through CodeChecker.

I have a little issue with it flagging all my ranged based for loop with Past-the-end iterator dereferenced.

For example, in the following function

  void log(const log_tags_t & tags, const LogLevel lvl, const std::string & str)
  {
    for (const auto & logger : m_loggers) { logger(tags, lvl, str); }
  }

The for (const auto & logger : m_loggers) is being flagged. I can't think of any context in which a range based for loop would do such a thing.

Any idea?

Thanks in advance

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: Thomas Gurriet (tgurriet)

Hello,

I'm using the latest clang-18, and the static-analyzer/clang-tidy through CodeChecker.

I have a little issue with it flagging all my ranged based for loop with Past-the-end iterator dereferenced.

For example, in the following function

  void log(const log_tags_t & tags, const LogLevel lvl, const std::string & str)
  {
    for (const auto & logger : m_loggers) { logger(tags, lvl, str); }
  }

The for (const auto & logger : m_loggers) is being flagged. I can't think of any context in which a range based for loop would do such a thing.

Any idea?

Thanks in advance

[steakhal]

Do you have a self-contained example that we could feed into clang to see the mentioned behavior?

[steakhal]

I couldn't reproduce this issue. https://godbolt.org/z/7bY18caWx
Let me know if your flags are different or the code looks differently.

[tgurriet]

@steakhal It's part of a large project. I'll try to extract a subset that highlights the behavior.

Isn't it strange though? I don't understand much about how the analyser is implemented, but it feels like such warning shouldn't be triggerable, no matter what's triggering it !?

[steakhal]

@steakhal It's part of a large project. I'll try to extract a subset that highlights the behavior.

Let me know if you need some help. If the project is open-source, you could just upload a preprocessed version of it, and we wil ltake it from there. Use the -E commandline flag for it.

If it's a closed-source, and you want it to be fixed, you have two options:

• Try to manually get it reproduce on some simplified code derived from your project, which you can share, or
• Have your closed project, preprocess it and feed it to creduce with some interestingness script that will preserve the warning you want to report. After a few hours, creduce should reduce the file to a minimal shape that still excercises the behavior, but probably doesn't have any sensitive information inside. You can check and redact the remaining and submit what's left. If you choose this, I'll help you along the way.

Isn't it strange though? I don't understand much about how the analyser is implemented, but it feels like such warning shouldn't be triggerable, no matter what's triggering it !?

This is just a bug, like many others. I don't see how it would be any special.

[steakhal]

I guess, this remains unactionable.

[tgurriet]

Yes, sorry, I've been pretty busy. I'll get back to this issue asap.

[steakhal]

Yes, sorry, I've been pretty busy. I'll get back to this issue asap.

I see. No worries. Take your time. I couldn't look into this now anyways :D

[mboyko2000]

This will reproduce the issue. Notice the warning is only produced on C++20 and 23 dialects. C++17 does not produce the warning.
https://godbolt.org/z/vnc9zTfrd

[tgurriet]

This will reproduce the issue. Notice the warning is only produced on C++20 and 23 dialects. C++17 does not produce the warning. https://godbolt.org/z/vnc9zTfrd

Thanks for pushing this forward!