I edit my C code with VS Code (1.17.0) with C/C++ Extension (1.12.0) that provides error checking. I compile my code with GCC compiler that supports nested functions. So if I write this
int foo(int x)
{
int bar(int x)
{
return x * 2;
}
return bar(x) + 1;
}
and compile it with gcc it works fine. However, the extension doesn't think so and red-squiggles the second curly brace with a "semicolon expected" error. The extension allows you to choose IntelliSense mode which I set to "windows-gcc-x64", however it doesn't seem to work. This issue exists since 2017. Is there a fix or a workaround?
C/C++ extension for VSCode does not support nested functions yet.
There is an issue open in their repo already, which you can track here.
... it's been there since 2017 though
Related
The recommended Microsoft C/C++ extension for VSCode works great for C++ but fails at some places with C giving false errors. Here's one I have found:
void f(int a,int b, int arr[][b]);
This is valid C code and yet it says there's an error.
So how do I properly set up my intellisense to account for such nuances?
I'm trying to implement "labels as values" (https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html) in a c program using clang 3.7 in Visual Studio 2015.
As a toy example I had the following code which causes the compiler to crash (internal error "fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'c:\agent\build\cache\git\vctools\vctools\compiler\utc\src\p2\main.c', line 246)
1> To work around this problem, try simplifying or changing the program near the locations listed above.").
const void *array_jump[] = {&&S1,&&S2,&&S3,&&S3,&&S4};
S1:
goto *array_jump[3];
S2:
return 2;
S3:
return 3;
S4:
return 4;
If I move the array declaration to after all of the labels it works, until I include the array_jump variable in any of the statements.
S1:
//comment out and add "return 1;" and it will compile fine
goto *array_jump[3];
S2:
return 2;
S3:
return 3;
S4:
return 4;
const void *array_jump[] = {&&S1,&&S2,&&S3,&&S3,&&S4};
Can anyone provide an example like the one above that should work? Is this a problem with clang or with the "codegen" aspect for Visual Studio?
I think this bug is relevant but I'm not sure:
https://connect.microsoft.com/VisualStudio/feedback/details/2103400/crash-in-clang-c2-with-address-of-label-extension
The examples you build should work, I've just verified it using Apple LLVM version 7.0.2 (clang-700.1.81).
The mentioned bug reports seem to report this very same issue, until it's fixed, you can't do anything aside from trying to not use the extension.
While GNU C has some great extensions, if you want to write portable c code, try to avoid using any GNU C extension.
What you've linked to is a gnu-specific extension to the language. If you're not using a gnu compiler (I don't believe clang is), then it won't necessarily work. The documentation says to check for definition of the __GNUC__ name in the processor. Try adding this...
#ifndef __GNUC__
#error Not a GNU compiler, does not include GNU specific extensions
#endif
I have the error C4576 in Visual studio 2015 when I tried to compile the file: transcoding.c.
The source code of this file is here: transcoding.c
error C4576: a parenthesized type followed by an initializer list is a non-standard explicit type conversion syntax
The error arise at line 127 in this instruction:
enc_ctx->time_base = (AVRational) { 1, enc_ctx->sample_rate };
I used the source of ffmpeg in my project
https://www.ffmpeg.org/download.html
I searched around for a solution but I'm not able to correct the error
If someone have found something similar, please provide an idea
Despite what some other answers incorrectly claim, VS2015 compiler provides comprehensive support for C99 features, including the compound literal feature you are trying to use in that problematic line.
One possible explanation for the error message is that it the source file, despite being named as .c file, is being compiled as C++ file. The project settings might explicitly request C++ compiler for this file. In C++ this code is invalid.
Check your compilation settings to see if it by any chance includes a /TP ("compile as C++") switch.
Old question, but...
The solution is pretty simple:
AVRational tb;
tb.num = 1;
tb.den = enc_ctx->sample_rate;
enc_ctx->time_base = tb;
or
enc_ctx->time_base.num = 1;
enc_ctx->time_base.den = enc_ctx->sample_rate;
Remove the parenthesis around the type in the macro definition.
That should work.
enc_ctx->time_base = AVRational { 1, enc_ctx->sample_rate };
Looks like a question where the C and C++ tags make sense. You're trying to compile C99 code with a C++ compiler. That doesn't work.
I'm trying to use SWIG to create a Octave function. But even the most basic example code seems to fail before I even get the chance to get it into octave. I am not sure if I should be concerned that swig creates a extension type for the C++ source file (.cxx) it generates that mkoctfile doesn't recognize (it only takes .C .cpp .cc, which seems like allot for swig to mess up that much and create what seems like the ONE extension for C++ it doesn't support).
Any help from someone with more experience with this would be greatly appreciated!
The steps I have done are as follows:
swig -octave swig_test.i
mv swig_test_wrap.cxx swig_test_wrap.cpp <--- This is necessary because mkoctfile doesn't recognize the cxx type c++ code that swig generates
mkoctfile swig_test_wrap.cpp
This results in 4 errors consistantly:
swig_test_wrap.cpp:1449:24: error: invalid covariant return type for 'virtual Octave_map octave_swig_type::map_value() const'
/usr/include/octave-3.4.0/octave/../octave/ov-base.h:560:22: error: overriding 'virtual octave_map octave_base_value::map_value() const'
swig_test_wrap.cpp:1657:24: error: invalid covariant return type for 'virtual Octave_map octave_swig_ref::map_value() const'
/usr/include/octave-3.4.0/octave/../octave/ov-base.h:560:22: error: overriding 'virtual octave_map octave_base_value::map_value() const'
The source code of my outlandishly basic swig_test.c
int fact(int n) {
if (n <= 1) return 1;
else return n*fact(n-1);
}
int my_mod(int x, int y) {
return (x%y);
}
Then the code of my wrapper inteface file swig_test.i
%module swig_test
%{
extern int fact(int n);
extern int my_mod(int x, int y);
%}
extern int fact(int n);
extern int my_mod(int x, int y);
___________________________________________________
UPDATE: May 9th 2011
So I still have not found a solution to this, and am starting to wonder if maybe these programs are out of date? The documentation most certainly is. Just as an example: the instructions say
swig -octave swig_test.i -o swig_test_wrap.cxx
now that will certainly not work regardless, because mkoctfile wont take type cxx as stated before. Also, this command just is physically written wrong. As typed above, it returns the error.
swig error : unrecognized option example.i
use swig -help for available options
The command SHOULD be entered as:
swig -octave -o swig_test_wrap.cpp swig_test.i
That WILL generate the swig_test_wrap.cpp file just as advertised. I would have thought there would be a -i option for input file in the argv of swig, but hey, now that I know that order matters here, someone must have just not updated the documentation when they changed something about how the function works.
So now, after running this command I have my swig_test_wrap.cpp file. Next I take that and try to execute
mkoctfile swig_test_wrap.cpp swig_test.c
Again, I get the same error as above: "invalid covariant return type" etc, however I also DO get a file swig_test.o out of the process. Just for fun, I then ran
mkoctfile swig_test.o
And lo and behold, this DOES generate a file called swig_test.oct. However when I went into octave and tried to load the file by running
octave:1>swig_test
I get the response error: 'swig_test' undefined near line 1 column 1
So as far as I can tell, I'm right back to square one. Anyone have any ideas?
So it turns out that this issue is related to the version of octave that I was using. Octave version 3.4.0 doesn't seem to work with swig yet. I got help on source-forge and once i downgraded to version 3.2.4-r3 it works perfectly.
And it is a known bug that you have to use:
swig -octave -o WRAPFILE.cpp INPUT.i
and its a problem with mkoctfile that you have to use the .cpp extension, since they SHOULD accept the .cxx extension as it is a valid extension for C++ files.
Try:
$ swig -octave -c++ swig_test.i -o swig_test_wrap.cxx
$ mkoctfile swig_test_wrap.cxx swig_test.c
as described here.
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.