I am trying to setup a c11 thread example in xcode... but it doesn't seem to have the threads.h header, though it isn't complaning about the macro described here:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
__STDC_NO_THREADS__The integer constant 1, intended to indicate that the implementation does not support the <threads.h> header.
Looks like almost nothing supports the threads feature in C11... maybe I will try to get it into clang...
With the clang on my machine (v. 3.2 on ubuntu/linux) that feature test macro isn't defined. Support for that feature will need support in the C library, that usually doesn't come with the compiler. So basically the answer for clang will not be much different than for gcc, they usually build upon the same C library, namely glibc, see here for answer for gcc.
Just in case anyone is looking this up in 2021+, Apple still doesn't support this, and likely never will. As others have stated, pthreads is by far the best bet. Note that widely, C11 threads are not supported. I would go as far as to say pthreads is more portable in most circumstances.
From a development perspective, C11 threads are much too limited, and obfuscate user space vs. kernel space implementation features, along with implementation attributes.
If you really need C11 threads I would recommend doing one of three things.
Don't.
Use a cross-platform library: https://github.com/tinycthread/tinycthread seems to do a good job.
Write your own polyfill. The library I just mentioned tries to support a bunch of platforms (though it's inactive now), but anyone with a little bit of experience with pthreads and win32 threads will have no trouble (but, maybe a headache) writing a polyfill. I actually did this the other day out of interest, and it took just a few hundred lines, not too bad. For any project that will use it alot, this will give more control over usage.
The good thing to note is some other C11 features are supported on OSX, like C11 Atomics, which complementing would be impossible without a lot of ASM knowledge.
it doesn't seem to have the threads.h header, though it isn't complaining
C11 has 2 specs about __STDC_NO_THREADS__
7.26 Threads
Implementations that define the macro __STDC_NO_THREADS__ need not provide
this header nor support any of its facilities. C11 N1570 §7.26.1 2
__STDC_NO_THREADS__ The integer constant 1, intended to indicate that the
implementation does not support the <threads.h> header. C11 N1570 §6.10.8.3 1
Per §7.26.1 2:
#ifdef __STDC_NO_THREADS__
#error "No threading support"
#else
#include <threads.h>
#endif
Per §6.10.8.3:
#if defined(__STDC_NO_THREADS) && __STDC_NO_THREADS__ == 1
#error "No threading support"
#else
#include <threads.h>
#endif
// Certainly this can be simplified to
#if defined(__STDC_NO_THREADS) && __STDC_NO_THREADS__
or per What is the value of an undefined constant used in #if? to
#if __STDC_NO_THREADS__
This matches OP's code, so I would have expected that to work with a compliant C11 compiler.
Yet it looks like OP has a solution per #Kevin. That may be a false solution as __STDC_NO_THREADS looks like a typo (missing trailing __).
#if !defined(__STDC_NO_THREADS) || __STDC_NO_THREADS__
In C++11, you want to #include <thread>, not threads.h
#include <iostream>
#include <thread>
void fun() { std::cout << "fun!" << std::endl; }
int main() {
std::thread t ( fun );
t.join ();
return 0;
}
Related
(split this off from this question)
The following 3 macros appear in many C source files which try to detect/rely on the availability of POSIX functionality:
_POSIX_SOURCE
_POSIX_C_SOURCE
_POSIX_ (and _POSIX ?)
In the linked-to question it's explained that we're supposed to set _POSIX_C_SOURCE to the POSIX version on which we want to rely (although setting it doesn't guarantee that the functionality will actually be available - that's up to the compiler/OS). Also, while I can set it as the user, it's not clear when others set it themselves (e.g. the compiler / build system). For the other two, I know neither when I should set them nor when others set them.
So, what is the difference in meaning between the three macros? When would each of them be set for me? And why/when should I choose to set one of them over the others, if at all?
Very partial answer (and with thanks to #SomeProgrammerDude):
The POSIX reference tells us that:
The POSIX.1-1990 standard specified a macro called _POSIX_SOURCE. This has been superseded by _POSIX_C_SOURCE.
and in practical terms, the GNU C library manual tells us, for example:
The state of _POSIX_SOURCE is irrelevant if you define the macro _POSIX_C_SOURCE to a positive integer.
and it should probably be the same for other C standard library implementations. So - never use _POSIX_SOURCE yourself, only use _POSIX_C_SOURCE (except if you are on old platforms where the OS and libraries have not seen updates for the past 20 years at least).
_POSIX_ and _POSIX is a Microsoft-Visual-C(++)-specific macro. I am guessing you define it to get MSVC to expose POSIX/POSIX-like functionality. According to this non-authoritative thread on the MinGW mailing list, MSVC no longer uses _POSIX_ (and _POSIX?) as of MSVC2013.
Since a quick Google search did not find anything, I will try to ask here (since many people involved in gcc/clang hang around here) - What is the status of __STDC_LIB_EXT1__ in gcc/clang? We are developing a cross platform applicataion and I wanted to use some of the safe bounds checking functions from <stdio.h> (which by miracle are available on Visual Studio 2017), but could not compile the code with Xcode 9.2. I assumed maybe the clang version Xcode uses is outdated, but gcc 6.3.0 on Ubuntu behaves the same. I am trying to use tmpnam_s with the following sample:
#if defined(__STDC_LIB_EXT1__)
#define __STDC_WANT_LIB_EXT1__ 1
#include <stdio.h>
#else
#error "__STDC_LIB_EXT1__ not defined"
#endif
int main(int argc, char** argv)
{
char t[L_tmpnam_s];
tmpnam_s(t, L_tmpnam_s);
return 0;
}
But the compilation fails with the macro not being defined:
gcc -std=c11 test.c
test.c:5:2: error: #error "__STDC_LIB_EXT1__ not defined"
#error "__STDC_LIB_EXT1__ not defined"
^~~~~
Am I doing something wrong or this function set is simply poorly supported?
The whole set of 'safe' functions with the _s suffixes is poorly supported. Microsoft wrote a set of functions with the _s suffixes and submitted that to the C standard committee to be standardized. The committee made some changes (arguably out of necessity), and created a technical report, TR 24731-1. A mildly modified version of the TR was included as optional Annex K (normative) in the C11 standard, ISO/IEC 9899:2011.
You can find many sordid details in the answers to Do you use the TR-24731 "safer" functions?, especially in the notes in my answer to that question, and especially the link to the Standard C committee document N1967 Field Experience with Annex K — Bounds Checking Interfaces.
I don't know what the current status of the N1967 proposal is, but that it was suggested is telling. N1967 also contains links to libraries that support Annex K / TR-24731-1 — the list is limited.
Note that Microsoft does not implement the library specified by the C11 standard. It implements an approximation to the standard, but there are crucial differences. This would matter more if any other system had implemented the standard — but the functions have not been implemented in any widely accepted form (so, for example, the GNU C Library does not and will not support them).
Is there any way to access thread.h file .
I am not able to find thread.h header in windows since threading is related to OS.
I tried using pthread.h an external library , but was never able to find thread.h which according to my professor works in solaris.
This is an excellent example where tagging a question with "C" and "C++" is highly confusing because the answers are entirely different.
If you are coding in C++11 or later, then you should
#include <thread>
and use the std::thread class. You'll be fine.
If you are coding in C11 or later, then you should
#include <threads.h>
However, you may have to wait until your implementation supports it. § 7.26.1 ¶ 2 of the C11 standard says:
Implementations that define the macro __STDC_NO_THREADS__ need not provide this header nor support any of its facilities.
You can check with an #ifdef whether your implementation defines it. At least my GCC does.
For the time being, if you cannot switch to C++, use a third-party threading library like pthreads.
thread.h isn't well defined in the context of c++ standards. If you have a c++11 compliant toolchain, you need to
#include <thread>
as stated in the reference documentation.
Pre standard toolchains probably need to have the standard specified explicitly using the -std=c++0x or -std=c++11 compiler flags.
As you changed your focus to c, including c++ headers won't work. You may try pthread.h.
I got this book "Beginning C" by Ivor Horton and I'm half way through it and I like it; so far so good. I use Code::Blocks on Windows as my IDE, and now I've run into the problem I cannot solve for about 3 days now.
The author mentions some "optional" functions in <string.h>, like strnlen_s(), and also says that these are available in the new standard — C11 (the book is from 2013; I don't know how new C11 actually is), and he also gives a piece of code that will determine "whether the standard library that comes with your C compiler supports these optional functions".
This is the code:
#include <stdio.h>
int main(void)
{
#if defined __STDC_LIB_EXT1__
printf("Optional functions are defined.\n");
#else
printf("Optional functions are not defined.\n");
#endif
return 0;
}
So I run the code to check if GCC in Code::Blocks does and determine that it doesn't. The book didn't recommend the compiler nor the IDE; I picked up Code::Blocks with GCC on my own, since that's what I do my exams in at college, so I figured I should get familiar with the environment.
The thing is, I have no idea how to "fix" this, since strnlen() doesn't work, strnlen_s() doesn't work, and bunch of others, and I can't really continue through a book. Not that I need them, or that I can't do it any other way (strlen() works just fine) but it would be nice to know how to use non-standard functions.
Up to date versions of GCC certainly do support C11, you need to enable it with the compiler flag -std=c11.
I presume you're using some flavour of MinGW with Code::Blocks - I recommend using MinGW-W64 as it is actively maintained and very up to date.
Also, bundled toolchains of MinGW-W64's gcc are available at TDM-GCC.
The Code::Blocks IDE itself doesn't care which version of C you're using, that doesn't affect what libraries you have available.
You are speaking of the optional Annex K Microsoft pushed through.
K.2 Scope
1 This annex specifies a series of optional extensions that can be useful in the mitigation of
security vulnerabilities in programs, and comprise new functions, macros, and types
declared or defined in existing standard headers.
2 An implementation that defines __STDC_LIB_EXT1__ shall conform to the
specifications in this annex.380)
3 Subclause K.3 should be read as if it were merged into the parallel structure of named
subclauses of clause 7.
It is generally seen as deeply flawed, and Microsoft trying to force it's use as a severe nuisance.
That's especially the case as they are the only major player implementing them, and their versions are non-conformant.
glibc with gcc for example provide most supposed advantages of that annex without introducing new functions, discouraging use of half the standard-library and forcing such a cumbersome API on programmers.
You might want to read the C tag-wiki, and especially grab a draft of the C11 standard (which is from 2011, as the name should imply).
The optional Annex K from the C11 Standard is not widely adopted yet (see Deduplicator's comment below). For instance as of February 2015 it hasn't been merged into glibc.
The good news is that you might try an alternative compiler. For instance Pelles C for Windows is a modified LCC with enhanced support for newest C11 features (like atomics and C11 threads model, that I believe are also mentioned in your book). Here is some basic program, that compiles and runs in it:
#include <stdio.h>
#include <string.h>
int main(void)
{
#if defined __STDC_LIB_EXT1__
printf("Optional functions are defined.\n");
#else
printf("Optional functions are not defined.\n");
#endif
char *str = "Hello Annex K";
printf("%zu\n", strnlen_s(str, 5));
return 0;
}
Output is:
Optional functions are defined.
5
Press any key to continue...
I was looking at the man page of sigaction, and I ended up looking at the following line.
sigaction(): _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE
What do _POSIX_X_SOURCE, _X_OPEN_SOURCE, _POSIX_SOURCE mean? What to do with it?
These are feature test macros. Their purpose is to allow your program to inform the system header files which standards you want it to attempt to conform to, and what extensions you want available.
Without any feature test macros defined, implementations vary a lot in what macros, functions, and type definitions they make visible in their headers. A common practice is to make everything visible by default, which is a problem because "everything" is not very specific, and it's very possible that symbol names used in your program might clash with some of the extensions. Even if they don't clash now, there's no way to know if they will in the future. So the standards (like ISO C and POSIX) put strict requirements on the implementation that it not pollute the applications namespace with names not explicitly defined or reserved in the standards. When you use a feature test macro to request a particular standard, you're asking the implementation to ensure that (1) it provides everything defined in this standard, (2) it doesn't pollute your application's namespace by providing anything not defined in that standard.
A correct program should always explicitly use the right feature test macros for the standard(s) it's written to. The easiest way to do this is putting the right -D argument on the compiler command line (CFLAGS). Adding the #define as the first line in each source file also works. Be aware if you do it in source files though:
The feature test macros must be defined at the top before any system header is included.
It's usually a bad idea to use different feature test macros in different translation units.
As an aside, it's not exactly the same as the other feature test macros, but all modern programs should define _FILE_OFFSET_BITS=64 when built on Linux/glibc to request that off_t be 64-bit for large file support.
Here is a man for Feature macros: http://www.kernel.org/doc/man-pages/online/pages/man7/feature_test_macros.7.html
They will turn on or off some level of standard support in the headers.
E.g. _POSIX_C_SOURCE >= 1 means that POSIX.2-1992 or later should be supported; _X_OPEN_SOURCE means POSIX.1, POSIX.2, and XPG4 are enabled; and for greater values of macro (>=500; >=600; >=700) it will also turn on some variants of SUSv2 v3 or v4 (UNIX 98; 03 or POSIX.1-2008+XSI). And _POSIX_SOURCE is an obsolete way to define _POSIX_C_SOURCE = 1
They're the things you have to #define to get the prototype, and are known as feature test macros.
For example, the following code will susscessfully define the prototype for sigaction:
#define _XOPEN_SOURCE
#include <signal.h>
Including signal.h without that #define (or the others) will not define the prototype.
It is a Feature test macro.
Symbols called "feature test macros" are used to control the visibility of symbols that might be included in a header. Implementations, future versions of IEEE Std 1003.1-2001, and other standards may define additional feature test macros.