| Summary: | fopen and some other functions not found if iosfwd included first | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Nicolás Alvarez <nalvarez> |
| Component: | Language Support: CPP (old) | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | beschindler, craftplace.ms, l.jirkovsky, olivier.jg |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
I have a much smaller testcase (smaller if comparing after preprocessing):
#include <features.h>
#define __need_FILE
#include <stdio.h>
#include <stdio.h>
int main() {
FILE* fp;
fp = fopen("foo", "rb");
}
This is quite nasty. Some system header (which is being included indirectly by <iosfwd>) defines __need_FILE and includes <stdio.h>. With that macro set, stdio.h will behave different from what it normally does, and then #undef __need_FILE. The second time it's included (with that macro not defined anymore), it will do its usual work.
I think KDevelop assumes the second include is identical and doesn't re-process it with __need_FILE unset. If I remove one of the stdio.h #includes, GCC says fopen isn't declared, which matches KDevelop behavior. And if I replace either or both of the includes by the full contents of stdio.h, KDevelop finds the fopen declaration.
My next step is reducing stdio.h itself to create a minimal testcase that doesn't require any system headers.
Here you go; it couldn't be shorter:
//evil.h:
#ifndef FIRSTRUN
void foo();
#endif
#undef FIRSTRUN
//main.c:
#define FIRSTRUN
#include "evil.h"
#include "evil.h"
int main() {
foo();
}
Works in GCC, but KDevelop says foo() is not declared.
Bug still present as initially stated, but your last testcase doesn't expose it here. for me all but the middle case are fixed, and considering that the first is probably the "correct" one to use as a developer, I'm marking this as fixed. Nicolas, reopen if you disagree. My original snippet still fails on both 4.1 (7b13bcf) and 4.2 (1fe82ff). right, I wonder what I did to make it work earlier today o_O Isn't it the same bug as in #233889? Here on my machine, kdevelop doesn't manage to find iosfwd (it red-underlines it). But this might be a totally different issue However, opgengl seems to ahve a similar problem. Many opengl functions are not recognized. For example glFramebufferTexture2DEXT is not found even though gcc accepts it Scratch the iosfwd not found - I switched compiler without restarting kdevelop *oops*, but I think the glFramebufferTexture2DEXT case could be very much the same issue I tried to reproduce the bug in KDevelop 5 - it no longer valid. Probably it is necessary to close. Hello! We are working on a new clang-based C/C++ language plugin for KDevelop 5 which supersedes the old C++ plugin in KDevelop 4. See e.g.: https://www.kdevelop.org/news/first-beta-release-kdevelop-500-available Due to a lack of manpower, we cannot fix bugs in the old C++ plugin. We rather want to supply a good Clang based C++ experience for KDevelop 5 than wasting our time on the legacy C++ support for KDevelop 4. With the new clang-based C/C++ language plugin, the bug presented here does not occur. In my testing. For these reasons, I'll close this bug. Please stay tuned for KDevelop 5. If you think this bug is applicable to Clang/KDevelop 5, please reopen the report and add new information on how to reproduce the bug there. Sorry for the inconvenience, I hope you understand the reasoning above. Cheers |
Version: 4.0.60 (using KDevPlatform 1.0.60) (using 4.3.4 (KDE 4.3.4), Debian packages) OS: Linux (x86_64) release 2.6.32-3-amd64 Loading the following C++ file in KDevelop shows fopen as an unrecognized function, and the Problems toolview says "Declaration not found: fopen" (from semantic analysis). #include <iosfwd> #include <cstdio> int main() { FILE* fp; fp = fopen("foo", "rb"); } Using stdio.h instead of cstdio makes no difference. The key is iosfwd. Commenting out the iosfwd include makes no difference initially, but if you force a re-parse from the Problems toolview, fopen is found properly. Adding iosfwd back gives the same behavior: fopen continues to be found initially, but forcing a re-parse brings the yellow underline back.