[24 Dec 06:46] hmmm is is legal to -D_XOPEN_SOURCE=500 in c++ ? [24 Dec 06:46] -std=gnu++14 [24 Dec 06:46] /usr/include/c++/8.0/cwchar:164:11: error: '::vfwscanf' has not been declared using ::vfwscanf;/usr/include/c++/8.0/cwchar:164:11: error: '::vfwscanf' has not been declared using ::vfwscanf; [24 Dec 06:48] re defining _XOPEN_SOURCE in c++, i have no clue. do c++ standards mention _XOPEN_SOURCE? [24 Dec 06:49] but it's correct that vfwscanf is not available for 500 [24 Dec 06:51] i really doubt it even mentions xopen [24 Dec 06:51] c++ actually say that standard headers need to be c99 compliant [24 Dec 06:51] (for c++ standard defined headers) [24 Dec 06:57] what port is it? [24 Dec 06:58] https://sting.dragonflybsd.org/dports/logs/devel___poco.log [24 Dec 06:59] cmake has freebsd not to set xopen flags [24 Dec 06:59] but strange why it works on linux/glibc then [24 Dec 06:59] maybe some feature checks of glibc are present in stdc++ [24 Dec 07:00] i don't understand. what sets _XOPEN_SOURCE? the gcc header or the port? [24 Dec 07:02] which config do we take in poco? [24 Dec 07:03] port itself in CMakeList.txt [24 Dec 07:03] except for FreeBSD [24 Dec 07:03] i have patched to check for us too [24 Dec 07:05] i don't see where our wchar.h would prevent the vfwscanf prototype to be visible even if _XOPEN_SOURCE == 500 [24 Dec 07:06] it has it under __ISO_C_VISIBLE >= 1999 [24 Dec 07:07] ah no, it doesn't have it with 500 [24 Dec 07:08] ah i see [24 Dec 07:09] no i don't see it [24 Dec 07:09] where is the visibility restricted [24 Dec 07:11] ah [24 Dec 07:11] __ISO_C_VISIBLE is from us [24 Dec 07:11] thought it was a g++ macro [24 Dec 07:11] yes, that's 1990 when _XOPEN_SOURCE is 500 [24 Dec 07:12] thought it was a gcc macro* [24 Dec 07:12] i would say -D_XOPEN_SOURCE=500 in c++ is illegal at least for C binding headers use [24 Dec 07:14] and why again does it work for fbsd? [24 Dec 07:15] yeah fbsd doesn't have _XOPEN_SOURCE in their poco config [24 Dec 07:15] mayhaps linux just doesn't restrict proto visibility as strict as dfly/free [24 Dec 07:16] or they make them visible for __cplusplus anyway [24 Dec 07:16] or... [24 Dec 07:18] poco CMakeLists.txt explictly was not adding this define for freebsd [24 Dec 07:18] i have patched to not to add for us too [24 Dec 07:18] yeah i saw that [24 Dec 07:21] does c++ set __STDC_VERSION__? [24 Dec 07:22] ah [24 Dec 07:22] /* This is to enable compatibility for ISO C++17. */ [24 Dec 07:22] # if __cplusplus >= 201703L [24 Dec 07:22] # define __USE_ISOC11 1 [24 Dec 07:22] # endif [24 Dec 07:23] and [24 Dec 07:23] # if __cplusplus >= 201103L || defined __GXX_EXPERIMENTAL_CXX0X__ [24 Dec 07:23] # define __USE_ISOCXX11 1 [24 Dec 07:23] # define __USE_ISOC99 1 [24 Dec 07:23] # endif [24 Dec 07:23] so that would make the protos visible in linux [24 Dec 07:23] mmmm [24 Dec 07:24] (glibc has the protos under a __USE_ISOC99 check) [24 Dec 07:25] why poco wants to set _XOPEN_SOURCE to 500 nevertheless, i have no clue though. that should really only be needed if you need to use some obsolete function or so [24 Dec 07:28] so in dfly/fbsd, _XOPEN_SOURCE affects visibility also when using c++ while in glibc it doesn't [24 Dec 07:28] at least for stuff under __USE_ISOC* checks [24 Dec 07:37] i wonder if how we handle it (by not handling it) is correct.. [24 Dec 07:38] good question [24 Dec 07:46] does any linux distro have a different libc than glibc as _default_? [24 Dec 07:46] seems so at least for musl [24 Dec 07:47] although nothing major [24 Dec 07:47] there are ones with musl and that lighter gplv2 one [24 Dec 07:48] even with uClibc [24 Dec 07:48] i assume it is not different in musl (vfwscanf availability) [24 Dec 07:52] could be, tbh maybe we could also set __ISO_C_VISIBLE 2011 if c++ under _XOPEN [24 Dec 07:52] musl doesn't restrict vfwscanf's proto at all [24 Dec 07:52] not necessarily 2011 though [24 Dec 07:54] if __cplusplus >= 201103L and env is limited [24 Dec 07:56] well in our cdefs.h it is like this: [24 Dec 07:57] if _XOPEN_SOURCE == 500 -> set _POSIX_C_SOURCE to 199506 [24 Dec 07:57] and then later on __ISO_C_VISIBLE and __POSIX_VISIBLE are set to 1990 and 199506 based on that [24 Dec 07:58] well yeah, easiest would be a check after that but that would require an undef [24 Dec 08:00] cleanest would probably be to handle __ISO_C_VISIBLE separately from __POSIX_VISIBLE [24 Dec 08:01] i think doing #if __cplusplus >= 201103L && __ISO_C_VISIBLE < 2011 specific check and #undef #define is not that bad [24 Dec 08:03] yeah i think so too, but it would clearly look (to someone understanding) like, "ah right, and there they were too lazy to handle it cleanly in the style of the rest of the header!" :) [24 Dec 08:04] well should be for things C, right [24 Dec 08:04] ? [24 Dec 08:04] tbh things c++ should be its header problem [24 Dec 08:08] so like [24 Dec 08:08] +#ifdef __cplusplus [24 Dec 08:08] +#if __cplusplus >= 201703L && __ISO_C_VISIBLE < 2011 [24 Dec 08:08] +#undef __ISO_C_VISIBLE [24 Dec 08:08] +#define __ISO_C_VISIBLE 2011 [24 Dec 08:08] +#endif [24 Dec 08:08] +#if __cplusplus >= 201103L && __ISO_C_VISIBLE < 1999 [24 Dec 08:08] +#undef __ISO_C_VISIBLE [24 Dec 08:08] +#define __ISO_C_VISIBLE 1999 [24 Dec 08:08] +#endif [24 Dec 08:08] +#endif [24 Dec 08:08] [24 Dec 08:08] ? [24 Dec 08:09] hm could make it an #elif [24 Dec 08:10] (untested at all) [24 Dec 08:10] mmm shouldn't if __cplusplus >= 201103L take __ISO_C_VISIBLE 2011 too ? [24 Dec 08:10] not according to glibc's featurs.h [24 Dec 08:10] /usr/include/features.h: __USE_ISOCXX11 Define ISO C++11 things. [24 Dec 08:10] yes but not __USE_ISOC11 [24 Dec 08:11] don't know what __USE_ISOCXX* is [24 Dec 08:11] ah right [24 Dec 08:11] so i ignored it [24 Dec 08:11] various "helpers" [24 Dec 08:11] poco would work with 1999 [24 Dec 08:11] like for templating libm functions [24 Dec 08:11] and sets c++ to 11 [24 Dec 08:12] but check the c++11 standard perhaps [24 Dec 08:12] i don't have one here [24 Dec 08:12] i had it somewhere, but dunno where :D [24 Dec 08:16] draft is at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf [24 Dec 08:16] and it says [24 Dec 08:16] in 1.1 scope [24 Dec 08:16] "C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:1999 Programming languages — C (hereinafter referred to as the C standard)." [24 Dec 08:16] i will look if that changed to c11 in the 2017 draft [24 Dec 08:17] 2017 draft: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4640.pdf [24 Dec 08:17] yes [24 Dec 08:17] "C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:2011 Programming languages — C (hereinafter referred to as the C standard)." [24 Dec 08:34] i wonder if there should be a tab after #undef too [24 Dec 08:43] go ahead and try https://leaf.dragonflybsd.org/~swildner/0001-WIP-__ISO_C_VISIBLE-adjustments-for-C.patch with a bulk