[Top][All Lists]

[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
>     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 /* 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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]