I'd line to use pthread_setname_np function if it's available. Code from the manpage:
#define _GNU_SOURCE /* See feature_test_macros(7) */
#include <pthread.h>
int pthread_setname_np(pthread_t thread, const char *name);
int pthread_getname_np(pthread_t thread,
char *name, size_t len);
Is it safe to just do like that (no includes, no defines):
#ifdef _GNU_SOURCE
pthread_setname_np(pthread_self(), "mythread");
#endif
Includes are not needed because the C++ #include <thread> that I use seems to pull pthreads. The _GNU_SOURCE is always enabled in libstdc++, and if it gets disabled - the code will still compile.
Am I missing something?
Is it safe to just do like that (no includes, no defines):
Yes. It's safe as long as you include <pthread.h> which provides the prototype for pthread_setname_np.
Includes are not needed because the C++ #include that I use seems to pull pthreads.
libc++ uses pthreads library underneath. So, it works with pthread.h. But that doesn't mean pthread.h isn't needed if you include <thread>. What if libc++ changes the underlying mechanism to implement threads? So, it's not safe to by pass pthread.h just because it happens to be available by other means.
Related
I'm fairly new to C but writing a small multithreaded application. I want to introduce a delay to a thread. I'd been using 'usleep' and the behavior is what I desire - but it generates warnings in C99.
implicit declaration of function ‘usleep’
It's only a warning, but it bothers me. I've Googled for an answer but all I could find was a while-loop / timer approach that seemed like it would be CPU intensive.
EDIT:
My includes are:
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
#include <time.h>
And I'm invoking the compiler with:
c99 program.c -Wall -pedantic -W -lpthread
EDIT #2:
I've created a new file that contains:
#include <unistd.h>
int main(void) {
usleep(10);
}
And I still get the warning.
EDIT #3:
As suggested, I've updated the text of the question.
The problem is that you are using a standard C99 compiler, but you're trying to access POSIX extensions. To expose the POSIX extensions you should for example define _POSIX_C_SOURCE to 200809L (for the current standard). For example this program:
#include <time.h>
int main(void) {
struct timespec reqtime;
reqtime.tv_sec = 1;
reqtime.tv_nsec = 500000000;
nanosleep(&reqtime, NULL);
}
will compile correctly and wait for 1.5 seconds (1 second + 500000000 nanoseconds) with the following compilation command:
c99 main.c -D _POSIX_C_SOURCE=200809L
The _POSIX_C_SOURCE macro must be defined with an appropriate value for the POSIX extensions to be available.
Also the options -Wall, -pedantic and -W are not defined for the POSIX c99 command, those look more like gcc commands to me (if they work on your system then that's fine, just be aware that they are not portable to other POSIX systems).
You are probably on a modern POSIX system:
POSIX.1-2008 removes the specification of usleep().
On my system (linux) there is a detailed explanation of the macros that must be set to get that function back. But you should just follow the advice that zvrba already gave, use nanosleep instead.
From the manual page: This function is obsolete. Use nanosleep instead.
implicit declaration of function ‘usleep’
This warning usually means that you didn't #include the right header file, in this case unistd.h.
Did you have the #include <unistd.h> ?.
And you can use some of the similar methods instead: nanosleep() for nanoseconds and sleep() for seconds. Or another way could be using clock(), but i think this is more CPU wasting.
I'm writing the header of a kernel module. The header is known to the module, but also used by callers in user space. This is a problem, because some types used should be included from different files depending on whether the header is currently in user or kernel space (or so this question makes me think).
I don't want to maintain two separate header files, so I've been thinking of a solution like this:
#ifndef IN_KERNEL
#include <stdint.h>
#else
#include <linux/types.h>
With IN_KERNEL being defined somewhere in my kernel code. Is there a preprocessor constant that already does this?
From reading this, it seems that an existing constant used for this purpose is __KERNEL__.
#ifndef __KERNEL__
#include <stdint.h>
#else
#include <linux/types.h>
#endif
I want to write a portable way to get the free disk space. On Windows, I use GetDiskFreeSpaceEx, and on Linux, the header <sys/statvfs.h> contains the function statvfs64() I can use.
My question is, on which systems I can assume that this header exists. Is there a macro I can check? Something like
#ifdef _MSC_VER
#include <windows.h>
#else
#ifdef STATVFS_IS_AVAILABLE
#include <sys/statvfs.h>
#endif
#endif
Generally, you would use autotools for stuff like that. autoconf creates a config.h header which defines a HAVE_STATVFS or so macro if you define a suitable configuration test.
However, due to the otherwise huge availability of <sys/statvfs.h>, you can also less portably simply test for _MSC_VER, as you just did.
I have a header foo.h file that declares a function prototype
void foo(FILE *f);
/* ... Other things that don't depend on FILE ... */
among other things.
Now obviously, to use this header, I need to do the following
#include <stdio.h>
#include "foo.h"
I would like to surround this particular prototype with something like the following:
#ifdef _STDIO_H
void foo(FILE *f);
#endif
/* ... Other things that don't depend on FILE ... */
so that I can #include "foo.h" without worrying about #include <stdio.h> in cases where I don't need that particular function.
Is the #ifdef _STDIO_H the way to go if I want my code to be portable and standards compliant?
I could find no mention of _STDIO_H in the standards document, but I see it is used in a variety of C libraries. Should I rather use something that I know to be defined in stdio.h, like EOF?
A related question: What do you do for other standard C headers, like stdlib.h?
<stdio.h> and <stdlib.h> are part of the C99 (and C11) standards. So every (hosted) standard conforming C implementation have them.
On most practical implementations, they are header files with some include guards.
A standard conforming implementation might process #include <stdio.h> very specifically, e.g. by using some database. I know no such implementation.
So simply add
#include <stdio.h>
near the top of your header file, something like
// file foo.h
#ifndef FOO_INCLUDED
#define FOO_INCLUDED
#include <stdio.h>
// other includes ...
// ...
// other stuff
#endif /* FOO_INCLUDED */
Alternatively, you could not care and document that #include "foo.h" requires a previous #include <stdio.h>; any sensible developer using a good-enough C implementation would be able to take care of that.
Actually, I was wrong in my comment on Alter Mann's deleted answer. It looks like stdin is required to be some macro, and then you might use #ifdef stdin ... endif as Alter Mann correctly answered. I believe it is not very readable, and you just want to have <stdio.h> included, either by including it yourself in your foo.h or by requiring it in your documentation.
Contrarily to C++ standard headers, C standard headers are in practice quite quick to be compiled, so I don't think it is worth to optimize the unusual case when <stdio.h> has not been included.
Open your stdio.h file (for your compiler) and see whether it has _STDIO_H or similar definition.
I'm fairly new to C but writing a small multithreaded application. I want to introduce a delay to a thread. I'd been using 'usleep' and the behavior is what I desire - but it generates warnings in C99.
implicit declaration of function ‘usleep’
It's only a warning, but it bothers me. I've Googled for an answer but all I could find was a while-loop / timer approach that seemed like it would be CPU intensive.
EDIT:
My includes are:
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
#include <time.h>
And I'm invoking the compiler with:
c99 program.c -Wall -pedantic -W -lpthread
EDIT #2:
I've created a new file that contains:
#include <unistd.h>
int main(void) {
usleep(10);
}
And I still get the warning.
EDIT #3:
As suggested, I've updated the text of the question.
The problem is that you are using a standard C99 compiler, but you're trying to access POSIX extensions. To expose the POSIX extensions you should for example define _POSIX_C_SOURCE to 200809L (for the current standard). For example this program:
#include <time.h>
int main(void) {
struct timespec reqtime;
reqtime.tv_sec = 1;
reqtime.tv_nsec = 500000000;
nanosleep(&reqtime, NULL);
}
will compile correctly and wait for 1.5 seconds (1 second + 500000000 nanoseconds) with the following compilation command:
c99 main.c -D _POSIX_C_SOURCE=200809L
The _POSIX_C_SOURCE macro must be defined with an appropriate value for the POSIX extensions to be available.
Also the options -Wall, -pedantic and -W are not defined for the POSIX c99 command, those look more like gcc commands to me (if they work on your system then that's fine, just be aware that they are not portable to other POSIX systems).
You are probably on a modern POSIX system:
POSIX.1-2008 removes the specification of usleep().
On my system (linux) there is a detailed explanation of the macros that must be set to get that function back. But you should just follow the advice that zvrba already gave, use nanosleep instead.
From the manual page: This function is obsolete. Use nanosleep instead.
implicit declaration of function ‘usleep’
This warning usually means that you didn't #include the right header file, in this case unistd.h.
Did you have the #include <unistd.h> ?.
And you can use some of the similar methods instead: nanosleep() for nanoseconds and sleep() for seconds. Or another way could be using clock(), but i think this is more CPU wasting.