Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()

[David Brown]

On 31/10/2011 22:29, Georg-Johann Lay wrote:
> Bob Paddock schrieb:
> > > All this appears to be specific only to some proprietary lint that
> > > unlike gcc doesn't even run everywhere, so not a relevant argument IMHO.
> >
> > It is one of the most common Lints in commercial environments.
>
> But why clutter avr-libc with lint? You will have
> __attribute__((progmem)) from PROGMEM and PSTR macros
> __attribute__((signal)) from ISR macro
> __attribute__((interrupt)) for ISR code
> __attribute__((naked)) for custom startup/ISR bits
> __attribute__((OS_main)) AVR-specific
> __attribute__((OS_task)) AVR-specific
> __attribute__((noinline))
> __attribute__((always_inline))
> __attribute__((noclone))
> __attribute__((const))
> __attribute__((pure))
> __attribute__((noreturn))
>
> so you could just do
> #define __attribute__(...)
> or it's command line equivalent to get rid of all the messages.
>
> BTW: What will (sp)lint to with named address space qualifiers?
> Either it must be able to be told that there is special semantics or you
> end up dirscarding hundreds of potential RAM <-> Flask access failures
> when ignoring the qualifier.
>
> ----
>
> As far as avr-libc and -mint8 is concerned: Instead of messing with
> machine modes, it could do
>
> #if __INT_MAX__ == 127
> typedef signed long int16_t;
> typedef signed int
> __attribute__((deprecated("no int32_t together with -mint8")))
> int32_t;
> ...
> #elif __INT_MAX__ == 32767
> typedef signed int int16_t;
> typedef signed long int32_t;
> ...
> #else
> #error
> #endif
>
> or is there a reason why that do not work?
>
> Johann

For -mint8, can you use "long long int" for int32_t?  If so, it might be 
a better choice.



As for lint, there is currently no general-purpose open source lint 
program that is worth the name.  Splint has its uses, but it's a dead 
project, and has been for many years.  Using it takes a lot of effort - 
you need to fill your code with manual annotations for it to be useful. 
 I don't think it is worth spending much effort trying to make support 
for it.

When I last looked at static analysis tools (which I do every now and 
again), my conclusions were:

Splint is dead - it will never support modern C standards, and certainly 
not C++.

Gimpel PC-Lint is /the/ standard tool in embedded development.  It is 
commercial, but not too expensive for professionals (though the Linux 
version is three times the price!).  It does a good job with unannotated 
code, and a better job with a few annotations.  I don't know how it 
treats gcc-specific features such as __attribute__, or more modern C 
features such as memory spaces.  But it is very much in active 
development, aiming to support C/C++ features that are in current use. 
I tested pclint a few years ago, but don't have a copy.

It would be very useful to test avr-libc with PC-Lint (or equivalently, 
flexlint - their *nix version), and to support it with any required 
#ifdef's in the headers.  But obviously that requires someone with the 
time to do the work, the money to buy a license, and the time to learn 
the tool.


gcc itself is an excellent static error checker - the warnings get more 
powerful and more accurate with each release.  I don't know how many 
warnings avr-libc developers usually use, but if anyone is working on 
static analysis compatibility with avr-libc, the emphasis should be on 
warning-free compilation with most warnings enabled in gcc.


The nearest to an open-source general lint tool is perhaps 
<http://clang-analyzer.llvm.org/>.  It is open source, and under heavy 
development, but it is still a work-in-progress.  No C++ support as yet. 
 It is sponsored by Apple, and thus geared towards Macs and Objective 
C, but aims to be more general purpose.


cppcheck 
<http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page> 
is another open source checker tool.  It is smaller in scope, but seems 
to be good at that job.  A very useful feature of cppcheck is its strong 
integration with IDEs/editors (Code::Blocks, Codelite, and especially 
Eclipse).


There are also several high-end commercial tools, and a whole range of 
special purpose open source tools (such as sparse), but these are seldom 
applicable to avr development.


For my own use, I like /lots/ of warnings in gcc, and Eclipse with 
cppcheck.  Many of the cppcheck checks are already found by Eclipse's 
built-in checker (which is very fast and convenient, but obviously only 
useful if you use Eclipse) and/or gcc - but some checks are still useful.

I haven't found any need to do anything special to get warning-free 
checking using that setup for avr-gcc and avr-libc.  But I haven't tried 
compiling or checking avr-libc itself.

mvh.,

David