I have a function, createFile that uses fchmod:
int createFile(char *pFileName) {
int ret;
if ((ret = open(pFileName, O_RDWR | O_CREAT | O_TRUNC)) < 0)
errorAndQuit(2);
fchmod(ret, S_IRUSR | S_IWUSR);
return ret;
}
At the top of my file, I have the following includes:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/stat.h>
#include <fcntl.h>
When compiling: the compiler spits out:
warning: implicit declaration of function ‘fchmod’
I'm including all of the correct files, yet getting this warning. The program runs fine, even with the warning.
By a happy coincidence, your question is directly answered by the feature_test_macros(7) manpage:
Specification of feature test macro requirements in manual pages
When a function requires that a feature test macro is
defined, the manual page SYNOPSIS typically includes a note
of the following form (this example from the chmod(2) manual
page):
#include <sys/stat.h>
int chmod(const char *path, mode_t mode);
int fchmod(int fd, mode_t mode);
Feature Test Macro Requirements for glibc (see
feature_test_macros(7)):
fchmod(): _BSD_SOURCE || _XOPEN_SOURCE >= 500
The || means that in order to obtain the declaration of
fchmod(2) from <sys/stat.h>, either of the following macro
definitions must be made before including any header files:
#define _BSD_SOURCE
#define _XOPEN_SOURCE 500 /* or any value > 500 */
Alternatively, equivalent definitions can be included in the
compilation command:
cc -D_BSD_SOURCE
cc -D_XOPEN_SOURCE=500 # Or any value > 500
You didn't specify what compiler or platform you're using, but on my recent Linux installation, fchmod() is defined in but guarded by a couple of #ifdefs (__USD_BSD and __USE_XOPEN_EXTENDED).
You aren't supposed to set those directly, but rather via the _FOO_SOURCE macros in . Try defining _XOPEN_SOURCE_EXTENDED or just _GNU_SOURCE and recompiling (and note that these macros enable nonstandard functionality and use of the functionality they enable may limit the portability of your code).
I have faced this error while building uml.
Just add this line in the file where this error is thrown:
#include "sys/stat.h"
I believe it will take care about adding the macros defined in the above answers.
Related
Let's say for instance I want to use the structure timespec, which is defined in time.h. According to the manpages I only need to include time.h. But when compiling in c99, this isn't enough:
#include <stdio.h>
#include <time.h>
struct timespec abcd;
int main(int argc, char *argv[])
{
return 0;
}
According to the info I find online (not in the manpages), I need to add this:
#define _POSIX_C_SOURCE 200809L
So I have a few questions:
How do I know to which value I need _POSIX_C_SOURCE to be equal? I found multiple values online.
Why does the placement of this definition influence the compilation? (cf . infra)
#include <stdio.h>
#define _POSIX_C_SOURCE 200809L
#include <time.h>
struct timespec abcd;
int main(int argc, char *argv[])
{
return 0;
}
$ gcc test.c -Wall -Wpedantic -std=c99 -o test
test.c:9:25: error: field ‘time_last_package’ has incomplete type
struct timespec time_last_package;
compiles well:
#define _POSIX_C_SOURCE 200809L
#include <stdio.h>
#include <time.h>
....
Thanks
How do I know to which value I need _POSIX_C_SOURCE to be equal? I found multiple values online.
There is one value per POSIX standard definition. So you can use any value which:
defines the functionality you need
is supported by your hosting OS
Best is to use the lowest value that meet both those criteria.
Why does the placement of this definition influence the compilation?
POSIX says :
System Interface Chapter 2. Section 2 The Compilation Environment: A POSIX-conforming application should ensure that the feature test
macro _POSIX_C_SOURCE is defined before inclusion of any header.
Otherwise it may leads to wrong/incompatible included definitions... Defining it before any include ensure that all is under the same POSIX version...
Recommended reading : The Open Group Base Specifications Issue 7, 2018 edition, 2 - General Information
The other answer gives nice background. But, it's also possible to define this at the compiler level so you don't have to put it in your source. With gcc and glibc at least, the command-line option
-D_POSIX_C_SOURCE=199309L
is enough to ensure that nanosleep and struct timespec are available if you include <time.h>.
I am trying to make a C program that uses named pipes to communicate with a C++ program on a Raspberry Pi 3.
The warning that GCC is spitting out when I compile some code of mine:
/home/pi/BluetoothTest/btooth.c|76|warning: implicit declaration of function ‘mknod’ [-Wimplicit-function-declaration]|
Here is the code from for the function, including the #if above it:
#if defined __USE_MISC || defined __USE_BSD || defined __USE_XOPEN_EXTENDED
extern int mknod (const char *__path, __mode_t __mode, __dev_t __dev)
__THROW __nonnull ((1));
and here are the includes that I have in the file:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <pthread.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>
#include <bluetooth/rfcomm.h>
//#include <linux/stat.h>
The program attempts to create the pipe here:
umask(0);
fifo = mknod(PIPE_LOC, S_IFIFO|0666, 0);
fp = fopen(PIPE_LOC, "w");
fifo is an int that isn't used anywhere else and fp is a FILE* to the pipe. Some debugging that I have done shows that fifo has a value of -1 after mknod runs, likely because of the compiler not seeming to be able to find the implementation of the function.
How do I make it so that GCC knows where to find the implementation of mknod?
As you can see that for declaration of mknod() function to stay after preprocessing stage, one of three macros (__USE_MISC, __USE_BSD, __USE_XOPEN_EXTENDED) should be defined. Otherwise, declaration of mknod() will be removed during preprocessing stage.
#if defined __USE_MISC || defined __USE_BSD || defined __USE_XOPEN_EXTENDED
extern int mknod (const char *__path, __mode_t __mode, __dev_t __dev)
__THROW __nonnull ((1));
You can use compiler options: -std=gnu99 -D_GNU_SOURCE or you can define these macros on your own and place them above header file inclusion.
I think you're missing a definition of some feature test macro required for the respective headers to define mknod. According to the Linux Programmer's Manual for the function (man 2 mknod) the macros for glibc are:
mknod():
_XOPEN_SOURCE >= 500
|| /* Since glibc 2.19: */ _DEFAULT_SOURCE
|| /* Glibc versions <= 2.19: */ _BSD_SOURCE || _SVID_SOURCE
Try adding -D_XOPEN_SOURCE=500 to your compile flags to see if that helps.
Some lines of my flex file:
%{
#include <stdlib.h>
#include <string.h>
#include "types.h"
#define NO_YY_UNPUT
/* #define YY_NEVER_INTERACTIVE */
extern char *strdup(const char *);
short unsigned int yylineno = 1;
%}
{ID} {
yylval.txt = strdup(yytext);
return ID;
};
\n { ++yylineno; }
My code looks good but I have problem when i want to compile on Ubuntu. In windows everything is okay but on linux I have errors like:
lex.l:10:14: error: expected identifier or ‘(’ before ‘__extension__’
lex.l:12:20: error: conflicting types for ‘yylineno’
lex.c:355:5: note: previous definition of ‘yylineno’ was here
Line 10: extern char *strdup(const char *);
Line 12: short unsigned int yylineno = 1;
strdup is declared in string.h, but it is a Posix interface and you should define an appropriate feature test macro before including any system header:
%top {
#define _POSIX_C_SOURCE 200809L
#include <stdlib.h>
#include <string.h>
#include "types.h"
}
(Note: Using %top forces the enclosed code to be inserted at the top of the generated C file, in order to provide the guarantee that the feature test macro is defined before any system header.)
I don't know if that works on Windows (and it certainly depends on your compiler and toolchain), so you might need to declare strdup on that platform. If so, make sure you surround the declaration with a preprocessor test for the build environment.)
The error at line 10 is probably the result of strdup being defined as a macro. I'm not sure under what conditions that will happen -- it will be some GNU extension mode -- but defining the Posix feature test macro should prevent it.
As for the error with the type of yylineno, there is a simple solution: don't declare yylineno. It is declared in the code flex generates (and it may be declared as a macro if you ask for a re-entrant -- "pure" -- lexer).
I started studying POSIX timers, so I started also doing some exercises, but I immediately had some problems with the compiler.
When compiling this code, I get some strange messages about macros like CLOCK_MONOTONIC. Those are defined in various libraries like time.h etc. but the compiler gives me errors as if they are not defined.
It is strange because I am using a Fedora 16, and some of my friends with Ubuntu get less compiler errors than I :-O
I am compiling with gcc -O0 -g3 -Wall -c -fmessage-length=0 -std=c99 -lrt
Here the errors I get:
struct sigevent sigeventStruct gives:
storage size of ‘sigeventStruct’ isn’t known
unused variable ‘sigeventStruct’ [-Wunused-variable]
Type 'sigevent' could not be resolved
unknown type name ‘sigevent’
sigeventStruct.sigev_notify = SIGEV_SIGNAL gives:
‘SIGEV_SIGNAL’ undeclared (first use in this function)
request for member ‘sigev_notify’ in something not a structure or union
Field 'sigev_notify' could not be resolved
if(timer_create(CLOCK_MONOTONIC, sigeventStruct, numero1) == -1) gives:
implicit declaration of function ‘timer_create’ [-Wimplicit-function- declaration]
‘CLOCK_MONOTONIC’ undeclared (first use in this function)
Symbol 'CLOCK_MONOTONIC' could not be resolved
Here is the code:
#include <stdio.h>
#include <fcntl.h>
#include <time.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <signal.h>
int main()
{
timer_t numero1;
struct sigevent sigeventStruct;
sigeventStruct.sigev_notify = SIGEV_SIGNAL;
if(timer_create(CLOCK_MONOTONIC, sigeventStruct, numero1) == -1)
{
printf( "Errore: %s\n", strerror( errno ) );
}
return 0;
}
Firstly, you can compile your code with -std=gnu99 instead of -std=c99 if you want to have the identifiers SIGEV_SIGNAL, sigeventStruct, and CLOCK_MONOTONIC available.
As noted by #adwoodland these identifiers are declared when _POSIX_C_SOURCE is set to a value >= 199309L, which is the case with -std=gnu99. You can also use -D_POSIX_C_SOURCE=199309L -std=c99 or have the macro defined in source code.
Secondly, see the timer_create prototype, you have to pass pointers as the second and the third argument to the function:
timer_create(CLOCK_MONOTONIC, &sigeventStruct, &numero1)
^ ^
Also you have to include the standard header string.h for strerror function declaration.
If you are using -std=c99 you need to tell gcc you're still using recent versions of POSIX:
#define _POSIX_C_SOURCE 199309L
before any #include, or even with -D on the command line.
Other errors:
Missing #include <string.h>
You need a pointer for timer_create, i.e. &sigeventStruct instead of just sigeventStruct
The other answers suggest _POSIX_C_SOURCE as the enabling macro. That certainly works, but it doesn't necessarily enable everything that is in the Single Unix Specification (SUS). For that, you should set _XOPEN_SOURCE, which also automatically sets _POSIX_C_SOURCE. I have a header I call "posixver.h" which contains:
/*
** Include this file before including system headers. By default, with
** C99 support from the compiler, it requests POSIX 2001 support. With
** C89 support only, it requests POSIX 1997 support. Override the
** default behaviour by setting either _XOPEN_SOURCE or _POSIX_C_SOURCE.
*/
/* _XOPEN_SOURCE 700 is loosely equivalent to _POSIX_C_SOURCE 200809L */
/* _XOPEN_SOURCE 600 is loosely equivalent to _POSIX_C_SOURCE 200112L */
/* _XOPEN_SOURCE 500 is loosely equivalent to _POSIX_C_SOURCE 199506L */
#if !defined(_XOPEN_SOURCE) && !defined(_POSIX_C_SOURCE)
#if __STDC_VERSION__ >= 199901L
#define _XOPEN_SOURCE 600 /* SUS v3, POSIX 1003.1 2004 (POSIX 2001 + Corrigenda) */
#else
#define _XOPEN_SOURCE 500 /* SUS v2, POSIX 1003.1 1997 */
#endif /* __STDC_VERSION__ */
#endif /* !_XOPEN_SOURCE && !_POSIX_C_SOURCE */
It is tuned for the systems I work with which don't all recognize the 700 value. If you are working on a relatively modern Linux, I believe you can use 700. It's in a header so that I only have to change one file when I want to alter the rules.
Referring to the CLOCK_MONOTONIC not being defined problem:
As Caterpillar pointed out this is an eclipse bug, more precisely a CDT-Indexer bug with a workaround at eclipse bugs, comment 12
I solved a lot of problems with -std=gnu99 (without specifing any POSIX versions) but I am still having
CLOCK_MONOTONIC could not be resolved
Searching on internet I found some Eclipse bugreports with people complaining about this. Have to check better if is an Eclipse bug, because with
gcc -Wall -w -o Blala timer.c -std=gnu99 -lrt
it compiles
Consider the following C code:
#include <stdio.h>
#include <stdlib.h>
void fatal(const char* message){
/*
Prints a message and terminates the program.
Closes all open i/o streams before exiting.
*/
printf("%s\n", message);
fcloseall();
exit(EXIT_FAILURE);
}
I'm using clang 2.8 to compile: clang -Wall -std=gnu99 -o <executable> <source.c>
And get: implicit declaration of function 'fcloseall' is invalid in C99
Which is true, but i'm explicitly compiling to gnu99 [which should support fcloseall()], and not to c99.
Although the code runs, I don't like to have unresolved warnings when compiling.
How can i solve this?
Edit: corrected tipo.
To include non-standard extensions when you include standard headers you need to define the appropriate feature test macro. In this case _GNU_SOURCE should work.
#define _GNU_SOURCE
#include <stdio.h>
This is independent of -std=gnu99 which enables language extensions, not library extensions.
Here in the man page of fcloseall()
#define _GNU_SOURCE
#include <stdio.h>
You have to define macros _GNU_SOURCE is you snippet, along with stdio.h header. _GNU_SOURCE is a feature test macros which is used to create portable application.