missing methods in inttypes.h
Thu Aug 1 18:03:00 GMT 2013
On 7/30/2013 10:57 AM, Corinna Vinschen wrote:
> On Jul 30 09:00, Joel Sherrill wrote:
>> On 7/30/2013 4:13 AM, Corinna Vinschen wrote:
>>> On Jul 29 09:14, Joel Sherrill wrote:
>>>> I am curious where the missing methods from inttypes.h
>>>> should go (eventually) in the source tree?
>>>> intmax_t imaxabs(intmax_t);
>>>> imaxdiv_t imaxdiv(intmax_t, intmax_t);
>>>> intmax_t strtoimax(const char *restrict, char **restrict, int);
>>>> uintmax_t strtoumax(const char *restrict, char **restrict, int);
>>>> intmax_t wcstoimax(const wchar_t *restrict, wchar_t **restrict, int);
>>>> uintmax_t wcstoumax(const wchar_t *restrict, wchar_t **restrict, int);
>>> For Cygwin, they are just aliases of the respective method using the
>>> biggest available datatype:
>>> imaxabs = llabs
>>> imaxdiv = lldiv
>>> strtoimax = strtoll
>>> strtoumax = strtoull
>>> wcstoimax = wcstoll
>>> wcstoumax = wcstoull
>>> In theory, every target can handle it that way without the need
>>> to implement these functions explicitely.
>> When you say aliases, do you mean just wrapper methods?
>> Can the Cygwin versions be merged into newlib so every newlib target
>> has these?
> The current Cygwin method can't be folded into newlib because it
> uses ld's DEF file facility which is Windows-specific.
> However, what we could do in newlib is either adding #defines as in
> #define strtoimax strtoll
> etc., or we could use symbol aliases as in
> #define EXPORT_ALIAS(sym,symalias) extern "C" __typeof (sym) symalias __attribute__ ((alias(#sym)));
> strtoll ()
> EXPORT_ALIAS (strtoll, strtoimax)
> We use this in Cygwin as well in some cases.
Would a simple #define like this be acceptable?
#define imaxabs( _j ) (intmax_t) llabs( _j )
I have a few concerns:
+ Would these end up being typed correctly? Could we accidentally
cover up incorrect type usage?
+ What about the documentation for these methods? Without a
body, where would that go?
+ Are these methods visible based on the same standards/features
conditionals? Otherwise, the macros don't expand to visible methods.
>> FWIW when I looked at FreeBSD, the few I looked at had their own
>> real implementations which were not wrappers. I can see that wrapping
>> the largest type is OK though.
> It's also better for small targets if there's only one implementation,
> I think.
I agree but don't want to lose type safety.
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the Newlib