Update of bug #34695 (project avr-libc):
Priority: 1 - Later = 9 - Immediate
___
Follow-up Comment #8:
This issue needs to be considered along with other stdint.h changes in bugs
#36571, #35539.
Follow-up Comment #7, bug #34695 (project avr-libc):
FYI, the attached files show avr-gcc's understanding of the C99 types with and
without -mint8
You can use these defines as a blueprint for the stdin.h headers or use them
directly (once a fix for http://gcc.gnu.org/PR46261 is upsteram).
The
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
...@nongnu.org] On Behalf Of David
Brown
Sent: 01 November 2011 08:50
To: Georg-Johann Lay
Cc: avr-libc-dev@nongnu.org
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
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.
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
On Mon 31 Oct 2011 02:04:10 NZDT +1300, Bob Paddock wrote:
Their system won't allow a direct link.
Click on view messages at the bottom left.
There are several related discussions:
Normally it is sufficient to use
++d__attribute__(p)=
And be sure to use '-wlib(1)', not '-wlib(0)'.
That
Follow-up Comment #5, bug #34695 (project avr-libc):
Eric, what changes are you thinking of for better lint-friendliness?
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?34695
___
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.
___
AVR-libc-dev mailing list
-Original Message-
From: Volker Kuhlmann [mailto:invalid.nore...@gnu.org]
Sent: Monday, October 31, 2011 4:16 AM
To: Volker Kuhlmann; Joerg Wunsch; Weddington, Eric; avr-libc-
d...@nongnu.org
Subject: [bug #34695] fixed width int types without __attribute__()
Follow-up Comment
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
URL:
http://savannah.nongnu.org/bugs/?34695
Summary: fixed width int types without __attribute__()
Project: AVR C Runtime Library
Submitted by: vok
Submitted on: Sun 30 Oct 2011 21:06:15 NZDT
Category: Header
Follow-up Comment #2, bug #34695 (project avr-libc):
On a second thought: generally preparing our header files for
being more lint-friendly might be a good idea. Everything
should be wrapped within #ifdef __lint where needed. This
should in particularly consider the commonly used splint
Follow-up Comment #3, bug #34695 (project avr-libc):
The trivial way to deal with lint (its splint incantation or whichever other
one) is to use run lint with -DLINT and to use this in code:
#ifdef LINT
#define __attribute__(discard)
#endif
lint will for sure only grok standard C, which
On Sun, Oct 30, 2011 at 6:37 AM, Volker Kuhlmann
invalid.nore...@gnu.org wrote:
_attribute_
For Gimpel Lint search for _attribute_ here:
http://www.gimpel.com/Discussion.cfm?action=search
Their system won't allow a direct link.
There are several related discussions:
Normally it is sufficient
Update of bug #34695 (project avr-libc):
Severity: 3 - Normal = 1 - Wish
Priority: 5 - Normal = 1 - Later
___
Follow-up Comment #4:
I would also like
25 matches
Mail list logo
