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
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.
On Tue 01 Nov 2011 02:12:17 NZDT +1300, Weddington, Eric wrote:
Eric, what changes are you thinking of for better lint-friendliness?
I was hoping you could tell me. ;-)
Back to me then ;-)
I had already posted my solution. To recap, the problem is parsing
typedef int int8_t
As Volker Kuhlmann wrote:
I had already posted my solution. To recap, the problem is parsing
typedef int int8_t __attribute__((__mode__(__QI__)));
typedef int int16_t __attribute__((__mode__ (__HI__)));
typedef int int32_t __attribute__((__mode__ (__SI__)));
with any
On 01/11/2011 11:28, Joerg Wunsch wrote:
As Volker Kuhlmann wrote:
I had already posted my solution. To recap, the problem is parsing
typedef int int8_t __attribute__((__mode__(__QI__)));
typedef int int16_t __attribute__((__mode__ (__HI__)));
typedef int int32_t
David Brown a écrit:
While I agree with your principle here, I think there is good reason for
changing the typedefs in this case - and nothing to lose. People use
different tools with their code, such as static error checkers,
documentation generators, and smart editors like Eclipse. They
On 01/11/2011 13:10, Georg-Johann Lay wrote:
David Brown a écrit:
While I agree with your principle here, I think there is good reason
for changing the typedefs in this case - and nothing to lose. People
use different tools with their code, such as static error checkers,
documentation
As David Brown wrote:
The other possible issue that springs to mind is debuggers - will
debuggers always be happy with non-standard definitions of the types?
At least GDB apparently doesn't have a problem, and very likely the
AVR Studio (4 5) debuggers neither. Otherwise, we'd already knew
On 01/11/2011 13:45, Joerg Wunsch wrote:
As David Brown wrote:
It is even more ironic that there are already standard definitions in
stdint.h precisely to support tools other than avr-gcc, namely doxygen.
OK, so what's wrong with writing
#if defined(__DOXYGEN__) || defined(LINT)
then?
As David Brown wrote:
That might be okay. However, why not do this:
#if defined(__DOXYGEN__)
#define __attribute__(discard)
#endif
I don't know whether doxygen's preprocessing stage will really work
correctly with that. Otherwise, it might be fine.
A char * can alias any other type,
On 01/11/2011 15:14, Joerg Wunsch wrote:
As David Brown wrote:
That might be okay. However, why not do this:
#if defined(__DOXYGEN__)
#define __attribute__(discard)
#endif
I don't know whether doxygen's preprocessing stage will really work
correctly with that. Otherwise, it might be fine.
URL:
http://savannah.nongnu.org/patch/?7654
Summary: include/delay.h: delay_us 255us without decreasing
resolution
Project: AVR C Runtime Library
Submitted by: mmcx
Submitted on: Втр 01 Ноя 2011 16:10:22
Category: None
URL:
http://savannah.nongnu.org/bugs/?34719
Summary: Check for right build compiler
Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Di 01 Nov 2011 17:08:53 GMT
Category: Build Infrastructure
As Volker Kuhlmann wrote:
I've been trying for 3 days now (incl half a weekend) to get 4.6.2 to
compile and I have to say build instructions are shockingly bad. What
worked for 4.3.3 just wasted 3 days for me.
If you look into the correct (out of the many ;) config.log files,
you'll see the
On Wed 02 Nov 2011 06:16:01 NZDT +1300, Georg-Johann Lay wrote:
I'd suggest not wasting more than one day on a issue.
Good advice. Not work related, so after-hours days. Sometimes I'm
stubborn...
If you cannot solve the
problem in that time, come up and ask; for example in a place like here.
As David Brown wrote:
The reason I questioned the signed char case was from a quotation
from the standards in a stackoverflow question, which suggests that
it only applies to plain char and unsigned char. I don't have a
copy of the standards on-hand to check. It may also be that it
applies
Joerg Wunsch schrieb:
OK, so what's wrong with writing
#if defined(__DOXYGEN__) || defined(LINT)
then?
LINT is the wrong name space; should be
__LINT or _LINT
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
17 matches
Mail list logo
