Visual Studio Open Folder GCC (Cygwin) Intellisense Errors - c

I'm trying to configure Visual Studio Community 2019 for use as the IDE for work on an open source C project targeting the Nintendo 64.
The makefile seems to define a gcc-derivative (mips64-elf-gcc) as the compiler and has -std=gnu99 as one of the CFLAGS, so I assume that means this is C99.
I don't know much about C development, so I initially followed a tutorial, which directed me to set up Cygwin. For a time I edited the *.h and *.c files in Notepad++ and then used the Cygwin terminal to compile everything (there's probably a thousand better ways, but I'm a C/*nix nub and just wanted to get something off the ground quickly). Notepad++ was ok just to tinker around with things, but I'm getting more serious about this project and doing any real work in Notepad++ is a real bother. I've used Visual Studio for a long time, so I figured I'd try getting things set up there, since I know it has support for C/C++.
I've successfully gotten VS to run my makefile using the "Open Folder" feature and by wiring up the requisite data within the CppProperties.json and tasks.vs.json files. While attempting to get IntelliSense working, however, I've run into a few errors that I can't resolve.
1. 'duplicate parameter name' in stdio.h & string.h
There are several instances of this error. The problem seems to be lines like this one:
FILE * freopen (const char *__restrict, const char *__restrict, FILE *__restrict);
As you can see, there are multiple "parameters" all named __restrict. I'm still just beginning my C journey, so I'm not entirely sure what this is, but my suspicion was that it wasn't a parameter name, but might be #defineed somehwere. Using the Agent Ransack file search utility, I looked for instances of #define __restrict and did find some. I added those paths to the INCLUDE section of my CppProperties.json file, but that didn't help at all.
According to the VS Open Folder tutorial, IntelliSense can sometimes get hung up on preprocessor directives, so I added the recommended cpp.hint file, closed VS, deleted cached data in the .vs folder, and started VS back up, but the errors still persist.
2. "expected a ')'" in stdio.h
I assume this one is also related to that __restrict issue.
FILE * fopen (const char *__restrict _name, const char *__restrict _type);
^
| expected a ')'
It seems to be unhappy about the _name parameter for some reason.
3. 'expected an expression / identifier "i" is undefined' in my for loops
Any place in the code I've been working on where a for loop is defined, I get these errors. Here's an example of the errors:
void v(void)
{
for (int i = 0; i < 25; i++)
{ ^ ^
| | identifier "i" is undefined
|
| expected an expression
}
}
If, however, I change the loop to the following, everything is fine.
void v(void)
{
int i;
for (i = 0; i < 25; i++)
{
}
}
It's not liking the int type declaration in in the init-expression of the for loop. I'm not sure what I could've done in configuration to break a core language feature. I assume something about the previous errors are affecting this.
None of this affects the build process, since all of that is still being done through the makefile using everything I have set up in Cygwin, so I guess it isn't critical to fix these issues, but the whole point of doing this was to have a nice environment to work in and having 61 errors constantly hanging out is probably gonna put a pretty big damper on that situation.
I've tried everything I can think of to resolve these issues and nothing has worked. This is a particularly difficult issue to google, due to the large number of potential contributing factors required as search terms, so that hasn't proved fruitful.
Any help or advice is appreciated.

Related

Link with custom function instead of crt one

