VSCode claims pthread_rwlock_t is undefined due to an #ifdef in the pthreadtypes.h header file

[Managor]

Type: Intellisense

Describe the bug

• OS and Version: Ubuntu 19.04
• VS Code Version: 1.33.1
• C/C++ Extension Version: 0.22.1
• Other extensions you installed (and if the issue persists after disabling them): Python, PHP Intellisense, npm and ESLint which none of them should interfere with C
• A clear and concise description of what the bug is: Intellisense claims that pthread_rwlock_t is undefined. Probably due to the header file having #if defined __USE_UNIX98 || defined __USE_XOPEN2K in front of the of the typedef. It compiles just fine so it's definitely defined.

To Reproduce
Steps to reproduce the behavior:

1. Have the C/C++ intellisense enabled
2. Init a rwlock with pthread_rwlock_t lock = PTHREAD_RWLOCK_INITIALIZER;
3. The editor claims that it is not defined even if it runs through gcc compilation without an error

[sean-mcmanus]

Yeah, it's due to the those defines. Something on your build system must be causing them to be defined (i.e. a -D in your gcc command line). We currently query the compiler for defines, but your build system might add additional flags. Can you try adding `"_GNU_SOURCE" to your defines (or _POSIX_C_SOURCE=200809L or _XOPEN_SOURCE=700)? That fixed it for me. If you look in features.h you might see alternative ways to enable the __USE_UNIX98.

[Managor]

Adding _GNU_SOURCE before the includes was the only one that fixed 'not defined' error message. My setup is a pretty vanilla Xubuntu 19.04 distro and the command I used to compile was gcc main.c -lpthread. I'm not knowledgeable enough to know where gcc might be defining _GNU_SOURCE for me.
EDIT: clang provides the same results with clang main.c -pthread

[Managor]

I think I found a method to investigate this. Running gcc -dM -E main.c I'm able to list all the preprocessor defines. Piping that to grep I'm able to search individual defines as in gcc -dM -E main.c | grep __USE_XOPEN2K. For starters _GNU_SOURCE is not found on that list. __USE_UNIX98 yields nothing but __USE_XOPEN2K finds #define __USE_XOPEN2K 1. It's defined in two places and is dependent on defining _XOPEN_SOURCE (which is dependent on _GNU_SOURCE, so a dead end) or _POSIX_C_SOURCE. grep _POSIX_C_SOURCE finds it defined as #define _POSIX_C_SOURCE 200809L. 200809L is defined in this code block in features.h

/* If none of the ANSI/POSIX macros are defined, or if _DEFAULT_SOURCE
   is defined, use POSIX.1-2008 (or another version depending on
   _XOPEN_SOURCE).  */
#ifdef _DEFAULT_SOURCE
# if !defined _POSIX_SOURCE && !defined _POSIX_C_SOURCE
#  define __USE_POSIX_IMPLICITLY	1
# endif
# undef  _POSIX_SOURCE
# define _POSIX_SOURCE	1
# undef  _POSIX_C_SOURCE
# define _POSIX_C_SOURCE	200809L
#endif

#if ((!defined __STRICT_ANSI__					\
      || (defined _XOPEN_SOURCE && (_XOPEN_SOURCE - 0) >= 500))	\
     && !defined _POSIX_SOURCE && !defined _POSIX_C_SOURCE)
# define _POSIX_SOURCE	1
# if defined _XOPEN_SOURCE && (_XOPEN_SOURCE - 0) < 500
#  define _POSIX_C_SOURCE	2
# elif defined _XOPEN_SOURCE && (_XOPEN_SOURCE - 0) < 600
#  define _POSIX_C_SOURCE	199506L
# elif defined _XOPEN_SOURCE && (_XOPEN_SOURCE - 0) < 700
#  define _POSIX_C_SOURCE	200112L
# else
#  define _POSIX_C_SOURCE	200809L
# endif
# define __USE_POSIX_IMPLICITLY	1
#endif

and grepping _DEFAULT_SOURCE yields #define _DEFAULT_SOURCE 1
Hard to know where to go from this point forward but that should give you some pointers where the extention logic goes wrong

[Managor]

If I take the output of gcc -dM -E main.c, copy it to the start of my main.c and delete #define _BITS_PTHREADTYPES_COMMON_H 1 and #define _PTHREAD_H 1, pthread_rwlock_t won't show up as undefined.
I hope these bits of information help

[sean-mcmanus]

Yeah, this is caused by the fact that the default "-std" with gcc is a version that has gcc extensions enabled, but instead our default uses a non-gcc extension standard version.

[bobbrow]

#2782 is tracking gnu standard modes.