Re: [atlas-devel] anybody know of need for C89 compliance?

[R. C. W. <rcw...@ls...>]

Andrew,

On 01/14/2017 03:11 PM, Andrew Reilly wrote:
> Hi Clint,
>
> The two compilers with least support for c99 features that I'm aware of are MSVC and TI CodeComposer.  Both have most of the support for C99 library features, but both (being primarily C++ compilers) don't have good support for the C99 language features that aren't in C++.
>
> So: you'll find // comments everywhere.
> You'll need a macro to define inline _inline on some systems.
> You'll need a macro to define ATLAS_RESTRICT _restrict on at least MSVC.  Alas you can't actually use or redefine the keyword "restrict", because that is already a magic keyword used in the Windows header files, and some other Windows magic compilation directives.
> I'm fairly sure that modern versions of MSVC support long long int and %llu, although you might have to spell the former as __int64 on some versions.
> You will need a macro to define snprintf to _snprintf on MSVC, and you'll need to define _CRT_SECURE_NO_WARNINGS before including any of the standard headers to turn off the deprecation warnings.
>
> I haven't tried to use _Complex or _Thread_local myself.  I have a memory of _Atomic being supported in many places though.  I expect that the others are too.
>

Thank you very much for this!  It looks like I can't really change much 
about ATLAS's C use, other than allowing myself to use // then.  Of my 
proposed list, only this and the safe string functions were things that 
would immediately make my life a lot better, so lack of snprintf support 
is the only real disappointment.

Unfortunately, I can't just macro my way around this lack: supporting 
both snprintf and sprintf doubles all my string handling code, which I'm 
unwilling to do from a code maintenance perspective, so I'll just 
continue with my present C89 behavior there :(

Since I have a soft dependence on gcc for the install, I could still 
switch to snprintf, but the fact that MSVC doesn't support it still 
means I'm less confident that no embedded system has only 1 compiler 
that doesn't support snprintf, and for which modern gcc is not ported, 
so I'll not switch to snprint.

For anyone concerned about security here: The string handling doesn't 
wind up in the ATLAS library, so it's not really a matter for user 
security. I do a lot of string handling during the tuning and generation 
stages, which would either be vastly simplified or made less likely to 
segfault using snprints, which is why I would have liked to make the change.

On the long long type name, I'm already using a macro that can be 
changed to another name, but I had no way to print out such values in 
C89, even though many compilers supported the type, so the fact that llu 
will work is good.

Many thanks,
Clint

> Cheers,
>
> Andrew Reilly
> M: 0409-824-272
> ar...@bi...
>
>
>
>> On 15 Jan 2017, at 04:35 , R. Clint Whaley <rcw...@ls...> wrote:
>>
>> Guys,
>>
>> In the developer release, I am considering relaxing ATLAS's present
>> strict adherence to ANSI/ISO 9899-1990 standard, so that I can assume
>> stuff from C99.  Frankly, the lack // is slowly killing me.
>>
>> Right now, any C99 features are enabled only by macros that can be shut
>> off.
>>
>> There is little benefit aside from  aesthetics to this (though safe
>> string ops would be *so* nice), so I don't want to do it if anybody
>> reports using a compiler that doesn't support these features, but I'm
>> thinking that while their might still be some compilers w/o full C99
>> support, they'll all have the features I most want to add.
>>
>> Here's the list of things I'd definitely like to assume support for that
>> I think all compilers support (even likely obscure ones on embedded
>> systems):
>>    // style comments
>>    inline
>>    restrict
>>    long long int, %llu
>>    Safe string operations, like snprintf (this lack is painful)
>>
>> In addition there are more advanced features that might be useful, but
>> I'm not sure if I can count on them being universally available:
>>    _Complex support
>>    _Atomic
>>    _Thread_local
>>
>> Does anyone have comments on this idea?
>>
>> Thanks,
>> Clint
>>
>> --
>> **********************************************************************
>> ** R. Clint Whaley, PhD * Assoc Prof, LSU * www.csc.lsu.edu/~whaley **
>> **********************************************************************
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> Math-atlas-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/math-atlas-devel
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Math-atlas-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/math-atlas-devel
>

-- 
**********************************************************************
** R. Clint Whaley, PhD * Assoc Prof, LSU * www.csc.lsu.edu/~whaley **
**********************************************************************