[PATCH v2 2/2] break fenv.c file to function files

[Sebastian Huber]

On 27/07/2020 08:58, Eshan Dhawan wrote:

>> On 27-Jul-2020, at 12:00 PM, Sebastian Huber<sebastian.huber at embedded-brains.de>  wrote:
>>
>> On 27/07/2020 08:11, Eshan Dhawan wrote:
>>
>>>>> diff --git a/newlib/libc/machine/arm/sys/fenv.h b/newlib/libc/machine/arm/sys/fenv.h
>>>>> index 70bd57be4..8712b2f33 100644
>>>>> --- a/newlib/libc/machine/arm/sys/fenv.h
>>>>> +++ b/newlib/libc/machine/arm/sys/fenv.h
>>>>> @@ -62,6 +62,14 @@ typedef int fexcept_t;
>>>>>   #define    FE_DOWNWARD        0x00800000
>>>>>   #define    FE_TOWARDZERO        0x00c00000
>>>>>   +#ifndef __SOFTFP__
>>>>> +#define    vmrs_fpscr(__r)    __asm __volatile("vmrs %0, fpscr" : "=&r"(__r))
>>>>> +#define    vmsr_fpscr(__r)    __asm __volatile("vmsr fpscr, %0" : : "r"(__r))
>>>>> +#define    _FPU_MASK_SHIFT    8
>>>>> +#define    _ROUND_MASK    (FE_TONEAREST | FE_DOWNWARD | \
>>>>> +             FE_UPWARD | FE_TOWARDZERO)
>>>>> +#endif
>>>>> +
>>>> I would still prefer to have this in an internal header file "newlib/libm/machine/arm/_fenv.h" which is included via #include "_fenv.h".
>>>>
>>>> If you really want to have it visible via <fenv.h>, then the vm*() should at least be renamed to _vmrs_fpscr() and _vmsr_fpscr().
>>>>
>>> I am not able to get you point could you provide a little detail
>>> I understood that you are saying that create an alternative _fenv.h in machine/arm in libm.
>>> But I am not able to understand why.
>>> If the symbols are visible with fenv.h than does that cause any issues?
>> Yes, this is a header file which is included in the C and POSIX standards. It should only provide the things covered in the standards. The general convention is to reserve all names starting with an underscore for the C library implementation and operating system use. For example:
>>
>> https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html
>>
>>> Or how does renaming them causes any change?
>> It moves the names to the reserved name space.
> I will add the changes and send a patch ASAP

Ok, good. I will test it and then push it to Newlib if everything is all 
right:

https://sourceware.org/pipermail/newlib/2020/017791.html