[PATCH] libstdc++: Rename __null_terminated to avoid collision with Apple SDK

[PATCH] libstdc++: Rename __null_terminated to avoid collision with Apple SDK

[Mark Mentovai]

The macOS 13 SDK (and equivalent-version iOS and other Apple OS SDKs)
contain this definition in <sys/cdefs.h>:

863  #define __null_terminated

This collides with the use of __null_terminated in libstdc++'s
experimental fs_path.h.

As libstdc++'s use of this token is entirely internal to fs_path.h, the
simplest workaround, renaming it, is most appropriate. Here, it's
renamed to __nul_terminated, referencing the NUL ('\0') value that is
used to terminate the strings in the context in which this tag structure
is used.

libstdc++-v3/ChangeLog:

	* include/experimental/bits/fs_path.h: Rename __null_terminated
	to __nul_terminated avoid colliding with a macro in Apple's SDK.

Signed-off-by: Mark Mentovai <mark@mentovai.com>
---
 libstdc++-v3/include/experimental/bits/fs_path.h | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libstdc++-v3/include/experimental/bits/fs_path.h b/libstdc++-v3/include/experimental/bits/fs_path.h
index b0825ba76e80..19d246100cb5 100644
--- a/libstdc++-v3/include/experimental/bits/fs_path.h
+++ b/libstdc++-v3/include/experimental/bits/fs_path.h
@@ -140,10 +140,10 @@ namespace __detail
     inline _Source
     _S_range_begin(_Source __begin) { return __begin; }
 
-  struct __null_terminated { };
+  struct __nul_terminated { };
 
   template<typename _Source>
-    inline __null_terminated
+    inline __nul_terminated
     _S_range_end(_Source) { return {}; }
 
   template<typename _CharT, typename _Traits, typename _Alloc>
@@ -459,11 +459,11 @@ namespace __detail
       struct _Cvt;
 
     static string_type
-    _S_convert(value_type* __src, __detail::__null_terminated)
+    _S_convert(value_type* __src, __detail::__nul_terminated)
     { return string_type(__src); }
 
     static string_type
-    _S_convert(const value_type* __src, __detail::__null_terminated)
+    _S_convert(const value_type* __src, __detail::__nul_terminated)
     { return string_type(__src); }
 
     template<typename _Iter>
@@ -477,7 +477,7 @@ namespace __detail
 
     template<typename _InputIterator>
       static string_type
-      _S_convert(_InputIterator __src, __detail::__null_terminated)
+      _S_convert(_InputIterator __src, __detail::__nul_terminated)
       {
 	auto __s = _S_string_from_iter(__src);
 	return _S_convert(__s.c_str(), __s.c_str() + __s.size());
@@ -504,7 +504,7 @@ namespace __detail
 
     template<typename _InputIterator>
       static string_type
-      _S_convert_loc(_InputIterator __src, __detail::__null_terminated,
+      _S_convert_loc(_InputIterator __src, __detail::__nul_terminated,
 		     const std::locale& __loc)
       {
 	const std::string __s = _S_string_from_iter(__src);
-- 
2.36.1

Re: [PATCH] libstdc++: Rename __null_terminated to avoid collision with Apple SDK

[Jonathan Wakely]

On Fri, 10 Jun 2022 at 21:12, Mark Mentovai  wrote:
>
> The macOS 13 SDK (and equivalent-version iOS and other Apple OS SDKs)
> contain this definition in <sys/cdefs.h>:
>
> 863  #define __null_terminated
>
> This collides with the use of __null_terminated in libstdc++'s
> experimental fs_path.h.
>
> As libstdc++'s use of this token is entirely internal to fs_path.h, the
> simplest workaround, renaming it, is most appropriate. Here, it's
> renamed to __nul_terminated, referencing the NUL ('\0') value that is
> used to terminate the strings in the context in which this tag structure
> is used.
>
> libstdc++-v3/ChangeLog:
>
>         * include/experimental/bits/fs_path.h: Rename __null_terminated
>         to __nul_terminated avoid colliding with a macro in Apple's SDK.
>
> Signed-off-by: Mark Mentovai <mark@mentovai.com>

Thanks for the patch. The change makes sense so I'll get it committed.
Is this change needed on the release branches too?

Just to be sure, could you please confirm that your Signed-off-by: tag
is to certify you agree with the DCO at https://gcc.gnu.org/dco.html
(and not just something you're doing because you've seen others doing
it :-)

Thanks again.

Re: [PATCH] libstdc++: Rename __null_terminated to avoid collision with Apple SDK

[Mark Mentovai]

Thanks, Jonathan. I am, in fact, so certifying.

I do believe that bringing up support for new OS versions is in scope for
open branches, and it makes sense to merge, particularly for a trivial and
uncontentious patch like this one.

Jonathan Wakely wrote:

> On Fri, 10 Jun 2022 at 21:12, Mark Mentovai  wrote:
> >
> > The macOS 13 SDK (and equivalent-version iOS and other Apple OS SDKs)
> > contain this definition in <sys/cdefs.h>:
> >
> > 863  #define __null_terminated
> >
> > This collides with the use of __null_terminated in libstdc++'s
> > experimental fs_path.h.
> >
> > As libstdc++'s use of this token is entirely internal to fs_path.h, the
> > simplest workaround, renaming it, is most appropriate. Here, it's
> > renamed to __nul_terminated, referencing the NUL ('\0') value that is
> > used to terminate the strings in the context in which this tag structure
> > is used.
> >
> > libstdc++-v3/ChangeLog:
> >
> >         * include/experimental/bits/fs_path.h: Rename __null_terminated
> >         to __nul_terminated avoid colliding with a macro in Apple's SDK.
> >
> > Signed-off-by: Mark Mentovai <mark@mentovai.com>
>
> Thanks for the patch. The change makes sense so I'll get it committed.
> Is this change needed on the release branches too?
>
> Just to be sure, could you please confirm that your Signed-off-by: tag
> is to certify you agree with the DCO at https://gcc.gnu.org/dco.html
> (and not just something you're doing because you've seen others doing
> it :-)
>
> Thanks again.
>
>

Re: [PATCH] libstdc++: Rename __null_terminated to avoid collision with Apple SDK

[Jonathan Wakely]

On Fri, 10 Jun 2022 at 22:42, Mark Mentovai wrote:
>
> Thanks, Jonathan. I am, in fact, so certifying.

Great, thanks.

>
> I do believe that bringing up support for new OS versions is in scope for open branches, and it makes sense to merge, particularly for a trivial and uncontentious patch like this one.

Agreed. I've pushed it to trunk for now and will follow up with the
backports soon.

Thanks again for the patch.