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.
Related
I have a C project which i open in VisualStudio 2019 with the "Open folder" option. I added a CppProperties.json to get Intellisense running, but now it throws errors if i try to declare a variable in a for loop like this:
for (int i = 0; i < 10; i++)
{
}
error: E0029 expected an expression
error: E0020 identifier "i" is undefined
I searched StackOverflow already and found this thread where someone mentions that the declaration of variables in for loops was added in the C99 standard.
In the VisualStudio documentation it says you should add "-std=C99" to your project settings, but i have no project file (because I opened it with the "Open Folder" option) and therefore no project settings.
Is there a way to tell Intellisense what C standard to use anyways ?
Thanks in advance.
Found it: Just add
"compilerSwitches": "-std=c99",
to your CppProperties.json.
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
First, you can successfully compile the following main.c through DDK build utility.
#include <ntddk.h>
NTSTATUS DriverEntry(PDRIVER_OBJECT, PUNICODE_STRING)
{
try
{
leave;
}
except (1)
{
}
return 0;
}
And however, please note that:
Both of "leave" and "except" are not valid C-language kerwords.
I know both of __leave and __except (i.e. with double leading underscores) are microsoft-specific keywords to extend the C language, but "leave" and "except" not.
I also confirmed that "leave" and "except" are not defined by macro. MSDN explains none about this.
Who can give me an explanation? Thanks in advance.
As Rohan noted, they are defined by macro in warning.h. The definitions are there for backward compatibility with old code which used the non-underscore versions.
Im trying to compile z/lib on z/OS USS(thats right a mainframe). ive got gmake and the c89 compiler (which im assuming is c89 standards compliant) and USS is supposed to be POSIX compliant.
But zlib seems to be tripping up on
struct internal_state FAR *state; /* not visible by applications */
with the following error(s)
c89 -O3 -DUSE_MMAP -D_XOPEN_SOURCE_EXTENDED=1 -D_POSIX_SOURCE -c -o example.o example.c
ERROR CCN3277 ./zlib.h:92 Syntax error: possible missing ';' or ','?
ERROR CCN3007 ./zlib.h:92 "struct internal_state" is undefined.
ERROR CCN3166 ./zlib.h:103 Definition of function FAR requires parentheses.
ERROR CCN3276 ./zlib.h:103 Syntax error: possible missing '{'?
ERROR CCN3273 ./zlib.h:124 Missing type in declaration of gz_header.
ERROR CCN3166 ./zlib.h:126 Definition of function gz_header requires parentheses.
ERROR CCN3276 ./zlib.h:126 Syntax error: possible missing '{'?
WARNING CCN3137 ./zlib.h:1346 Declaration must declare at least one declarator, tag, or the members of an enumeration.
ERROR CCN3275 ./zlib.h:1350 Unexpected text z encountered.
ERROR CCN3282 ./zlib.h:1350 The type of the parameters must be specified in a prototype.
ERROR CCN3275 ./example.c:95 Unexpected text file encountered.
ERROR CCN3045 ./example.c:95 Undeclared identifier gzFile.
ERROR CCN3046 ./example.c:96 Syntax error.
ERROR CCN3045 ./example.c:98 Undeclared identifier file.
ERROR CCN3019 ./example.c:523 Expecting an array or a pointer to object type.
ERROR CCN3280 ./example.c:527 Function argument assignment between types "const char*" and "int" is not allowed.
CCN0793(I) Compilation failed for file ./example.c. Object file not created.
FSUM3065 The COMPILE step ended with return code 12.
FSUM3017 Could not compile example.c. Correct the errors and try again.
gmake: *** [example.o] Error 3
when i progressively take out the FAR * (i think its a far pointer but im really not that sure) the errors go away. But as this is a library, im not sure what other artifacts are going to be produced by removing this.
has anybody got any ideas?
any old mainframe heads out there?
it turns out there is a previous version of zlib that compiles on USS, version 1.1.4 or close to that. Its a back level, but i presume this works because it is before the implementation of the FAR pointer in the latest code. So atm i think ive got it to work.
thanks for all your help.
Regards
Mark.
FAR is not a C89 keyword, it is a Microsoft/Intelism and is probably #defined somewhere. If not, you need to define it as nothing:
#define FAR
However, this will probably only fix one of many problems. I would guess that the library uses some form of conditional compilation to handle things like FAR pointers - you need to read the docs to find which configuration is most suitabkle for your platform.
I'd use xlc instead of c89 since xlc is your system default compiler but you'll still probably have issues. I'd subscribe to the MVS-OE email list, the people on it are quite helpful. The link to info about the list appears to be down now so send email to
LISTSERV#VM.MARIST.EDU
with the message: INFO MVS-OE
FWIW, IBM provides a prebuilt version of zlib that includes support for the compression hardware (so-called zEDC) available on recent-vintage mainframes. See zlib for zEnterprise Data Compression
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.