Dne Ne 13. prosince 2009 06:36:47 David Brownell napsal(a):
On Saturday 12 December 2009, Marek Vasut wrote:
Also, can you restructure it so that you don't just add a bit
if (there's a custom erase_page) { ... }? That's the sort
of thing which is easier to just require.
Require?
On Sun, Dec 13, 2009 at 12:13 AM, Carsten Breuer
carstenbreueropen...@textwork.de wrote:
Hi all,
treat warning as errors (-wall) is a fine thing but sometimes breaks
the build..
This is a good thing to have as a default behavior, we want warning
fixes fed back. It cleans up the code and
Øyvind Harboe a écrit :
On Sun, Dec 13, 2009 at 12:13 AM, Carsten Breuer
carstenbreueropen...@textwork.de wrote:
Hi all,
treat warning as errors (-wall) is a fine thing but sometimes breaks
the build..
This is a good thing to have as a default behavior, we want warning
fixes fed back.
On Sun, Dec 13, 2009 at 2:45 PM, Albert ARIBAUD albert.arib...@free.fr wrote:
Øyvind Harboe a écrit :
On Sun, Dec 13, 2009 at 12:13 AM, Carsten Breuer
carstenbreueropen...@textwork.de wrote:
Hi all,
treat warning as errors (-wall) is a fine thing but sometimes breaks
the build..
This
Øyvind Harboe a écrit :
-Wall is the minimum that should be applied to source code. Running it
through Splint (or some other verification tool) would not hurt either.
Is there an open source lint tool that's worthwhile to use?
Did you try splint on OpenOCD?
Apart from Splint, I haven't
Øyvind Harboe a écrit :
On Sun, Dec 13, 2009 at 3:04 PM, Albert ARIBAUD albert.arib...@free.fr
wrote:
Øyvind Harboe a écrit :
-Wall is the minimum that should be applied to source code. Running it
through Splint (or some other verification tool) would not hurt either.
Is there an open
Albert ARIBAUD a écrit :
Also note splint has not been updated for a long time, as I discovered
when going to its home site.
There are some alternatives mentioned on Wikipedia:
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#C
I like clang's way of reporting errors,
their cvs has been updated according to sourceforge somewhat recently.
they haven't done a release in two years, though.
On 12/13/09, Albert ARIBAUD albert.arib...@free.fr wrote:
Øyvind Harboe a écrit :
On Sun, Dec 13, 2009 at 3:04 PM, Albert ARIBAUD albert.arib...@free.fr
wrote:
Øyvind
On Sunday 13 December 2009, Marek Vasut wrote:
Either provide the
current logic in a separate routine that gets patched into the
ops vector of any driver that doesn't have it, or ...
We can do so in one go in a separate patch if you want to do this kind of
cleanup. That'd be
Don't include helper/jim.h from target.h ... not everything
which touches targets needs to be able to talk to Jim. Also,
most files include this header by another path.
Also, switch the affected files to use the classic sequence
for #included files: all framework/headers.h first, then
the
Make these .h files adopt the same policy the .c files already
follow: don't use subsystem/...h syntax for private interfaces.
If we ever get reviewed/supported public interfaces they should
come exclusively from some include/... directory.
---
src/target/arm.h |2 +-
-Wall is the minimum that should be applied to source code. Running
it through Splint (or some other verification tool) would not hurt
either.
That's true. Nonetheless some people are too lazy to make
a distclean first ;-). Splint is t buggy to use it.
At work we use pclint from gimple
Hi Michael, hi all
There is setedit that uses gdb. I haven't tried the one on windows
Cool :-). Looks like Borland C++ 3.1, that i have used
some decades ago with DOS 5.0 :-))). Since i use midnight commander
a lot, this is really an option :-).
kdbg would be nicer. insight sucks. If someone
On Sun, Dec 13, 2009 at 09:53:42PM +0100, Carsten Breuer wrote:
What I dislike most:
Missing brackets:
if (FOO_BAR)
do_something
It should be
if (FOO_BAR)
{
do:something
}
because if do_something is defined like follows:
#define do_something a=10; b = 20;
Then
You could also argue that the do_something definition is buggy,
since it's not one statement.
Correct. But if you use brackets the code do what you want and
you get the result what you expect. Lint complains about
both.
E.g. the Linux kernel takes this stance, and wraps such macros in do
{ }
On Sun, Dec 13, 2009 at 10:29:36PM +0100, Carsten Breuer wrote:
You could also argue that the do_something definition is buggy,
since it's not one statement.
Correct. But if you use brackets the code do what you want and
you get the result what you expect.
Sure, but if you use brackets
On Sunday 13 December 2009, Carsten Breuer wrote:
http://en.wikipedia.org/wiki/MISRA
So if you have access to MISRA tools and specifications,
which aren't exactly public ... are you intending to submit
any patches to address related issues? Or maybe at least post
the results of some MISRA
On Sunday 13 December 2009, Carsten Breuer wrote:
What I dislike most:
Missing brackets:
if (FOO_BAR)
do_something
It should be
if (FOO_BAR)
{
do:something
}
For the record: I dislike the superfluous brackets.
As Lennart noted, wasting vertical space is not good.
That's
Add a -ignore-version to jtag newtap which makes the IDCODE
comparison logic optionally ignore version differences.
Update the scan_chain command to illustrate this by showing
a * character instead of the (ignored) version nibble.
---
Various folk have mentioned this idea, and I figured it would
On Sunday 13 December 2009, Benjamin Schmidt wrote:
Not sure if interesting to anyone, but I just ran svn head againt cppcheck...
Much more relevant to see it against current git.
The SVN tree is obsolete, nobody should be using it...
___
On Sunday 13 December 2009, David Brownell wrote:
On Sunday 13 December 2009, Benjamin Schmidt wrote:
Not sure if interesting to anyone, but I just ran svn head againt
cppcheck...
Much more relevant to see it against current git.
And to clarify why: several of those path names no longer
On Sun, Dec 13, 2009 at 11:41 PM, David Brownell davi...@pacbell.net wrote:
On Sunday 13 December 2009, Benjamin Schmidt wrote:
Not sure if interesting to anyone, but I just ran svn head againt cppcheck...
Much more relevant to see it against current git.
The SVN tree is obsolete, nobody
On Monday 30 November 2009, Øyvind Harboe wrote:
I believe the problem with iMX31 is that it misbehaves after receiving
a TAP reset...
I tried restoring the workaround for that (TLR) and added a comment
about that being IMX-specific. Could you give this patch a try?
- dave
Hi David, hi all,
first of all i have to say that it was not my intention to upset
the developers here. Sorry. I was very happy that you
fix the R13_svc bug in the second i had report it..
I agree. Nonetheless this error shouldn't occur in the official
snapshot on the website.
I must have
On Sun, 2009-12-13 at 15:49 -0800, David Brownell wrote:
[snip]
Note that MISRA is not universally lauded. As I understand, some of
its practices are contrary to other widely adopted coding policies.
Sure. Some points are a laugh like a null pointer should not be
dereferenced.
Dne Ne 13. prosince 2009 21:06:32 David Brownell napsal(a):
On Sunday 13 December 2009, Marek Vasut wrote:
Either provide the
current logic in a separate routine that gets patched into the
ops vector of any driver that doesn't have it, or ...
We can do so in one go in a
On Sunday 13 December 2009, Zach Welch wrote:
On Sun, 2009-12-13 at 15:49 -0800, David Brownell wrote:
[snip]
Note that MISRA is not universally lauded. As I understand, some of
its practices are contrary to other widely adopted coding policies.
Sure. Some points are a laugh
On Sunday 13 December 2009, Marek Vasut wrote:
I'd send followup patch that'd clean that mess up altogether ... it's cleaner
and much easier to track back in git log.
Go for it then. :)
___
Openocd-development mailing list
On Sunday 13 December 2009, David Brownell wrote:
I admit that when I first came across it, the don't check for NULL
philosophy seemed pretty wrong. But, quite a few years later on, now
I see that it's quite effective. The it's wrong argument is on micro
scales. The it's right one is macro
Carsten Breuer a écrit :
Debugging was once cool with real emulators, with jtag, bdm or whatever,
it always sucks a bit.
Best Regards,
Carsten
I dislike the emulators. At work I have some projects with a Fujitsu
processor and when I debug I need the $15k emulator
to connect to the
On Sunday 13 December 2009, Michel Catudal wrote:
I think that once OpenOCD is optimized it should work just as nice on
the ARM (except for the lack of breakpoints)
Recent ARMs don't share the just two breakpoint/watchpoint units
restriction of ARM7/ARM9 EmbeddedICE.
Example, Cortex A8 and
One of the common threads there is needing to have a handle on
just how common an error is before choosing strategies for
dealing with it.
I did a pass of OpenOCD in the early days where I fixed
all the error paths for malloc() where malloc() was greater than
a few bytes. I have no evidence
On Mon, Dec 14, 2009 at 5:44 AM, David Brownell davi...@pacbell.net wrote:
On Sunday 13 December 2009, Michel Catudal wrote:
I think that once OpenOCD is optimized it should work just as nice on
the ARM (except for the lack of breakpoints)
Recent ARMs don't share the just two
33 matches
Mail list logo
