When using dprintf() I'm getting the warning "implicit declaration of dprintf". That tends to mean a necessary file isn't included, but I already included stdio.h, which is supposed to be all that it needs. Is there something else dprintf needs?
The "feature_test_macros" section of the man page explains that to make stdio.h declare dprintf(), you must first #define _POSIX_C_SOURCE 200809L (or higher) before you #include <stdio.h>. The reason for this is that dprintf() was not standardized until POSIX.1-2008, but <stdio.h> needs to continue to work with code written before that, even if that code used its own identifier named "dprintf". (Defining _GNU_SOURCE or _XOPEN_SOURCE would also work on Linux, but _POSIX_C_SOURCE is the best choice for general portability.)
You might need to set some macros. Put on top of the file, before any includes the following
#define _POSIX_C_SOURCE 200809L
#define _GNU_SOURCE
(One of that would be enough but I don't know the GLibC version you use)
You can look up for fprintf() here.
I ran into the same problem and hence I was forced to run on POSIX based machine, I must changed my code, so fprintf() is one of (may be) many options I had.
example :
fprintf(stderr,"file not found");
Related
This question already has answers here:
GCC with -std=c99 complains about not knowing struct timespec
(3 answers)
Closed 2 years ago.
I am currently experiencing the error
Unknown type name 'ssize_t'
I had a look at Where is ssize_t defined in Linux?
but the error remained.
I added the
#include <sys/types.h>
My function is
ssize_t ss_size(sparse_set_ptr sparse_set)
{
return false;
}
What could be the cause of the problem and can it be fixed?
Also I am running C Executable Language Standard: C99
From `man ssize_t:
ssize_t
Include: <sys/types.h>. Alternatively, <aio.h>, <monetary.h>,
<mqueue.h>, <stdio.h>, <sys/msg.h>, <sys/socket.h>, <sys/uio.h>,
or <unistd.h>.
Try all these one by one, with one of them it should work.
Note that even if you include <sys/types.h>, the type might not be defined if you specify a strict C standard with GCC (-std=c99) rather than the GNU variant (-std=gnu99). In fact, you don't need to explicitly include <sys/types.h> with POSIX 2008 (2018) or the prior version, POSIX 2004; it is effectively included automatically.
If you're including <sys/types.h> and still see the problem, then you need to enable the POSIX extensions, probably with #define _XOPEN_SOURCE 700 — the number's easier to remember than #define _POSIX_C_SOURCE 200809L which is a valid alternative. Both these select POSIX 2008; there are other values for other versions of POSIX. There are a few subtle differences between X/Open and POSIX (X/Open might till specify a few things that POSIX does not), but they're minimal and seldom relevant. The #define must appear before any system header is included. It could be specified on the command line as -D_XOPEN_SOURCE=700.
You have to decide which standard you want to use: C99 or Posix.
If you want to use the type ssize_t, then you have to define (activate) that standard in your sources, see man feature_test_macros.
But beware, if you activate any standard, which enables the desired Posix standard, you're not pure C99 anymore.
I'm writing a header file in C and need stdlib.h for it to work. But, when I check if _STDLIB_H is defined, the pre-processor says it's not, even if I include the file. I have tried it on multiple compilers, where it works on most but not on tdm-gcc. How can I fix this?
Looking at stdlib.h source code, it seems like the macro to look for in tdm-gcc might be _TR1_STDLIB_H.
So you can try something like:
#if defined _STDLIB_H || defined _TR1_STDLIB_H
For a safer way to check if stdlib.h is properly included, you should check for a macro that the C standard requires the file to define.
I may be missing something, but I don't see any requirement in the C standard for stdlib.h to define _STDLIB_H. I think this may just be a common way compilers decided to guard against multiple inclusion.
try something like
#include <stdlib.h>
#ifndef NULL
#error "stdlib.h not included"
#endif
because the C standard requires that stdlib.h defines NULL
But none of this should be technically necessary... I don't know of a preprocessor that won't throw a fatal error if it can't find a file you tried to #include
EDIT:
According to the C standard stdio.h also defines NULL, so perhaps it would be better to check for EXIT_SUCCESS or EXIT_FAILURE
I'm looking for a way to insert an #undef to the lex generated source code that will appear before the built in lines lex generates.
When compiling a file.l with lex, I generate a lex.yy.c file. In my file.l I have written :
#include "y.tab.h"
#undef __STRICT_ANSI__
#include <string.h>
The #undef helps me compile the code under the flag -std=c99 So it needs to be done before including string.h. But the generated file includes string.h before copying my undef.
Without the #undef I am getting a lot of warnings due to the use of strdup. I have seen the normal fixes using flags, but like I said I can't access the makefile.
Adding 'manually' the line
#undef __STRICT_ANSI__
into lex.yy.c before fixes everything. But i prefer not to touch any of the generated code and have it done by lex.
I have read this,
strdup(): Confused about warnings ('implicit declaration', 'makes pointer...without a cast', memory leak)
And like i said it does solve it.
But only if I can somehow force the generated file to run the undef first.
To start with, #undef __STRICT_ASCII__ is not the correct way to enable the declaration of Posix functions like strdup.
Posix extensions which are declared in standard C library header files are made conditional on "feature test macros". You can read a summary in man feature_test_macros but in any case, the documentation for any function which requires a feature test macro includes a description of which macros are required. In the case of strdup, we can read in man strdup:
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
strdup():
_XOPEN_SOURCE >= 500
(Followed by more possibilities.)
Personally, I always use
#define _XOPEN_SOURCE 700
which requests declarations for all functions in the latest version of Posix.
One way to insert the feature test macro before any include of a standard library function is to do so on the compile command line:
-D_XOPEN_SOURCE=700
I like doing it this way, because I can add it to my Makefile and then it applies to every compilation (which is basically what I want). Usually, makefiles include a feature which allows you to add this option to your compiler flags without modifying the file. For example, the following will often work:
make file CPPFLAGS="-D_XOPEN_SOURCE=700"
(CPPFLAGS is a common makefile variable used to set preprocessor flags.)
But if you want to put it into your flex file, you can use a %top block:
%top {
#define _XOPEN_SOURCE 700
}
%top is like %{ but it puts the inserted code right at the beginning of the generated code.
If nothing else works, you can always just insert the declaration for strdup, (also taken from man strdup) into your flex prologue.
%{
char *strdup(const char *s);
#include "y.tab.h"
%}
Both the C standard and the Posix standard allow explicit declaration of library functions (but not macros) as an alternative to including relevant headers.
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
...
lstat(name, &st);
...
I am using CodeBlocks to write a C program. All the other includes work fine. I checked online and lstat requires the three includes listed at the top of the code, but I still get the error message warning: implicit declaration of function 'lstat' when I try to compile. I do not know what is wrong. If I need to include any extra information to get help, please say.
According to lstat(2):
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
lstat():
_BSD_SOURCE || _XOPEN_SOURCE >= 500 || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
|| /* Since glibc 2.10: */ _POSIX_C_SOURCE >= 200112L
This means you need to define one of these feature test macros to use lstat(2).
So choose one of those feature test macros that makes sense to your code, such as _BSD_SOURCE, and define it in the very beginning (before you include any header file) of your source file, or you could define it on the compiler command line, such as -D_BSD_SOURCE for gcc.
lstat() is not compliant with strict ANSI standard.You should use your compiler flags from
-std=c99 to -std=gnu99 . This would include all the Unix based system.
I'm trying to compile a C program but I get the error 'RTLD_NEXT' undeclared. I think this is supposed to be defined in dlfcn.h which the c program includes, but when I looked inside dlfcn.h there is no RTLD_NEXT.
How do I fix this?
The issue here is that RTLD_NEXT is not defined by the posix standard . So the GNU people don't enable it unless you #define _GNU_SOURCE or -D_GNU_SOURCE.
Other relevant pieces of POSIX are dlfcn.h and dlsym.h. Interestingly, the later mentions RTLD_NEXT. Apparently, the GNU people are a bit confused about what is an extension and what is not.
According to man dlsym it is #define _GNU_SOURCE (just one leading underscore) before the dlfcn.h is included. (RHEL6.1).
Try #define __GNU_SOURCE as first line in your sources.
There must be one underscore. #define _GNU_SOURCE
Further, this must be your first preprocessor directive.For example:
#define _GNU_SOURCE
#include <stdio.h>