Re: CVS commit: src/include
Hmm, it seems that we were the only ones that had RES_NOCHECKNAME enabled. Everyone else uses check-names by default. So I am inclined to leave it as is. christos > On Apr 30, 2021, at 5:33 PM, Christos Zoulas wrote: > > Signed PGP part > I guess I will undo it, because as I mentioned in a separate mail it causes > other problems. > > christos > >> On Apr 30, 2021, at 5:18 PM, Robert Elz wrote: >> >> Date:Fri, 30 Apr 2021 12:07:49 -0400 >> From:"Christos Zoulas" >> Message-ID: <20210430160749.3a4dbf...@cvs.netbsd.org> >> >> |src/include: resolv.h >> | >> | Log Message: >> | Default to check-names for safety. >> >> Please don't do that, check-names applies at the wrong place, and >> is far too big a hammer. Applications which actually depend upon >> names returned (all that ever matters) having (or not having) some >> particular syntax should be verifying that before using it, just like >> any other data received over the network. What is to be valid, and >> what is a problem, varies from application to application. >> >> kre > > > signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/include
I guess I will undo it, because as I mentioned in a separate mail it causes other problems. christos > On Apr 30, 2021, at 5:18 PM, Robert Elz wrote: > >Date:Fri, 30 Apr 2021 12:07:49 -0400 >From:"Christos Zoulas" >Message-ID: <20210430160749.3a4dbf...@cvs.netbsd.org> > > |src/include: resolv.h > | > | Log Message: > | Default to check-names for safety. > > Please don't do that, check-names applies at the wrong place, and > is far too big a hammer. Applications which actually depend upon > names returned (all that ever matters) having (or not having) some > particular syntax should be verifying that before using it, just like > any other data received over the network. What is to be valid, and > what is a problem, varies from application to application. > > kre signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/include
Date:Fri, 30 Apr 2021 12:07:49 -0400 From:"Christos Zoulas" Message-ID: <20210430160749.3a4dbf...@cvs.netbsd.org> | src/include: resolv.h | | Log Message: | Default to check-names for safety. Please don't do that, check-names applies at the wrong place, and is far too big a hammer. Applications which actually depend upon names returned (all that ever matters) having (or not having) some particular syntax should be verifying that before using it, just like any other data received over the network. What is to be valid, and what is a problem, varies from application to application. kre
Re: CVS commit: src/include
On Fri, 17 Apr 2020, Kamil Rytarowski wrote: On 17.04.2020 22:22, Joerg Sonnenberger wrote: On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: Module Name:src Committed By: kamil Date: Fri Apr 17 15:22:35 UTC 2020 Modified Files: src/include: assert.h Log Message: Remove the static_assert() fallback for pre-C11 and pre-C++11 C++ without real static_assert() can be incompatible with the C fallback as presented in openjdk. A pre-C11 compiler can be picky on the implementation. So did you actually test that the tree compiles with this? Just asking, since your own ptrace tests depend on static_assert... Joerg I will fix it! And please test... :) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/include
On 17.04.2020 22:22, Joerg Sonnenberger wrote: > On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: >> Module Name: src >> Committed By:kamil >> Date:Fri Apr 17 15:22:35 UTC 2020 >> >> Modified Files: >> src/include: assert.h >> >> Log Message: >> Remove the static_assert() fallback for pre-C11 and pre-C++11 >> >> C++ without real static_assert() can be incompatible with the C fallback >> as presented in openjdk. >> >> A pre-C11 compiler can be picky on the implementation. > > So did you actually test that the tree compiles with this? Just asking, > since your own ptrace tests depend on static_assert... > > Joerg > I will fix it! signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/include
On Fri, 17 Apr 2020, Joerg Sonnenberger wrote: On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: Module Name:src Committed By: kamil Date: Fri Apr 17 15:22:35 UTC 2020 Modified Files: src/include: assert.h Log Message: Remove the static_assert() fallback for pre-C11 and pre-C++11 C++ without real static_assert() can be incompatible with the C fallback as presented in openjdk. A pre-C11 compiler can be picky on the implementation. So did you actually test that the tree compiles with this? Just asking, since your own ptrace tests depend on static_assert... Obviousliy this change was not tested... dependall ===> tests/lib/libc/sys # compile sys/t_ptrace_wait.o /build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2 -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror -Wno-missing-noreturn -fPIE -g --sysroot=/build/netbsd-local/dest/amd64 -I/build/netbsd-local/src_ro/tests/lib/libc/sys/../../.. -c -D_KERNTYPES -D__TEST_FENV -DENABLE_TESTS /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:77:15: error: expected declaration specifiers or '...' before 'sizeof' static_assert(sizeof(((struct ptrace_state *)0)->pe_report_event) == ^~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:79:5: error: expected declaration specifiers or '...' before string constant "pe_report_event and si_pe_report_event must be of the same size"); ^ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:80:15: error: expected declaration specifiers or '...' before 'sizeof' static_assert(sizeof(((struct ptrace_state *)0)->pe_other_pid) == ^~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:82:5: error: expected declaration specifiers or '...' before string constant "pe_other_pid and si_pe_other_pid must be of the same size"); ^~~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:83:15: error: expected declaration specifiers or '...' before 'sizeof' static_assert(sizeof(((struct ptrace_state *)0)->pe_lwp) == ^~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:85:5: error: expected declaration specifiers or '...' before string constant "pe_lwp and si_pe_lwp must be of the same size"); ^~~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:86:15: error: expected declaration specifiers or '...' before 'sizeof' static_assert(sizeof(((struct ptrace_state *)0)->pe_other_pid) == ^~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:88:5: error: expected declaration specifiers or '...' before string constant "pe_other_pid and pe_lwp must be of the same size"); ^~ *** [t_ptrace_wait.o] Error code 1 nbmake: stopped in /build/netbsd-local/src_ro ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/include
On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Fri Apr 17 15:22:35 UTC 2020 > > Modified Files: > src/include: assert.h > > Log Message: > Remove the static_assert() fallback for pre-C11 and pre-C++11 > > C++ without real static_assert() can be incompatible with the C fallback > as presented in openjdk. > > A pre-C11 compiler can be picky on the implementation. So did you actually test that the tree compiles with this? Just asking, since your own ptrace tests depend on static_assert... Joerg
Re: CVS commit: src/include
On 02.03.2020 03:58, matthew green wrote: >>> On Sun, Mar 01, 2020 at 03:08:16PM +, Kamil Rytarowski wrote: Module Name: src Committed By: kamil Date: Sun Mar 1 15:08:16 UTC 2020 Modified Files: src/include: stddef.h Log Message: Expose max_align_t to C99/C++ > > where was this discussed? Yes. > > why are controvesial changes being commited without any > warning or discussion on tech-toolchain? > It was discussed on ML. > this is getting ridiculous. please revert this and the > GNU hashc hanges, and hold off any other changes pending > discussions on public lists. > > GNU hashes are not generated (and so used) on NetBSD. > .mrg. > signature.asc Description: OpenPGP digital signature
re: CVS commit: src/include
> > On Sun, Mar 01, 2020 at 03:08:16PM +, Kamil Rytarowski wrote: > >> Module Name: src > >> Committed By: kamil > >> Date: Sun Mar 1 15:08:16 UTC 2020 > >> > >> Modified Files: > >>src/include: stddef.h > >> > >> Log Message: > >> Expose max_align_t to C99/C++ where was this discussed? why are controvesial changes being commited without any warning or discussion on tech-toolchain? this is getting ridiculous. please revert this and the GNU hashc hanges, and hold off any other changes pending discussions on public lists. .mrg.
Re: CVS commit: src/include
On 01.03.2020 22:54, Joerg Sonnenberger wrote: > On Sun, Mar 01, 2020 at 10:26:08PM +0100, Kamil Rytarowski wrote: >> On 01.03.2020 19:31, Joerg Sonnenberger wrote: >>> On Sun, Mar 01, 2020 at 03:08:16PM +, Kamil Rytarowski wrote: Module Name: src Committed By: kamil Date: Sun Mar 1 15:08:16 UTC 2020 Modified Files: src/include: stddef.h Log Message: Expose max_align_t to C99/C++ >>> >>> Please revert this immediately. It is just wrong. >>> >> >> Rationale? libc++ does not work and I perceive insisting it as a losing >> battle and and zero gain. > > As you do know, there is a patch for libc++ under review to fix this > properly. It is even generally agreed that the current behavior is a > bug. Your patch broke well defined C++03 programs. > This problem does not exist on OSs like Linux as they get this namespace visibility defined inside LLVM or GNU toolchain headers. NetBSD ships with its own stddef.h, rather than relying on a toolchain and its internal extensions. >>> >>> This is incorrect as well. >>> >> >> No stddef.h in GLIBC is a matter of fact. > > $ printf '#include \nmax_align_t foo;' | clang++ -std=c++03 -x c++ - > :2:1: error: unknown type name 'max_align_t' > $ printf '#include \nmax_align_t foo;' | g++ -std=c++03 -x c++ - > :2:1: error: ‘max_align_t’ does not name a type > > Joerg > As you know what I am referring to: https://github.com/llvm/llvm-project/commit/03dd205c1516d9930a80101a7e0a6793af47ec9e I will revert this but I don't feel convinced. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/include
On Sun, Mar 01, 2020 at 10:26:08PM +0100, Kamil Rytarowski wrote: > On 01.03.2020 19:31, Joerg Sonnenberger wrote: > > On Sun, Mar 01, 2020 at 03:08:16PM +, Kamil Rytarowski wrote: > >> Module Name: src > >> Committed By: kamil > >> Date: Sun Mar 1 15:08:16 UTC 2020 > >> > >> Modified Files: > >>src/include: stddef.h > >> > >> Log Message: > >> Expose max_align_t to C99/C++ > > > > Please revert this immediately. It is just wrong. > > > > Rationale? libc++ does not work and I perceive insisting it as a losing > battle and and zero gain. As you do know, there is a patch for libc++ under review to fix this properly. It is even generally agreed that the current behavior is a bug. Your patch broke well defined C++03 programs. > >> This problem does not exist on OSs like Linux as they get this namespace > >> visibility defined inside LLVM or GNU toolchain headers. NetBSD ships with > >> its own stddef.h, rather than relying on a toolchain and its internal > >> extensions. > > > > This is incorrect as well. > > > > No stddef.h in GLIBC is a matter of fact. $ printf '#include \nmax_align_t foo;' | clang++ -std=c++03 -x c++ - :2:1: error: unknown type name 'max_align_t' $ printf '#include \nmax_align_t foo;' | g++ -std=c++03 -x c++ - :2:1: error: ‘max_align_t’ does not name a type Joerg
Re: CVS commit: src/include
On 01.03.2020 19:31, Joerg Sonnenberger wrote: > On Sun, Mar 01, 2020 at 03:08:16PM +, Kamil Rytarowski wrote: >> Module Name: src >> Committed By:kamil >> Date:Sun Mar 1 15:08:16 UTC 2020 >> >> Modified Files: >> src/include: stddef.h >> >> Log Message: >> Expose max_align_t to C99/C++ > > Please revert this immediately. It is just wrong. > Rationale? libc++ does not work and I perceive insisting it as a losing battle and and zero gain. >> This problem does not exist on OSs like Linux as they get this namespace >> visibility defined inside LLVM or GNU toolchain headers. NetBSD ships with >> its own stddef.h, rather than relying on a toolchain and its internal >> extensions. > > This is incorrect as well. > No stddef.h in GLIBC is a matter of fact. > Joerg > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/include
On Sun, Mar 01, 2020 at 03:08:16PM +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Sun Mar 1 15:08:16 UTC 2020 > > Modified Files: > src/include: stddef.h > > Log Message: > Expose max_align_t to C99/C++ Please revert this immediately. It is just wrong. > This problem does not exist on OSs like Linux as they get this namespace > visibility defined inside LLVM or GNU toolchain headers. NetBSD ships with > its own stddef.h, rather than relying on a toolchain and its internal > extensions. This is incorrect as well. Joerg
Re: CVS commit: src/include
Thanks, applied. christos > On Sep 15, 2019, at 7:51 PM, Kamil Rytarowski wrote: > > Signed PGP part > Thanks! > > Here is more cleanup of _INCOMPLETE_XOPEN_C063: > > http://netbsd.org/~kamil/patch-00149-_INCOMPLETE_XOPEN_C063.txt > > (not build tested) > > On 16.09.2019 01:41, Christos Zoulas wrote: >> Fixed. >> >> christos >> >>> On Sep 15, 2019, at 6:40 PM, Kamil Rytarowski wrote: >>> >>> Signed PGP part >>> On 16.09.2019 00:32, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Sun Sep 15 22:32:48 UTC 2019 Modified Files: src/include: unistd.h Log Message: Declare fexecve >>> >>> Thanks! >>> >>> Now we have got two.. declarations. >>> >>> >>> #if defined(_INCOMPLETE_XOPEN_C063) >>> int fexecve(int, char * const *, char * const *); >>> #endif >>> >>> And the newly added one. Do we still need this _INCOMPLETE_XOPEN_C063 guard? >>> >>> >>> >> > > > >
Re: CVS commit: src/include
Thanks! Here is more cleanup of _INCOMPLETE_XOPEN_C063: http://netbsd.org/~kamil/patch-00149-_INCOMPLETE_XOPEN_C063.txt (not build tested) On 16.09.2019 01:41, Christos Zoulas wrote: > Fixed. > > christos > >> On Sep 15, 2019, at 6:40 PM, Kamil Rytarowski wrote: >> >> Signed PGP part >> On 16.09.2019 00:32, Christos Zoulas wrote: >>> Module Name:src >>> Committed By: christos >>> Date: Sun Sep 15 22:32:48 UTC 2019 >>> >>> Modified Files: >>> src/include: unistd.h >>> >>> Log Message: >>> Declare fexecve >>> >> >> Thanks! >> >> Now we have got two.. declarations. >> >> >> #if defined(_INCOMPLETE_XOPEN_C063) >> int fexecve(int, char * const *, char * const *); >> #endif >> >> And the newly added one. Do we still need this _INCOMPLETE_XOPEN_C063 guard? >> >> >> > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/include
Fixed. christos > On Sep 15, 2019, at 6:40 PM, Kamil Rytarowski wrote: > > Signed PGP part > On 16.09.2019 00:32, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Sun Sep 15 22:32:48 UTC 2019 >> >> Modified Files: >> src/include: unistd.h >> >> Log Message: >> Declare fexecve >> > > Thanks! > > Now we have got two.. declarations. > > > #if defined(_INCOMPLETE_XOPEN_C063) > int fexecve(int, char * const *, char * const *); > #endif > > And the newly added one. Do we still need this _INCOMPLETE_XOPEN_C063 guard? > > >
Re: CVS commit: src/include
On 16.09.2019 00:32, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sun Sep 15 22:32:48 UTC 2019 > > Modified Files: > src/include: unistd.h > > Log Message: > Declare fexecve > Thanks! Now we have got two.. declarations. #if defined(_INCOMPLETE_XOPEN_C063) int fexecve(int, char * const *, char * const *); #endif And the newly added one. Do we still need this _INCOMPLETE_XOPEN_C063 guard? signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/include
On 23.05.2019 16:09, m...@netbsd.org wrote: > On Thu, May 23, 2019 at 09:05:00AM +0200, Martin Husemann wrote: >> On Thu, May 23, 2019 at 12:03:33AM +0200, Kamil Rytarowski wrote: > -#if ((__cplusplus - 0) < 201103L) > +#if defined(_ISOC11_SOURCE) || (__STDC_VERSION__ - 0) >= 201101L >> >> Am I missing something or does this (in addition to the intended change) >> make the macro invisible for C++ compilations? Is that intended? If so, >> shouldn't it be explained in the log message? >> >> Martin > > Per the standards: > static_assert / _Static_assert is meaningful for >=C11 > static_assert is meaningful for >=C++11 > > >= C++11 : handled by libstdc++ / libc++ > >= C11 : handled by us, in this case and before. > > Should it mean something for: > < C++11 > < C11 > > The older version attempted to provide < C++11 and < C11 static_assert, > too. > > This is causing problems because g++ does not provide _Static_assert in > the case of building older C++ code. > > Kamil argued you should just not use it if it doesn't work. > My argument was that we shouldn't provide a broken definition. > > The code from the bug report did: > #if defined(static_assert) > .. fallback definition .. > #endif > > I think it is reasonable for this to work. > > We can probably keep providing it for all C standards, I guess. that was > the "that's so solaris" argument. GCC does not cause problems with that. > The solaris case is that we need to define very precise set of POSIX_SOURCE/XOPEN/C_SOURCE/etc namespace, and it's difficult sometimes to get some programs to build cleanly as there are occurrences of missing prototypes as something is protected by a different version of namespace. Personally, I was trying to improve SmartOS support for qemu and fix missing prototypes, but I gave up with the maze of ifdefs. The following patch makes static_assert functional for me for all C and C++ standards with GCC/G++: http://netbsd.org/~kamil/patch-00113-static_assert.txt] It removes usage of the message command, but in practice it probably doesn't matter. In C++17 this message argument is optional. 173 kamil@chieftec /tmp $ g++ -std=c++11 test.c test.c: In function ‘int main(int, char**)’: test.c:6:2: error: static assertion failed: Hello static_assert(sizeof(argc) == 1, "Hello"); ^ 174 kamil@chieftec /tmp $ g++ -std=c++17 test.c test.c: In function ‘int main(int, char**)’: test.c:6:2: error: static assertion failed: Hello static_assert(sizeof(argc) == 1, "Hello"); ^ 175 kamil@chieftec /tmp $ g++ -std=c++98 test.c In file included from /usr/include/assert.h:44:0, from test.c:1: test.c: In function ‘int main(int, char**)’: test.c:6:2: error: size of array ‘__ctassert0’ is negative static_assert(sizeof(argc) == 1, "Hello"); If this is fine, I will add ATF test for a combination of C and C++ standards. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/include
On Thu, May 23, 2019 at 09:05:00AM +0200, Martin Husemann wrote: > On Thu, May 23, 2019 at 12:03:33AM +0200, Kamil Rytarowski wrote: > > >> -#if ((__cplusplus - 0) < 201103L) > > >> +#if defined(_ISOC11_SOURCE) || (__STDC_VERSION__ - 0) >= 201101L > > Am I missing something or does this (in addition to the intended change) > make the macro invisible for C++ compilations? Is that intended? If so, > shouldn't it be explained in the log message? > > Martin Per the standards: static_assert / _Static_assert is meaningful for >=C11 static_assert is meaningful for >=C++11 >= C++11 : handled by libstdc++ / libc++ >= C11 : handled by us, in this case and before. Should it mean something for: < C++11 < C11 The older version attempted to provide < C++11 and < C11 static_assert, too. This is causing problems because g++ does not provide _Static_assert in the case of building older C++ code. Kamil argued you should just not use it if it doesn't work. My argument was that we shouldn't provide a broken definition. The code from the bug report did: #if defined(static_assert) .. fallback definition .. #endif I think it is reasonable for this to work. We can probably keep providing it for all C standards, I guess. that was the "that's so solaris" argument. GCC does not cause problems with that.
Re: CVS commit: src/include
On Thu, May 23, 2019 at 09:05:00AM +0200, Martin Husemann wrote: > On Thu, May 23, 2019 at 12:03:33AM +0200, Kamil Rytarowski wrote: > > >> -#if ((__cplusplus - 0) < 201103L) > > >> +#if defined(_ISOC11_SOURCE) || (__STDC_VERSION__ - 0) >= 201101L > > Am I missing something or does this (in addition to the intended change) > make the macro invisible for C++ compilations? Is that intended? If so, > shouldn't it be explained in the log message? static_assert is a keyword in C++11. Joerg
Re: CVS commit: src/include
On Thu, May 23, 2019 at 12:03:33AM +0200, Kamil Rytarowski wrote: > >> -#if ((__cplusplus - 0) < 201103L) > >> +#if defined(_ISOC11_SOURCE) || (__STDC_VERSION__ - 0) >= 201101L Am I missing something or does this (in addition to the intended change) make the macro invisible for C++ compilations? Is that intended? If so, shouldn't it be explained in the log message? Martin
Re: CVS commit: src/include
On 22.05.2019 23:35, Kamil Rytarowski wrote: > On 22.05.2019 23:25, Maya Rashish wrote: >> Module Name: src >> Committed By:maya >> Date:Wed May 22 21:25:01 UTC 2019 >> >> Modified Files: >> src/include: assert.h >> >> Log Message: >> Limit static_assert visibility to C11. >> >> The existing definition caused issues as GCC only provides _Static_assert >> when building C11 code. >> This follows the C standard: static_assert available since C11. >> >> Fixes https://rt.perl.org/Public/Bug/Display.html?id=134023 >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.22 -r1.23 src/include/assert.h >> >> Please note that diffs are not public domain; they are subject to the >> copyright notices on the relevant files. >> >> >> Modified files: >> >> Index: src/include/assert.h >> diff -u src/include/assert.h:1.22 src/include/assert.h:1.23 >> --- src/include/assert.h:1.22Mon Oct 3 12:08:39 2016 >> +++ src/include/assert.h Wed May 22 21:25:01 2019 >> @@ -1,4 +1,4 @@ >> -/* $NetBSD: assert.h,v 1.22 2016/10/03 12:08:39 kamil Exp $*/ >> +/* $NetBSD: assert.h,v 1.23 2019/05/22 21:25:01 maya Exp $ */ >> >> /*- >> * Copyright (c) 1992, 1993 >> @@ -105,7 +105,7 @@ void __diagassert13(const char *, int, c >> __END_DECLS >> #endif /* __ASSERT_DECLARED */ >> >> -#if ((__cplusplus - 0) < 201103L) >> +#if defined(_ISOC11_SOURCE) || (__STDC_VERSION__ - 0) >= 201101L >> #ifndef static_assert >> #define static_assert _Static_assert >> #endif /* static_assert */ >> > > We explicitly decided to not pick this Solaris-style approach in our > headers. Please revert and fix Perl. > OK, It looks like Joerg agreed with this change. It breaks the existing style of C/C++ compiler features, such as or .. but let it be. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/include
On 22.05.2019 23:25, Maya Rashish wrote: > Module Name: src > Committed By: maya > Date: Wed May 22 21:25:01 UTC 2019 > > Modified Files: > src/include: assert.h > > Log Message: > Limit static_assert visibility to C11. > > The existing definition caused issues as GCC only provides _Static_assert > when building C11 code. > This follows the C standard: static_assert available since C11. > > Fixes https://rt.perl.org/Public/Bug/Display.html?id=134023 > > > To generate a diff of this commit: > cvs rdiff -u -r1.22 -r1.23 src/include/assert.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > > Modified files: > > Index: src/include/assert.h > diff -u src/include/assert.h:1.22 src/include/assert.h:1.23 > --- src/include/assert.h:1.22 Mon Oct 3 12:08:39 2016 > +++ src/include/assert.h Wed May 22 21:25:01 2019 > @@ -1,4 +1,4 @@ > -/* $NetBSD: assert.h,v 1.22 2016/10/03 12:08:39 kamil Exp $*/ > +/* $NetBSD: assert.h,v 1.23 2019/05/22 21:25:01 maya Exp $ */ > > /*- > * Copyright (c) 1992, 1993 > @@ -105,7 +105,7 @@ void __diagassert13(const char *, int, c > __END_DECLS > #endif /* __ASSERT_DECLARED */ > > -#if ((__cplusplus - 0) < 201103L) > +#if defined(_ISOC11_SOURCE) || (__STDC_VERSION__ - 0) >= 201101L > #ifndef static_assert > #define static_assert _Static_assert > #endif /* static_assert */ > We explicitly decided to not pick this Solaris-style approach in our headers. Please revert and fix Perl. signature.asc Description: OpenPGP digital signature
re: CVS commit: src/include
Christos Zoulas writes: > In article <20180207130259.ga21...@britannica.bec.de>, > Joerg Sonnenberger wrote: > >On Tue, Feb 06, 2018 at 03:21:21PM -0500, Christos Zoulas wrote: > >> Module Name: src > >> Committed By: christos > >> Date: Tue Feb 6 20:21:21 UTC 2018 > >> > >> Modified Files: > >>src/include: unistd.h > >> > >> Log Message: > >> detect duplicate declaration of pthread_atfork() in pthread.h > > > >Is this for some new broken GCC warning? > > > > This is what the compiler said, and we have prior art for this (macro > protect to avoid dup declarations -- grep for _DECLARED). why is it a problem to declare the functino twice? what was the context of the compiler? .mrg.
Re: CVS commit: src/include
On Feb 9, 12:15pm, u...@stderr.spb.ru (Valery Ushakov) wrote: -- Subject: Re: CVS commit: src/include | On Fri, Feb 09, 2018 at 02:44:05 +, Christos Zoulas wrote: | | > In article <20180208234417.ga23...@britannica.bec.de>, | > Joerg Sonnenberger wrote: | > >On Thu, Feb 08, 2018 at 10:56:22PM +, Christos Zoulas wrote: | > >> In article <20180207130259.ga21...@britannica.bec.de>, | > >> Joerg Sonnenberger wrote: | > >> >On Tue, Feb 06, 2018 at 03:21:21PM -0500, Christos Zoulas wrote: | > >> >> Module Name: src | > >> >> Committed By: christos | > >> >> Date: Tue Feb 6 20:21:21 UTC 2018 | > >> >> | > >> >> Modified Files: | > >> >> src/include: unistd.h | > >> >> | > >> >> Log Message: | > >> >> detect duplicate declaration of pthread_atfork() in pthread.h | > >> > | > >> >Is this for some new broken GCC warning? | > >> > | > >> | > >> This is what the compiler said, and we have prior art for this (macro | > >> protect to avoid dup declarations -- grep for _DECLARED). | > > | > >Normally only for typedefs, since pre-C11 (?) it was invalid to typedef | > >the same thing twice. That's not true for prototypes though. | > | > We have been doing this for functions for a while; check unistd.h | | But *why* have we been doing that? I added the redundand decls warning in bsd.sys.mk in 2001, but it is still commented out. Is that now part of -Wall? christos
Re: CVS commit: src/include
On Fri, Feb 09, 2018 at 02:44:05 +, Christos Zoulas wrote: > In article <20180208234417.ga23...@britannica.bec.de>, > Joerg Sonnenberger wrote: > >On Thu, Feb 08, 2018 at 10:56:22PM +, Christos Zoulas wrote: > >> In article <20180207130259.ga21...@britannica.bec.de>, > >> Joerg Sonnenberger wrote: > >> >On Tue, Feb 06, 2018 at 03:21:21PM -0500, Christos Zoulas wrote: > >> >> Module Name:src > >> >> Committed By: christos > >> >> Date: Tue Feb 6 20:21:21 UTC 2018 > >> >> > >> >> Modified Files: > >> >> src/include: unistd.h > >> >> > >> >> Log Message: > >> >> detect duplicate declaration of pthread_atfork() in pthread.h > >> > > >> >Is this for some new broken GCC warning? > >> > > >> > >> This is what the compiler said, and we have prior art for this (macro > >> protect to avoid dup declarations -- grep for _DECLARED). > > > >Normally only for typedefs, since pre-C11 (?) it was invalid to typedef > >the same thing twice. That's not true for prototypes though. > > We have been doing this for functions for a while; check unistd.h But *why* have we been doing that? -uwe
Re: CVS commit: src/include
In article <20180208234417.ga23...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Thu, Feb 08, 2018 at 10:56:22PM +, Christos Zoulas wrote: >> In article <20180207130259.ga21...@britannica.bec.de>, >> Joerg Sonnenberger wrote: >> >On Tue, Feb 06, 2018 at 03:21:21PM -0500, Christos Zoulas wrote: >> >> Module Name: src >> >> Committed By: christos >> >> Date: Tue Feb 6 20:21:21 UTC 2018 >> >> >> >> Modified Files: >> >> src/include: unistd.h >> >> >> >> Log Message: >> >> detect duplicate declaration of pthread_atfork() in pthread.h >> > >> >Is this for some new broken GCC warning? >> > >> >> This is what the compiler said, and we have prior art for this (macro >> protect to avoid dup declarations -- grep for _DECLARED). > >Normally only for typedefs, since pre-C11 (?) it was invalid to typedef >the same thing twice. That's not true for prototypes though. We have been doing this for functions for a while; check unistd.h christos
Re: CVS commit: src/include
On Thu, Feb 08, 2018 at 10:56:22PM +, Christos Zoulas wrote: > In article <20180207130259.ga21...@britannica.bec.de>, > Joerg Sonnenberger wrote: > >On Tue, Feb 06, 2018 at 03:21:21PM -0500, Christos Zoulas wrote: > >> Module Name: src > >> Committed By: christos > >> Date: Tue Feb 6 20:21:21 UTC 2018 > >> > >> Modified Files: > >>src/include: unistd.h > >> > >> Log Message: > >> detect duplicate declaration of pthread_atfork() in pthread.h > > > >Is this for some new broken GCC warning? > > > > This is what the compiler said, and we have prior art for this (macro > protect to avoid dup declarations -- grep for _DECLARED). Normally only for typedefs, since pre-C11 (?) it was invalid to typedef the same thing twice. That's not true for prototypes though. Joerg
Re: CVS commit: src/include
In article <20180207130259.ga21...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Tue, Feb 06, 2018 at 03:21:21PM -0500, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Tue Feb 6 20:21:21 UTC 2018 >> >> Modified Files: >> src/include: unistd.h >> >> Log Message: >> detect duplicate declaration of pthread_atfork() in pthread.h > >Is this for some new broken GCC warning? > This is what the compiler said, and we have prior art for this (macro protect to avoid dup declarations -- grep for _DECLARED). christos
Re: CVS commit: src/include
On Tue, Feb 06, 2018 at 03:21:21PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Tue Feb 6 20:21:21 UTC 2018 > > Modified Files: > src/include: unistd.h > > Log Message: > detect duplicate declaration of pthread_atfork() in pthread.h Is this for some new broken GCC warning? Joerg
Re: CVS commit: src/include
On Sat, Oct 07, 2017 at 05:16:06PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sat Oct 7 21:16:06 UTC 2017 > > Modified Files: > src/include: stdlib.h > > Log Message: > remove recallocarray Thanks! Joerg
Re: CVS commit: src/include
In article <29792.1474483...@splode.eterna.com.au>, matthew green wrote: > >however, there's still a build issue in libsanitizer to fix due >to the changed structure size. I fixed it. christos
re: CVS commit: src/include
matthew green writes: > "Roy Marples" writes: > > Module Name:src > > Committed By: roy > > Date: Wed Sep 21 13:32:27 UTC 2016 > > > > Modified Files: > > src/include: ifaddrs.h > > > > Log Message: > > Add ifa_addrflags to ifaddrs (forgot to commit this file, thanks Ryo!) > > this change (and all the prior ones that need this too) don't seem to > have been done properly. > > getifaddrs(3) at the very least needs to be versioned, but i'm not > really even sure that you can make this change so easily. now any > 3rd party library code will fail unless explicitly updated to > understand this netbsd change and provide different versions. > > please revert these changes and bring it up on tech-kern/tech-net. roy pointed out privately that getifaddrs() returns a pointer and should be ok with this change. however, there's still a build issue in libsanitizer to fix due to the changed structure size. .mr.
re: CVS commit: src/include
"Roy Marples" writes: > Module Name: src > Committed By: roy > Date: Wed Sep 21 13:32:27 UTC 2016 > > Modified Files: > src/include: ifaddrs.h > > Log Message: > Add ifa_addrflags to ifaddrs (forgot to commit this file, thanks Ryo!) this change (and all the prior ones that need this too) don't seem to have been done properly. getifaddrs(3) at the very least needs to be versioned, but i'm not really even sure that you can make this change so easily. now any 3rd party library code will fail unless explicitly updated to understand this netbsd change and provide different versions. please revert these changes and bring it up on tech-kern/tech-net. .mrg.
Re: CVS commit: src/include
In article <20160320144155.gb29...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Sun, Mar 20, 2016 at 10:11:50AM -0400, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Sun Mar 20 14:11:50 UTC 2016 >> >> Modified Files: >> src/include: stddef.h >> >> Log Message: >> PR/50983: David Shao: Protect stddef; >> also make the pointer void *. > >It would be much nicer to cut out the defined(foo) checks and just use >foo - 0 > ... Indeed. christos
Re: CVS commit: src/include
On Sun, Mar 20, 2016 at 10:11:50AM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sun Mar 20 14:11:50 UTC 2016 > > Modified Files: > src/include: stddef.h > > Log Message: > PR/50983: David Shao: Protect stddef; > also make the pointer void *. It would be much nicer to cut out the defined(foo) checks and just use foo - 0 > ... Joerg
Re: CVS commit: src/include
On Thu, Mar 10, 2016 at 06:53:48PM +, Leonardo Taccari wrote: > Module Name: src > Committed By: leot > Date: Thu Mar 10 18:53:48 UTC 2016 > > Modified Files: > src/include: string.h > > Log Message: > strndup() is part of XSI from The Open Group Base Specification Issue 7 and > had > a similar history of stpcpy(), stpncpy() and strnlen(). > Make it visible under XOPEN_SOURCE>=700 too (not just _NETBSD_SOURCE). Just for the future, the more important change is actually to put it under POSIX 2008, XSI is less interesting. Joerg
Re: CVS commit: src/include/rpc
In article <20151107002945.2872e17f...@rebar.astron.com>, Christos Zoulas wrote: >On Nov 7, 9:17am, m...@eterna.com.au (matthew green) wrote: >-- Subject: re: CVS commit: src/include/rpc > >| > Switch to the size-unlimited fd_set. Some code will need to change to be >| > able to use this if the code allocates its own fd_set's. >| >| this is great! thanks. can we bump FD_SETSIZE itself now? :) > >There is a little more work to be done... Let me do it... And it is done. christos
re: CVS commit: src/include/rpc
On Nov 7, 9:17am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/include/rpc | > Switch to the size-unlimited fd_set. Some code will need to change to be | > able to use this if the code allocates its own fd_set's. | | this is great! thanks. can we bump FD_SETSIZE itself now? :) There is a little more work to be done... Let me do it... christos
re: CVS commit: src/include/rpc
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Fri Nov 6 19:42:57 UTC 2015 > > Modified Files: > src/include/rpc: svc.h > > Log Message: > Switch to the size-unlimited fd_set. Some code will need to change to be > able to use this if the code allocates its own fd_set's. this is great! thanks. can we bump FD_SETSIZE itself now? :) .mrg.
Re: CVS commit: src/include/ssp
On 25/04/14 18:00, Christos Zoulas wrote: In article <20140425171614.ga22...@britannica.bec.de>, Joerg Sonnenberger wrote: On Thu, Apr 24, 2014 at 08:12:56PM +, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Thu Apr 24 20:12:56 UTC 2014 Modified Files: src/include/ssp: string.h Log Message: Wrap stpncpy() iff GNUC_PREREQ(4,8). Fixes USE_SSP=yes builds with gcc 4.5. This produces a regerssion for clang users. Yes, what are you trying to fix? The thing stated in the commit message: "USE_SSP=yes builds with gcc 4.5"
Re: CVS commit: src/include/ssp
In article <20140425171614.ga22...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Thu, Apr 24, 2014 at 08:12:56PM +, Antti Kantee wrote: >> Module Name: src >> Committed By:pooka >> Date:Thu Apr 24 20:12:56 UTC 2014 >> >> Modified Files: >> src/include/ssp: string.h >> >> Log Message: >> Wrap stpncpy() iff GNUC_PREREQ(4,8). Fixes USE_SSP=yes builds >> with gcc 4.5. > >This produces a regerssion for clang users. Yes, what are you trying to fix? christos
Re: CVS commit: src/include/ssp
On Thu, Apr 24, 2014 at 08:12:56PM +, Antti Kantee wrote: > Module Name: src > Committed By: pooka > Date: Thu Apr 24 20:12:56 UTC 2014 > > Modified Files: > src/include/ssp: string.h > > Log Message: > Wrap stpncpy() iff GNUC_PREREQ(4,8). Fixes USE_SSP=yes builds > with gcc 4.5. This produces a regerssion for clang users. Joerg
Re: CVS commit: src/include
On Jan 2, 6:33pm, "Christos Zoulas" wrote: } } This is a multi-part message in MIME format. } } --_--=_1388705630257000 } Content-Disposition: inline } Content-Transfer-Encoding: 8bit } Content-Type: text/plain; charset="US-ASCII" } } Module Name: src } Committed By: christos } Date: Thu Jan 2 23:33:50 UTC 2014 } } Modified Files: } src/include: unistd.h } } Log Message: } PR/4891: Wiz: readlink moved from xopen to base at issue 5. This should have been PR/48491. PR/4891 cleaned up. }-- End of excerpt from "Christos Zoulas"
Re: CVS commit: src/include
In article <20121126195342.474c517...@cvs.netbsd.org>, Antti Kantee wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: pooka >Date: Mon Nov 26 19:53:42 UTC 2012 > >Modified Files: > src/include: pwd.h > >Log Message: >revert previous commit since it breaks the build on NetBSD and >apparently that's considered important > And it is disgusting :-) For things like this is is better to provide wrappers or get upstream to fix the real issue. christos
Re: CVS commit: src/include (commaize_number)
On Tue, 15 Mar 2011, Antti Kantee wrote: On Tue Mar 15 2011 at 05:25:51 -0700, Paul Goyette wrote: Module Name:src Committed By: pooka Date: Tue Mar 15 12:21:08 UTC 2011 Modified Files: src/include: stdlib.h Log Message: put in a proto for commaize_number() (nb. doing this purely as the minimum work solution to get a working build) Maybe we shouldn't fix the build here, since there's also the issue of bumping the minor version of libc which was not done. With a build break we don't have any compatability issues, but if we let a working build "ship" with this, don't we have to keep it ~forever? There's honoring compatibility and then there's just being silly. OK, color me "silly" !:) - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/include (commaize_number)
On Tue Mar 15 2011 at 05:33:16 -0700, Paul Goyette wrote: > On Tue, 15 Mar 2011, Antti Kantee wrote: > > >On Tue Mar 15 2011 at 05:25:51 -0700, Paul Goyette wrote: > >>>Module Name:src > >>>Committed By: pooka > >>>Date: Tue Mar 15 12:21:08 UTC 2011 > >>> > >>>Modified Files: > >>> src/include: stdlib.h > >>> > >>>Log Message: > >>>put in a proto for commaize_number() > >>>(nb. doing this purely as the minimum work solution to get a working > >>>build) > >> > >> > >>Maybe we shouldn't fix the build here, since there's also the issue of > >>bumping the minor version of libc which was not done. With a build > >>break we don't have any compatability issues, but if we let a working > >>build "ship" with this, don't we have to keep it ~forever? > > > >There's honoring compatibility and then there's just being silly. > > OK, color me "silly" !:) if you want to be colored with a blue ribbon, there's always the option of backing out the changes -- from what i quickly observed, that's the current consensus and would also address your ("silly" ;) concern. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/include (commaize_number)
In article <20110315123136.gj2...@cs.hut.fi>, Antti Kantee wrote: >On Tue Mar 15 2011 at 05:25:51 -0700, Paul Goyette wrote: >> >Module Name:src >> >Committed By: pooka >> >Date: Tue Mar 15 12:21:08 UTC 2011 >> > >> >Modified Files: >> >src/include: stdlib.h >> > >> >Log Message: >> >put in a proto for commaize_number() >> >(nb. doing this purely as the minimum work solution to get a working build) >> >> >> Maybe we shouldn't fix the build here, since there's also the issue of >> bumping the minor version of libc which was not done. With a build >> break we don't have any compatability issues, but if we let a working >> build "ship" with this, don't we have to keep it ~forever? > >There's honoring compatibility and then there's just being silly. Remove it; there is %' christos
Re: CVS commit: src/include (commaize_number)
On Tue Mar 15 2011 at 05:25:51 -0700, Paul Goyette wrote: > >Module Name:src > >Committed By: pooka > >Date: Tue Mar 15 12:21:08 UTC 2011 > > > >Modified Files: > >src/include: stdlib.h > > > >Log Message: > >put in a proto for commaize_number() > >(nb. doing this purely as the minimum work solution to get a working build) > > > Maybe we shouldn't fix the build here, since there's also the issue of > bumping the minor version of libc which was not done. With a build > break we don't have any compatability issues, but if we let a working > build "ship" with this, don't we have to keep it ~forever? There's honoring compatibility and then there's just being silly. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
RE: CVS commit: src/include (commaize_number)
Module Name:src Committed By: pooka Date: Tue Mar 15 12:21:08 UTC 2011 Modified Files: src/include: stdlib.h Log Message: put in a proto for commaize_number() (nb. doing this purely as the minimum work solution to get a working build) Maybe we shouldn't fix the build here, since there's also the issue of bumping the minor version of libc which was not done. With a build break we don't have any compatability issues, but if we let a working build "ship" with this, don't we have to keep it ~forever? - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/include
In article <20110216211601.ga24...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Wed, Feb 16, 2011 at 02:29:36PM -0500, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Wed Feb 16 19:29:35 UTC 2011 >> >> Modified Files: >> src/include: rmt.h >> >> Log Message: >> handle ssp >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.6 -r1.7 src/include/rmt.h > >Can we please stop adding even more cludges for this? I wish, please show a better way. christos
Re: CVS commit: src/include
On Wed, Feb 16, 2011 at 02:29:36PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Wed Feb 16 19:29:35 UTC 2011 > > Modified Files: > src/include: rmt.h > > Log Message: > handle ssp > > > To generate a diff of this commit: > cvs rdiff -u -r1.6 -r1.7 src/include/rmt.h Can we please stop adding even more cludges for this? Joerg
Re: CVS commit: src/include
On Wed, 20 Oct 2010 17:00:21 + David Holland wrote: > On Mon, Sep 06, 2010 at 10:52:27AM -0400, Christos Zoulas wrote: > > Modified Files: > >src/include: stdio.h > > > > Log Message: > > Add dprintf and vdprintf. XXX: Might ifdef it if too many things break. > > whose bright POSIX idea was it to not call this "fdprintf" (which is > what everyone's always called this operation in the past) and can we > thwack them? i guess this is the reason: to avoid namespace clash :) -- NetBSD - Simplicity is prerequisite for reliability
Re: CVS commit: src/include
In article <20101020170021.ga20...@netbsd.org>, David Holland wrote: >On Mon, Sep 06, 2010 at 10:52:27AM -0400, Christos Zoulas wrote: > > Modified Files: > > src/include: stdio.h > > > > Log Message: > > Add dprintf and vdprintf. XXX: Might ifdef it if too many things break. > >whose bright POSIX idea was it to not call this "fdprintf" (which is >what everyone's always called this operation in the past) and can we >thwack them? I am sure he is blushing in some corner as she/he reads this. christos
Re: CVS commit: src/include
On Mon, Sep 06, 2010 at 10:52:27AM -0400, Christos Zoulas wrote: > Modified Files: > src/include: stdio.h > > Log Message: > Add dprintf and vdprintf. XXX: Might ifdef it if too many things break. whose bright POSIX idea was it to not call this "fdprintf" (which is what everyone's always called this operation in the past) and can we thwack them? -- David A. Holland dholl...@netbsd.org