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

[Breeze, David]

Just to make clear for some of us all code must be passed through Lint as part 
of our procedures and any exclusions have to be justified.
The avr compiler though very good does bring up a number of "errors" which have 
to be optioned out some because of the unusual bracketing used in the compiler.
 A sample of Lint exceptions due to the compiler is shown below.  (This is the 
Gimpel PC-Lint referred to by David Brown).
It should also be remembered that compiler versions tend to have a long life, 
in industry, as updating has quality on our backs wanting justification and 
proof that the updated compiler is suitable for the job.
Keep up the good work, it's much appreciated.

David

-esym(1065, __vector_?,  __vector_??)                                           
                // Not declared as 'C'  (For __vector_n())
-esym(762, __vector_?, __vector_??)                                             
                // Redundant declaration  (For __vector_n())
-esym(765, __vector_?, __vector_??, start_of_pool, timebaseTicksFromStart)      
// Could be made static  (For __vector_n())
-esym(714, __vector_?, __vector_??)                                             
                // Not referenced  (For __vector_n())
-esym(551, pwm)                                                         // Not 
accessed (not true Lint just can't discern use)
-esym(950, _to_brackets, _to_semi)


// Compiler macros
//-emacro(40, __asm__, cli, sei, cbi, sbi, bit_is_set, bit_is_clear, 
loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV)
//-emacro(10, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, 
loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV)
-emacro(123, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, 
loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV)
//-emacro(522, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, 
loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV)
//-emacro(515, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, 
loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV)
//-emacro(523, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, 
loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV)
//-emacro(911, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, 
loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV)
//-emacro(923, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, 
loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV)

// Register macros specified for compiler
-emacro(915, OCR??, TCCR??, TCNT?, ETIMSK, ETIFR, PORT?, PORT??, PIN?, PIN??)
-emacro(921, OCR??, TCCR??, TCNT?, ETIMSK, ETIFR, PORT?, PORT??, PIN?, PIN??)
-emacro(923, OCR??, TCCR??, TCNT?, ETIMSK, ETIFR, PORT?, PORT??, PIN?, PIN??)
-emacro(925, OCR??, TCCR??, TCNT?, ETIMSK, ETIFR, PORT?, PORT??, PIN?, PIN??)




-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of David Brown
Sent: 01 November 2011 08:50
To: Georg-Johann Lay
Cc: address@hidden
Subject: Re: [avr-libc-dev] [bug #34695] fixed width int types without 
__attribute__()

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


_______________________________________________
AVR-libc-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev


This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
an addressing or transmission error has misdirected this e-mail, please notify 
the author by replying to this e-mail. If you are not the intended recipient 
you must not use, disclose, copy, print or rely on this e-mail.

We may monitor outgoing and incoming e-mails and other telecommunications on 
our e-mail and telecommunication systems in line with current legislation. We 
have taken steps to ensure that this email and attachments are free from any 
virus, but it remains your responsibility to ensure that viruses do not 
adversely affect you.

Joy Mining Machinery Limited. Registered number 02546087.
Registered address: Bromyard Road, Worcester, WR2 5EG. Telephone: (0870) 
252-1000
Nottingham Branch: Kirkby Lane, Pinxton, Nottinghamshire, NG16 6HX. Telephone: 
(0870) 252-5000
Wigan Branch: Seaman Works, PO BOX 12, Seaman Way, Ince, Wigan, Lancashire, WN1 
3DD Telephone: (0870) 252-6000


P&H Mining Equipment (UK) Limited. Registered number 02484112.
Registered address: Seaman Works, PO BOX 12, Seaman Way, Ince, Wigan, 
Lancashire, WN1 3DD. Telephone: (0870) 252-4400


Continental Conveyor Limited. Registered number 03586316.
Registered address: West Quay Road, Sunderland Enterprise Park, Sunderland, 
Tyne & Wear, SR5 2TD. Telephone: (0191) 516-5353


The above mentioned Companies are registered in England and Wales.

Privacy