Annoying false-positives in C code
al20878 opened this issue · comments
Environment
Version: 1.90.2 (system setup)
Commit: 5437499feb04f7a586f677b155b039bc2b3669eb
Date: 2024-06-18T22:34:26.404Z
Electron: 29.4.0
ElectronBuildId: 9728852
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Windows_NT x64 10.0.19045
Bug Summary and Steps to Reproduce
Bug Summary:
VSCode constantly mis-detects "FILE" as "undefined", even though one can trace it all the way back to the structure definition using "Go to definition"(F12).
Steps to reproduce:
-
Open "scp.c" from the top-level directory
-
Observe 250+ errors of
"resource": "/g:/cygwin/simh/simh/scp.c",
"owner": "C/C++: IntelliSense",
"code": "20",
"severity": 8,
"message": "identifier \"FILE\" is undefined",
"source": "C/C++",
"startLineNumber": 462,
"startColumn": 46,
"endLineNumber": 462,
"endColumn": 50
}]
Meanwhile clicking on the squiggled "FILE" for "definition", brings up this code snippet (code active) from <stdio.h>:
#if __POSIX_VISIBLE >= 200809 || _XSI_VISIBLE
/* As in stdio.h, <sys/reent.h> defines __FILE. */
#if !defined(__FILE_defined)
typedef __FILE FILE;
# define __FILE_defined
#endif
#endif
And then clicking on __FILE for definition again, opens its true struct view, from <sys/reent.h>
#if defined (__LARGE64_FILES) || defined (__CYGWIN__)
#ifdef __CYGWIN__
#define _fpos64_t _fpos_t
#endif
struct __sFILE64 {
unsigned char *_p; /* current position in (some) buffer */
int _r; /* read space left for getc() */
int _w; /* write space left for putc() */
short _flags; /* flags, below; this FILE is free if 0 */
short _file; /* fileno, if Unix descriptor, else -1 */
struct __sbuf _bf; /* the buffer (at least 1 byte, if !NULL) */
int _lbfsize; /* 0 or -_bf._size, for inline putc */
struct _reent *_data;
/* operations */
void * _cookie; /* cookie passed to io functions */
_READ_WRITE_RETURN_TYPE (*_read) (struct _reent *, void *,
char *, _READ_WRITE_BUFSIZE_TYPE);
_READ_WRITE_RETURN_TYPE (*_write) (struct _reent *, void *,
const char *,
_READ_WRITE_BUFSIZE_TYPE);
_fpos_t (*_seek) (struct _reent *, void *, _fpos_t, int);
int (*_close) (struct _reent *, void *);
/* separate buffer for long sequences of ungetc() */
struct __sbuf _ub; /* ungetc buffer */
unsigned char *_up; /* saved _p when _p is doing ungetc data */
int _ur; /* saved _r when _r is counting ungetc data */
/* tricks to meet minimum requirements even when malloc() fails */
unsigned char _ubuf[3]; /* guarantee an ungetc() buffer */
unsigned char _nbuf[1]; /* guarantee a getc() buffer */
/* separate buffer for fgetline() when line crosses buffer boundary */
struct __sbuf _lb; /* buffer for fgetline() */
/* Unix stdio files get aligned to block boundaries on fseek() */
int _blksize; /* stat.st_blksize (may be != _bf._size) */
int _flags2; /* for future use */
_off64_t _offset; /* current lseek offset */
_fpos64_t (*_seek64) (struct _reent *, void *, _fpos64_t, int);
#ifndef __SINGLE_THREAD__
_flock_t _lock; /* for thread-safety locking */
#endif
_mbstate_t _mbstate; /* for wide char stdio functions. */
};
typedef struct __sFILE64 __FILE;
So what IS the problem???
Another thing is that if I open PDP11/pdp11_rh.c and look for "RH11" symbol, it's a macro that uses OPT_RH11, line 148.
Going for definition for OPT_RH11 shows it in the file pdp11_defs.h in the same folder. BUT:
trying to find references of OPT_RH11 says there are NONE (either "Show references" or "Show All References")!
Simple "grep" through the sources in this directory reveals that OPT_RH11 is used 4 times in pdp11_cpumod.h, not to mention it's absolutely used in the initial pdp11_rh.c file where we started from.
These false-positives are extremely annoying!
I'm using VSCode on top on CYGWIN, with the following config file attached to the workspace (which is the checked out SimH directory from github).
Cygwin is installed into the "standard" location C:\Cygwin64, and VSCode opens include files from there.
Configuration and Logs
c_cpp_properties.json as found in .vscode for the SimH workspace (top level)
{
"configurations": [
{
"name": "Win32",
"includePath": [
"${workspaceFolder}/",
"${workspaceFolder}/PDP11",
"C:/Cygwin64/usr/include/**",
"C:/Cygwin64/lib/gcc/x86_64-pc-cygwin/11/include/**"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE",
"_GNU_SOURCE=1",
"__CYGWIN__",
"VM_PDP11=1",
"SIM_HAVE_DLOPEN=1"
],
"windowsSdkVersion": "10.0.17763.0",
"compilerPath": "C:/cygwin64/bin/gcc.exe",
"cStandard": "c17",
"cppStandard": "c++17"
}
],
"version": 4
}
User's settings.json stored in AppData\Roaming\Code\User:
{
"git.ignoreMissingGitWarning": true,
"extensions.autoUpdate": true,
"C_Cpp.default.systemIncludePath": [
"c:/cygwin64/lib/gcc/x86_64-pc-cygwin/11/include",
"c:/cygwin64/usr/include",
"c:/cygwin64/usr/include/w32api"
],
"C_Cpp.default.includePath": [],
"arduino.ignoreBoards": [
],
"editor.useTabStops": false,
"telemetry.telemetryLevel": "off",
"C_Cpp.intelliSenseCacheSize": 0,
"editor.rulers": [
80, 132
],
"update.enableWindowsBackgroundUpdates": false,
"extensions.autoCheckUpdates": false,
"files.autoSave": "afterDelay",
"cmake.showOptionsMovedNotification": false,
"workbench.localHistory.enabled": false
}Other Extensions
None of other extensions have anything to do with the issues above
Additional context
No response
@al20878 You should remove the system includes from your includePath
"C:/Cygwin64/usr/include/**",
"C:/Cygwin64/lib/gcc/x86_64-pc-cygwin/11/include/**"
and
"C_Cpp.default.systemIncludePath": [
"c:/cygwin64/lib/gcc/x86_64-pc-cygwin/11/include",
"c:/cygwin64/usr/include",
"c:/cygwin64/usr/include/w32api"
],
and instead rely on the compiler querying to provide those. You would only provide those if your compiler can't be queried, and if that's the case you should not use ** with system includes because ** puts the paths in a non-deterministic order and the order of system includes paths is important.
Those paths are there because otherwise, I was getting squiggles all over the place.
At any rate, I'd understand that inquiring the compiler would have probably resolved the "FILE" undefined issue (I'll try that to see if it does), but what about the "OPT_RH11" issue, I also described? That has nothing to do with the system includes, does it?
At any rate, I'd understand that inquiring the compiler would have probably resolved the "FILE" undefined issue (I'll try that to see if it does
It seems like it actually helped resolve FILE being undefined. Thanks for that. (I had that config in place for many years -- I had to place all those things in because it wasn't working correctly otherwise, back then.)
I also checked the OPT_RH11 issue just now, having cleaned the settings, but unfortunately (and as I thought) it is still there.