On 21 October 2014 17:29, Jonathan Wakely <jwak...@redhat.com> wrote: >> +typedef typeof (((tm*)0)->tm_sec) __tm_small_int; > > > I think this should probably use __typeof__ to work with > -Wpedantic-errors
Ok, makes sense, and it's a straightforward change. > >> +#else /* For 100% mangling compatibility, use int directly. */ >> +#define __tm_small_int int >> +#endif > > > I'd prefer to always use a typedef, which can be a private member of > std::time_get, instead of defining a macro (even a macro using a > reserved name). Is the typedef mangling compatible with the original "int" type? >> /** >> * @brief Time format ordering data. >> * @ingroup locales >> @@ -654,14 +663,16 @@ namespace std _GLIBCXX_VISIBILITY(defaul >> ios_base::iostate& __err, tm* __tm) const; >> >> // Extract numeric component of length __len. >> + template <typename _Member_t> >> iter_type >> - _M_extract_num(iter_type __beg, iter_type __end, int& __member, >> + _M_extract_num(iter_type __beg, iter_type __end, _Member_t& >> __member, >> int __min, int __max, size_t __len, >> ios_base& __io, ios_base::iostate& __err) const; > > > I think this function is exported from the library, so turning it into > a template would be an ABI change. The avr needs both an int and and int8_t __member variant of M_extract_num. So do template instantiations mangle differently from directly defined functions? In that case, what is the preferred solution? Duplicate the code (with all the maintenance ugliness that entails)? Or convert the function definition into an uber-ugly macro that is invoked twice to get what the template implementation denies us - metaprogramming with mangling compatibility? Define a templated function with a different name, and then define two _M_extract_num overloads as a wrapper? Does that even work in the case __tm_small_int is a typedef for int?
