If i compile the below program with std=c99, i get an error, but the program compiles fine without the c99 flag. Why?
#include <signal.h>
void x()
{
sigset_t dd;
}
int main(void)
{
x();
return 0;
}
jim#cola temp]$ gcc -std=c99 blah.c -o blah
blah.c: In function ‘x’:
blah.c:9: error: ‘sigset_t’ undeclared (first use in this function)
blah.c:9: error: (Each undeclared identifier is reported only once
blah.c:9: error: for each function it appears in.)
blah.c:9: error: expected ‘;’ before ‘dd’
Because sigset_t is not part of <signal.h> in standard C and you requested strict standards compatibility with -std=c99. That is, a strictly standard C program can do:
#include <signal.h>
int sigset_t;
int main(void) { return 0; }
and expect it to work.
sigset_t is not in C99 standard, but it is available in POSIX. You can define _POSIX_SOURCE or _POSIX_C_SOURCE to make sigset_t available.
Here is the definition:
#define _NSIG 64
#define _NSIG_BPW 32
#define _NSIG_WORDS (_NSIG / _NSIG_BPW)
typedef unsigned long old_sigset_t; /* at least 32 bits */
typedef struct {
unsigned long sig[_NSIG_WORDS];
} sigset_t;
Also see What does #define _POSIX_SOURCE mean?
Related
I am doing simple sigaction example to practice C, but when I try to compile my code, it claims that struct sigaction doesn't exist [1].
When I checked out some old code I had produced I saw that I had added some POSIX string at the very top of the file [2]. But when I read the manual for sigaction (man 2 sigaction) there is nothing about _POSIX_SOURCE in it, the closest being _POSIX_C_SOURCE which doesn't work. How and when do I know which POSIX is the be used? When I try simple code that others have suggested, which is without the _POSIX_SOURCE it doesn't work.
[1]
#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
void sa_handler(int signum)
{
printf("The signal has been replaced with this useless
string!\n");
exit(0);
}
int main(void)
{
struct sigaction sa = {.sa_handler = sa_handler};
int sigret = sigaction(SIGINT, &sa, NULL);
while(1);
return 0;
}
[2]
#define _POSIX_SOURCE
#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
void sa_handler(int signum)
{
printf("The signal has been replaced with this useless
string!\n");
exit(0);
}
int main(void)
{
struct sigaction sa = {.sa_handler = sa_handler};
int sigret = sigaction(SIGINT, &sa, NULL);
while(1);
return 0;
}
When I compile the first example the result are these error messages.
sigaction.c: In function ‘main’:
sigaction.c:13:12: error: variable ‘sa’ has initializer but
incomplete type
struct sigaction sa = {.sa_handler = sa_handler};
^~~~~~~~~
sigaction.c:13:29: error: ‘struct sigaction’ has no member named
‘sa_handler’
struct sigaction sa = {.sa_handler = sa_handler};
^~~~~~~~~~
sigaction.c:13:42: warning: excess elements in struct initializer
struct sigaction sa = {.sa_handler = sa_handler};
^~~~~~~~~~
sigaction.c:13:42: note: (near initialization for ‘sa’)
sigaction.c:13:22: error: storage size of ‘sa’ isn’t known
struct sigaction sa = {.sa_handler = sa_handler};
^~
sigaction.c:14:18: warning: implicit declaration of function
‘sigaction’ [-Wimplicit-function-declaration]
int sigret = sigaction(SIGINT, &sa, NULL);
^~~~~~~~~
when I read the manual for sigaction (man 2 sigaction) there is nothing about _POSIX_SOURCE in it
From man sigaction:L
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
From future_test_macros(7):
_POSIX_SOURCE
Defining this obsolete macro with any value is equivalent to
defining _POSIX_C_SOURCE with the value 1.
Since this macro is obsolete, its usage is generally not doc‐
umented when discussing feature test macro requirements in
the man pages.
So _POSIX_SOURCE is equivalent to _POSIX_C_SOURCE 1 and is obsolete.
How and when do I know which POSIX is the be used?
From man future_test_macros:
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 [....]
So you should check SYNOPSIS section in the manual page of the function/feature you are interested in. For example for man sigaction:
sigaction(): _POSIX_C_SOURCE
siginfo_t: _POSIX_C_SOURCE >= 199309L
So you need to define _POSIX_C_SOURCE for sigaction() and _POSIX_C_SOURCE greater or equal to the value of 199309 for siginfo_t.
You need to define a positive integer for _POSIX_C_SOURCE. For sigaction, it needs to be atleast:
#define _POSIX_C_SOURCE 199309L
Look the the documentation for which POSIX version to use.
You need to add <features.h> before <signals.>, as the features.h contains #define _POST_C_SOURCE with latest value for compatibility purpose.
So the function getdate_r seems to be undefined for me; compiling the following doesn't work in either gcc or clang, (the man page program also doesn't work)
#include <time.h>
int main() {
char timeString[] = "2015/01/01 10:30:50";
struct tm res = {0};
int err = getdate_r(timeString, &res);
return err;
}
clang reports the following
test.c:6:12: warning: implicit declaration of function 'getdate_r' is invalid
in C99 [-Wimplicit-function-declaration]
int err = getdate_r(timeString, &res);
^
1 warning generated.
Other functions from time.h such as getdate, strptime also don't work in a similar manner.
Anyone have an explanation on whats going on?
clang version information
Ubuntu clang version 3.6.0-2ubuntu1 (tags/RELEASE_360/final) (based on LLVM 3.6.0)
Target: x86_64-pc-linux-gnu
Thread model: posix
To make getdate_r available you need to:
#define _GNU_SOURCE 1
before including any include files. Doing so will provide declarations for various GNU extensions including getdate_r:
#define _GNU_SOURCE 1
#include <time.h>
int main(void) {
char timeString[] = "2015/01/01 10:30:50";
struct tm res = {0};
int err = getdate_r(timeString, &res);
return err;
}
I tried to play with the file module of the Eina library and the classical system calls.
My problem is when I want to use eina and some functions and constants from ftw.h.
Here is the first simple code:
#define _XOPEN_SOURCE 500 /*Get nftw() and S_IFSOCK declarations*/
#include <ftw.h>
#include <stdio.h>
#include <stdlib.h>
#include <Eina.h>
/*Compile with
gcc -o eina_ftw eina_ftw.c $(pkg-config --libs --cflags eina)
*/
int main(int argc, char **argv)
{
int a = FTW_DNR;
int b=0;
b = FTW_MOUNT;
printf("ok\n");
exit(EXIT_SUCCESS);
}
When I compile it I have those errors:
In file included from /usr/include/eina-1/eina/eina_lock.h:50:0,
from /usr/include/eina-1/Eina.h:259,
from eina_ftw.c:5:
/usr/include/eina-1/eina/eina_inline_lock_posix.x:57:1: erreur: unknown type name thread_spinlock_t’
typedef pthread_spinlock_t Eina_Spinlock;
^
/usr/include/eina-1/eina/eina_inline_lock_posix.x:561:4: erreur: unknown type name ‘pthread_barrier_t’
pthread_barrier_t barrier;
^
Ok so I tried this:
#include <Eina.h>
#define _XOPEN_SOURCE 500 /*Get nftw() and S_IFSOCK declarations*/
#include <ftw.h>
#include <stdio.h>
#include <stdlib.h>
/*Compile with
gcc -o eina_ftw eina_ftw.c $(pkg-config --libs --cflags eina)
*/
int main(int argc, char **argv)
{
int a = FTW_DNR;
int b=0;
b = FTW_MOUNT;
printf("ok\n");
exit(EXIT_SUCCESS);
}
And now I have this kind of error:
eina_ftw.c: In function ‘main’:
eina_ftw.c:13:7: erreur: ‘FTW_MOUNT’ undeclared (first use in this function)
b = FTW_MOUNT;
^
eina_ftw.c:13:7: note: each undeclared identifier is reported only once for each function it appears in
So I would like to know if there is a way to solve this problem?
Setting _XOPEN_SOURCE 500 is (approximately equivalent to) asking for the 1995 POSIX declarations.
Set it to at least 600 (for POSIX 2001) or perhaps 700 (for POSIX 2008).
Strictly, of course, setting _XOPEN_SOURCE is asking for a particular version of the Open Group (originally X/Open) Single Unix Specification, but there is a strong relationship between the POSIX standard and the Open Group standard. You can find out more at:
The Open Group Base Specifications Issue 7, IEEE Std 1003.1™, 2013 Edition
The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition
Single UNIX® Specification, Version 2, 1997
// screen.h
#ifndef screen_h
#define screen_h
#define MAC 1
#define WIN 2
#define LNX 3
#ifdef PLATFORM
# undef PLATFORM
#endif
#define PLATFORM MAC
void screen_init();
#endif
// screen.c
#include <string.h>
#include <stdlib.h>
#include "screen.h"
#if PLATFORM == MAC
#include <curses.h>
void screen_init(){
erase();
}
#endif
I don't understand why it is not seeing my prototype in screen.h
Any suggestions/hints are appreciated!
ISO/IEC 9899:TC2 - 6.2.1.2:
A function prototype is a declaration of a function that declares the types of its parameters.
An empty argument list in a function declaration indicates that the number and type of parameters is not known. You must explicitly indicate that the function takes no arguments by using the void keyword. Otherwise your function declaration does not count as a valid prototype.
void screen_init(void);
I met this similar error minutes ago. After i'd added the relatived function declaration in head file, error's gone.
Also, some said that canceling the compile option '-Wmissing-prototypes' should work, but i didn't have tried that. Good luck.
I just had this problem today.
I defined a function that just used internally
void func(void) {
}
int main(void) {
func();
}
This will give me that warning.
I had to add the prototype at the beginning of the file to get rid of the warning.
void func(void);
void func(void) {
}
int main(void) {
func();
}
I have a script that compiles fine on Linux (Ubuntu 11.04), but not on OS X (Lion).
gcc -pthread -o hw1 hw1.c
hw1.c:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘barr’
hw1.c: In function ‘__syncthreads’:
hw1.c:53: error: ‘barr’ undeclared (first use in this function)
hw1.c:53: error: (Each undeclared identifier is reported only once
hw1.c:53: error: for each function it appears in.)
hw1.c:54: error: ‘PTHREAD_BARRIER_SERIAL_THREAD’ undeclared (first use in this function)
hw1.c: In function ‘parallel_psum’:
hw1.c:94: error: ‘barr’ undeclared (first use in this function)
hw1.c:107: warning: assignment from incompatible pointer type
Here's the first 22 lines of the code:
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <math.h>
#include <sys/time.h>
#include <pthread.h>
#include <assert.h>
/* create thread argument struct for thr_func() */
typedef struct _thread_data_t {
int tid;
int* ints;
int* sums;
int num_ints;
int* temp;
} thread_data_t;
const int MIN_RAND_INT = 1;
const int MAX_RAND_INT = 65000;
// pthreads barrier variable
pthread_barrier_t barr;
Any ideas why this is happening?
According to info about pthread_barriers on opengroup.org, barriers are defined in the optional part of POSIX standard; the name of option is "(ADVANCED REALTIME THREADS)", sometimes more exact referred as "BAR, barriers (real-time)".
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html
The system may support one or more options (see Options) denoted by the following symbolic constants:
_POSIX_BARRIERS
So, only if the _POSIX_BARRIERS macro is defined as positive number, you can use pthread_barrier_t or pthread_barrier_wait.
Mac OS X is POSIX Compliant, but full list of implemented options is not available online. There is a letter in apple mainling list from 2006, which says there is no barriers in Mac OS X.
I know that Solaris had some problems with pthread_barrier too.
Just like osgx mentioned, barriers are not implemented on OS X, but you can always implement it or just use this implementation. Quick note on the previous implementation, you can use the macro that osgx mentioned, _POSIX_BARRIERS, instead of the ones on the blog, like this #if !defined _POSIX_BARRIERS || _POSIX_BARRIERS < 0