[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribut
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Tue, 01 Nov 2011 09:49:48 +0100
Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
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
so you could just do
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")))
#elif __INT_MAX__ == 32767
typedef signed int int16_t;
typedef signed long int32_t;
or is there a reason why that do not work?
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
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
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
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.
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
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.
- Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__(),
David Brown <=