[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: max_align_t fails with clang 6.1 on OS X 10.10
From: |
Bruno Haible |
Subject: |
Re: max_align_t fails with clang 6.1 on OS X 10.10 |
Date: |
Sun, 03 Sep 2017 18:11:42 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-93-generic; KDE/5.18.0; x86_64; ; ) |
Werner, Paul,
I wrote:
> The other approaches are brittle: If we/you change something regarding
> the max_align_t problem, you will continue to see issues
> - on other platforms,
> - when you request additional gnulib modules,
> - when the C standard features change,
> - when the C++ standard features change.
>
> Among these other approaches are the following:
>
> * You could add gnulib module 'std-gnu11' to the list of gnulib modules
> you request. This has the chance of fixing other problems than the
> max_align_t one, because C++ is closer to C11 than it is to C99.
> But still, newer C or C++ standard can bring new problems.
>
> * Gnulib could add a dependency from 'stddef' to 'std-gnu11'. I reject
> this idea because this is a big change that affects all users, for a
> situation that is not supported.
>
> * Gnulib could test something like
> HAVE_MAX_ALIGN_T || (defined(__APPLE__) && defined(__MACH__) &&
> defined(__cplusplus))
> instead of
> HAVE_MAX_ALIGN_T
> This is not such a big change, but it is brittle code, may only fix
> the max_align_t problem, and is for a situation that is not supported.
There is also the approach that we, in gnulib, usually employ when we have a
"typedef redefinition" error:
diff --git a/lib/stddef.in.h b/lib/stddef.in.h
index 2a11d2b..619f224 100644
--- a/lib/stddef.in.h
+++ b/lib/stddef.in.h
@@ -102,7 +102,8 @@ typedef union
double __d _GL_STDDEF_ALIGNAS (double);
long double __ld _GL_STDDEF_ALIGNAS (long double);
long int __i _GL_STDDEF_ALIGNAS (long int);
-} max_align_t;
+} _gl_max_align_t;
+#define max_align_t _gl_max_align_t
#endif
# endif /* address@hidden@_STDDEF_H */
This one is not brittle and is not a big change. If Paul agrees, I would commit
this, and you (Werner) would not need to reorganize your package's
configuration.
Bruno