I am trying to compile a console C application on HP-UX machine using the aCC compiler [HP C/aC++ B3910B A.06.26].The compilation always failing with the below error :
******"Common/Common.c", line 153: error #2020: identifier "snprintf" is undefined
snprintf( BufferMessage, MSG_SIZE,
^
1 error detected in the compilation of "Common/Common.c".
gmake: *****[Common/Common.o] Error 2********
However the Common.C file include already the library which contain normally the method snprintf.
any idea to solve this isse plz?
Thanks in advance for all
snprintf() was introduced in C99, and is defined in <stdio.h>, so your compiler must support that version of the C standard. If it does not support C99 then use sprintf() instead.
Version 6 of the HPUX C compiler is C99-compliant but you may need switches to enable it.
The 6.20 release notes stated that the next release should switch the default mode from C89 to C90, and you're running 6.26. It appears that it did happen in 6.25, which was the release following 6.20.
You could force C99 mode by using cc -AC99 (or cc -Ae now that C99 is the default) to see if that helps. It may be that, even though the default C compilation mode is C99, you still have to specify it's C rather than C++.
Some other things to check:
See if you've included the stdio.h header.
See if you get a similar problem with just printf, which is also in that header.
Run the compiler generating pre-processor output (cc -E) and check that it's defined somewhere.
Related
vscode default c syntax checker seems that c standard used not high (maybe c99 or lower)
like the example following:
array ellipsis is available in c11 , actually it can compiled successfully if specified flag with "std=c11"
but vscode still seem it as a syntax error and underline it.
compiler is gcc rather than clang
have some way to fix it?
I have been worked on M3 circuit and wrote some simple code including identifier "uint".
I got an error saying Fatal Error[Pe1696]: cannot open source file "stdint.h".
Do I have to add the source file by myself or is there any way to solve this??
stdint.h was added to C with the year 1999 version of the standard, known as "C99". To use it, you need a compiler that supports C99 or later. Some compilers support it, but it is not enabled per default. This appears to be the case here.
The latest version of IAR supports the current standard C11, and thereby also the previous standard C99. See this link: https://www.iar.com/support/resources/articles/exploring-c11-and-c14/
Click on "C11".
What is the difference between using -pedantic-errors and -Werror=pedantic in gcc?
According to the documentation of GCC there is a difference:
-pedantic-errors
Give an error whenever the base standard (see -Wpedantic) requires a diagnostic, in some cases where there is undefined behavior at compile-time and in some other cases that do not
prevent compilation of programs that are valid according to the
standard. This is not equivalent to -Werror=pedantic, since there are
errors enabled by this option and not enabled by the latter and vice
versa.
What errors are included by -pedantic-errors, but not by -Werror=pedantic?
What errors are included by -Werror=pedantic, but not by -pedantic-errors?
Any example of both types of errors?
A little insight as to why the two options exist separately in chapter 14:
Some ISO C testsuites report failure when the compiler does not produce an error
message for a certain program
ISO C requires a “diagnostic” message for certain kinds of invalid programs, but a
warning is defined by GCC to count as a diagnostic. If GCC produces a warning but
not an error, that is correct ISO C support. If testsuites call this “failure”, they should
be run with the GCC option ‘-pedantic-errors’, which will turn these warnings into
errors.
So it sounds like there's some ISO C rules that are not explicitly marked as invalid C but instead valid-ish C. These are the rules that -pedantic-errors makes into errors that -Werror=pendantic doesn't. You'll have to look at ISO C standard for more information on that.
As far as what errors are turned on/off as documented by GCC, there is but 1 that has -pendantic-errors explicitly:
-Wno-implicit-function-declaration
(C and Objective-C only)
This option controls warnings when a function is used before being declared. This warning is enabled by default in C99 and later dialects of C, and also by -Wall. The warning is made into an error by -pedantic-errors.
Note: however it seems that not all the authors of the manual have the same idea. In section 2 it talks about -pendantic-errors as if it WAS the same:
to obtain all the diagnostics required by the standard, you should
also specify ‘-pedantic’ (or ‘-pedantic-errors’ if you want them to be errors rather than
warnings).
So I believe you've discovered an editorial discrepancy.
What does __G signify in C?
I'm using GCC 4.9.
I'm using latest MinGW version.
I'm compiling with -std=gnu11.
I have the following C (being compiled with GCC as C11) code:
#ifndef __G
#define __G 0
#endif
It compiles fine.
But now, while compiling with the latest MinGW, i get the following:
In file included from ../common/sysbase/sysbase.h:6:0,
from Monitor.c:5:
../common/sysbase/sysbase_chk.h:3:13: error: expected ';', ',' or ')' before numeric constant
#define __G 0
compilation terminated due to -Wfatal-errors.
GCC under MinGW64 seems to be using `__G for something.
I could not find it in any header.
__G is simply an identifier. I'm not aware of any standard usage of it, but since it starts with two underscores, it's reserved to the implementation for all purposes. The word "implementation" here refers to the C compiler and library, not to any code you write (unless you're implementing part of the compiler or C standard library yourself.)
(The standard says that any identifier starting with two underscores, or with an underscore and an uppercase letter, are reserved for any use; any identifier starting with an underscore is reserved for use with file scope. See section 7.1.3 of the N1570 C standard draft.)
You should not use it in your own code. Doing so causes your program's behavior to be undefined.
The C implementation (either the compiler, the linker, a header, or the library) is permitted to define __G in any way it likes. Apparently this is what you've run into.
In answer to a question in your comment:
Now, after more than a year compiling codes with those headers, will I have to change aaalll my codes?
Yes, that's exactly what I'm saying. Your usage of __G has always been incorrect; you just happen not to have run into any visible symptoms until now.
(It's at least conceivable that previous versions of MinGW defined it in some way that didn't cause your code to fail to compile, but that could have cause it to misbehave.)
I recently realized that I am not even in C99 mode after receiving the compile error
'for' loop initial declarations are only allowed in C99 mode
I found some advice on how to get to C99 via a quick search which has told me to go to Projects -> Properties... But alas, it is greyed out and I am not sure that is even the correct way to fix it (probably not available because my file is not a project, it is a normal source file). I have also seen a lot of similar questions saying to enable C99 mode so I have looked inside the compiler flags menu, but I cannot see anything about C99. I have tried some other flags such as In C Mode, support all ISO C90 programs..., but after I set this flag, I got more errors than I had before which seem to appear whenever the compiler finds comments inside main().
Note: Please don't just say to initialize the counter outside the for loop.
Update: While trying to compile outside of codeblocks with gcc, I tried
gcc -O2 -std=C99 filename.c, but received an error:
unrecognized command line option "-std=C99"
I use 64-bit Windows 7, CodeBlocks10.05, and GNU gcc.
For future reference, type in the flag -std=c99 in settings->compiler->other options which is not case-sensitive, however when compiling in a terminal the flag is case-sensitive. Thanks chris!