I'm working on an application which defines it's own printf() to get around differences between the different CRTs out there or because some other platforms don't have it.
When building the application with gcc this automatically seems to work and the custom printf is used instead of libc's one; if I understand it correctly this is because of the order in which object files/libraries appear in the link command or maybe because object files are always searched before CRT libs, correct?
I'd like to do the same using msvc. Just building the project gives the expected 'LNK2005: _printf already defined in printf.obj' because printf is also in msvcrtd.lib. Fair enough. I know about /NODEFAULTLIB but that excludes everything resulting in unresolved references for everything but printf. I scanned through the other linker settings but couldn't find anything which allows this (apart from /FORCE maybe, but the 'might produce an invalid executable' comment doesn't make it sound like a good idea). Also nothing in the module definition file docs; the latter got me thinking it might be possible to create a stub library which has all exports from msvcrt.lib except printf but that seems a brittle solution even if it works.
In the end the question is simple: how do I tell msvc's linker it should skip msvcrt's printf definition and use the one from my printf.obj instead. Basically /NODEFAULTFUNCTION:printf or so. Just an answer for one single executable is ok, though I'd also be interested to know if and how it can be done when building a dll instead where the custom printf is exported: how to tell the linker it should use the export from my .lib instead of msvcrt.lib?
edit simplest repo I could find: create a file main.c:
#include <stdio.h>
int main(int argc, char** argv)
{
printf("Hello");
return 0;
}
and a file printf.c:
int printf(const char *fmt, ...)
{
write(1, "ok\n", 3);
return 3;
}
For VS2013 (though the other versions might work as well): create a new empty C++ project and add both files then build. (For gcc: just gcc main.c printf.c and the resulting a.out prints 'ok')
The culptrit for VS is #include : without that it works ok but I have yet to find out if the original code allows getting rid of it in some way. But even if it does I'd still want to know if this can be solved at the link level.

Minix 3 stdio.h doesn't recognize FILE *f

I'm developing something on Minix 3 and, when it comes to deal with io files, I got a problem.
In the code:
#include <stdio.h> /* If I don't call any stdio funcs compiler doesnt's complain*/
int main() {
FILE * fp; /* I get the following: " * not expected " */
return 0;
}
Already tried everything that comes to my mind, can't figure it out..
/EDIT/
From what I can tell, when I include something, if I call functions not related to structs, it's OK. Is it the structs ?
I will assume you have checked whether the Minix file is present, that it really defines the type FILE and that your include path provides the correct -Ioption to the compiler to find that file.
Depending on your environment it could happen that an environment variable INCLUDE exists and is recognized by your compiler to provide additional include paths, recognized even before the include options from the command line. In such a case it might happen to include a stdio.hfrom a different compiler. Visual Studio is known to provide such an environment variable by default, and that has bitten me once before.
EDIT: Running the preprocessor in isolation may help to find out what is really happening in any case. Verify that FILEis defined in the preprocessed version of your file.

FreeRTOS, Eclipse IDE, and Syntax Errors

I have a slight annoyance when dealing with FreeRTOS code in Eclipse and I'm not sure if it's just me or if other people have this issue too but I see a lot of syntax errors highlighted in my code but it compiles/executes fine. The syntax errors seem to be caused by FreeRTOS specific code like:
signed portCHAR *x;
or
vSemaphoreCreateBinary (semaphore);
or
signed portBASE_TYPE gpsTaskStart (void)
{
return xTaskCreate (vGPSTask, (const signed portCHAR * const) "GPS", configMINIMAL_STACK_SIZE, NULL, (tskIDLE_PRIORITY + 1), &taskHandles [TASKHANDLE_GPS]);
}
I was wondering if there was a way to configure Eclipse to parse this syntax properly.
I think you just have to update your Eclipse project configuration for the incremental checker to be able to find FreeRTOS symbol definitions.
Right click on your project > Properties > C/C++ General > Path and Symbols > Includes.
Add the FreeRTOS folder there.
Go to project settings > directories and include all directories containing .h files (including portable/GCC/%yourplatform%). Once done, make a build. This should work, at least works for me.

fopen fails mysteriously under Windows

Maybe I just have another black out but, this one line is giving me a lot of troubles:
FILE *fp = fopen("data/world.data", "rb");
This works fine under Linux when compiled with GCC. But when I compile it with Visual Studio, it crashes. fp is always NULL. Both the BIN and the EXE are in the exact same directory. Now, to make things even crazier, when I run the EXE using Wine under Linux... it... works...
I have absolutely not a god damn clue what's going on here. Maybe it's some insanely stupid mistake on my side, but I cannot get this thing to run under Windows :/
Also, I have another program which works just fine, there the data files are also contained in a sub directory named data.
EDIT:
To make it clear neither / NOR `\ * do work.
EDIT 2:
OK I've given up on this, maybe someone has fun trying to figure it out, here's ZIP containing the EXE, Debug Data for VS etc.:
https://dl.dropbox.com/u/2332843/Leaf.zip
EDIT 3:
Compiled it with CodeBlocks and MinGW, works like a charm. Guess it has to do something with MSVC or the Project Settings in VS.
It sounds like data isn't a subdirectory of your current directory when you run the program. By default (for x86 targets) VS will build and run your program from either a DEBUG or RELEASE subdirectory of the base directory you've created for the project. You can modify the directory that will be "current" when it runs though (e.g., project | properties | configuration properties | debugging for VS 2008).
Edit: While Windows requires that you use a backslash as a directory separator at the command line, a forward slash works fine in code -- this is not the source of your problem.
In windows you have to write the following:
FILE *fp = fopen("data\\world.data", "rb");
This is like that because the backslash is a special character (so a backslash in a string is written using \ and a quotation symbol is \" and so with other special characters).
Since this issue happens only on windows. I doubt whether the file is really named "world.data". As you know, the default setting for windows hides the file extention. Is its real name world.data.xxx?
Include a line to GetCurrentDirectory(), to see if you are running from the directory you expected.
When I develop in C#/ C++ on visual studio, I normally get to run it from the debug folder. I don't think it matters if forward slash is used in place of backslash in .net.
I happened to have the same problem, and suddenly i figured it out.
That should be your windows fault.
Let's say, FILE *fp = fopen("data/world.data", "rb"); in windows, if you hide the extensions, then you can see the file data/world.data, but actually it maybe /data/world.dat.txt or somewhat.
So please check the extensions.
Hope it helps!
I ran into this today, and it happened because I used "br" instead of "rb" on that mode argument.
The underlying fopen is throwing an exception of some kind, which only registers as a crash. It's not bothering to return the standard NULL response or set the associated error values.
I'm not sure but it may be because you're using slash instead of (an escaped) backslash in the path?

Why does Eclipse CDT say: 'syntax error', but compilation no problem

I am working in existing C code which has a couple of lines with statements similar to this one:
struct collect_conn *tc = (struct collect_conn *)
((char *)c - offsetof(struct collect_conn, runicast_conn));
The struct collect_conn goes along the following lines:
struct collect_conn {
struct runicast_conn runicast_conn;
struct announcement announcement;
const struct collect_callbacks *cb;
struct ctimer t;
uint16_t rtmetric;
uint8_t forwarding;
uint8_t seqno;
};
I am using Eclipse CDT, and it marks the line with an orange squiggly line as 'syntax error'. I think it is marked as such by the CDT indexer.
However, compilation (manually in a terminal) is no problem.
This is a bit inconvenient however, since the elements on the line don't get indexed (so the call hierarchy tree isn't always correct, or the highlighting of elements, etc.)
Why does Ecipse not like the line as it is?
Eclipse CDT contains its own preprocessor/parser for analyzing your code and building an index. However, when you invoke a build CDT calls out to your system compiler, like gcc for example. There may be minor differences between the syntax accepted by the CDT parser and the syntax accepted by your compiler. When this happens the CDT parser can get confused.
On my system the offsetof macro expands into an expression that uses the __offsetof__ keyword. This keyword isn't recognized by CDT so that's why there's a syntax error. To deal with this problem the CDT parser has a macro built in to deal with __offsetof__ which looks like this:
#define __offsetof__(x) (x)
This doesn't appear to be correct, at least on my system the result is the removal of the __offsetof__ keyword from the source which still leads to a syntax error.
I was able to get rid of the syntax error by going to the Paths and Symbols property page and adding a macro for __offsetof__ which maps to 'foo'. This tricks the parser into thinking its just a call to a function it hasn't seen before, but not a syntax error.
Alternatively you can turn off syntax error reporting in the editor by going to Window > Preferences > General > Editors > Text Editors > Annotations and unchecking all the checkboxes for C/C++ Indexer Markers.
I've fixed problem in eclipse CDT with Preferences->C/C++->Language Mappings : Add
Content Type : C-header
Language : C++
Sometimes, although the code compiles with no error, eclipse CDT's real-time code analyzer shows some errors in C/C++ files (eg. 'Function xxx could not be resolved). This is because eclipse CDT uses its own preprocessor/parser for analyzing the code and building the indexes instead of the MinGW's one (or any other GNU compiler). In order to fix this globally for all eclipse projects in the workspace, follow these steps:
(In order to fix this only for a specific project, follow steps 1, 2 and 4 in menu 'Project->Preferences')
1-In menu 'Window->Preferences->C/C++->Language Mappings', add the correct mappings as shown in below: (eg. for content types: C++ Source/Header File, use GNU C++ language and so on)
2-In menu 'Window->Preferences->C/C++->Indexer', set full indexing by checking all checkboxes (but not 'Skip' ones) as shown in below:
3-In each project's specific properties, menu 'Project->Properties->C/C++ general->Indexer', Uncheck 'Enable project specific settings' as shown in below:
4-Rebuild the indexing, menu 'Project->C/C++ Index->Rebuild'.
It seems the CDT parser doesn't like the portion offsetof(struct ...).
If you declare collect_conn using a typedef the error goes away. At least for me, the following code works:
typedef struct {
struct runicast_conn runicast_conn;
struct announcement announcement;
const struct collect_callbacks *cb;
struct ctimer t;
uint16_t rtmetric;
uint8_t forwarding;
uint8_t seqno;
} collect_conn;
...
struct collect_conn *tc = (struct collect_conn *)
((char *)c - offsetof(collect_conn, runicast_conn));
If you can't change the original declaration do something like this:
typedef struct collect_conn collect_conn_t;
It might be confused, check if you have a definition of offsetof in-scope, for instance. Otherwise you might try simplifying the expression, breaking it up using e.g. a #define with the offset of, or something.
I'm thinking the compiler might provide a built-in version of offsetof, while Eclipses's compiler/code-parser might not. If so, you would need to make sure you have the definition, for Eclipse to be able to properly parse your code.
try switching the indexer to "Full c/C++ indexer (complete parse)" in Preferences->c/C++ -> indexer
Iv got the same problem. There is 2 definition of offsetof (one for C and one for C++). IMO the problem come from that
For example if i type
#ifndef __cplusplus
#endif
Eclipse will grey it. It mean __cplusplus is defined, but my project is a C
Unfortunatly i dont find a fix.
I fixed similar problem after checking the tab Error Parsers in Makefile Project in New CDT Project Wizard, removing CDT Visual C Error Parser (I am using gcc)
I ended up solving the problem like this. First I opened the project properties, then the C/C++ general->Paths and Symbols category. Under the Symbols tab I added this entry:
Symbol: offsetof(TYPE,MEMBER)
Value: ((ssize_t) &((TYPE *)0)->MEMBER)
These symbols are used by the indexer but not passed to the compiler (at least in Makefile projects, I haven't tried it in the other kind of C project), so it doesn't override GCC's built-in offsetof
I've seen Eclipse do this some times, and I use it for Java. Usually closing and opening the file again fixes it for me (resets whatever is wrong). It usually seems to be an error that WAS there but has been fixed and the "error cache" isn't updated correctly.

Resources