missing methods in inttypes.h

[Joel Sherrill]

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:
>>>> Hi
>>>>
>>>> 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.
>
> Corinna
>


-- 
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