Re: [Openocd-development] Codecheck

2009-12-17 Thread Carsten Breuer
Hi David, As I understand it, ANSI C says it returns NULL when it can't allocate memory. Anything else would be phenominally rude. You don't follow the thread, right? You don't read the people who said it is a bad idea to check the result ;-)? Alex and some others came up with the point,

Re: [Openocd-development] Codecheck

2009-12-17 Thread Carsten Breuer
Hi Thomas, hi all, This is just wrong. No one wants to malloc() to _always_ terminate the process. As I said, you have to differentiate the cases. Do you read this? http://article.gmane.org/gmane.comp.audio.jackit/19998 We have discussed this already a lot and the plan must be first to get

Re: [Openocd-development] malloc: Thanks for the answers

2009-12-17 Thread Carsten Breuer
Hi all, thanks for the answers and to clear this point. Since the majority votes for check the result, i can start hacking now :-). Best Regards, Carsten ___ Openocd-development mailing list Openocd-development@lists.berlios.de

[Openocd-development] Codecheck

2009-12-16 Thread Carsten Breuer
Hi all, i have done a first quick test with lint over the OpenOcd-Sources (based on commit 74ce435d97ca4f6f81645d755d04123f075aa42b) from today. Lint report a truckload of problems. The first thing i had to learn was, that it is verry uncommon in OpenOCD to check the result of malloc. Here

Re: [Openocd-development] OpenOCD Coding (was broken)

2009-12-16 Thread Carsten Breuer
Hi Øyvind, Of course resources tracking in C++ and exception handling comes to mind as a much more robust solution to such problems. I'm not arguing for using C++, I'm just saying that That's exactly what i thought when i see all the malloc's in OpenOcd. I think, that there are still a

Re: [Openocd-development] Codecheck

2009-12-16 Thread Carsten Breuer
Hi Øyvind, The first thing i had to learn was, that it is verry uncommon in OpenOCD to check the result of malloc. This is a known problem where we gladly accept patches to fix each case. OK, then i will start to fix all the mallocs that are handled not correct yet and where i understand

Re: [Openocd-development] OpenOCD Coding (was broken)

2009-12-16 Thread Carsten Breuer
Hi Dean, ...any plans too switch over to C++? There could be some great base Nooo! Don't start this again! :) Ups. Sorry. It looks like that i have the talent to ask the wrong questions in the wrong group ;-). I was actually just talking with a friend about C++ and virtual tables. We

Re: [Openocd-development] OpenOCD Coding (was broken)

2009-12-16 Thread Carsten Breuer
Hi Øyvind, hi all. Are there any plans too switch over to C++? None. There is no interest amongst the maintainers. We know of no *significant* memory leaks today and we accept patches to fix all malloc() / resource tracking problems. Do you know of any real memory leak(other than missing

Re: [Openocd-development] Codecheck

2009-12-16 Thread Carsten Breuer
Hi Øyvind, OK, then i will start to fix all the mallocs that are handled not correct yet and where i understand what to do if they fail. Great! I think if you do a pass on the *simple* cases and just mark w/todo on the remaining ones that would be *great*. I think it makes sense to split

Re: [Openocd-development] Codecheck

2009-12-16 Thread Carsten Breuer
Hi Øyvind, for number_of_mallocs: { - fix the file - see if it compiles. - create a patch - send it too you. } No. - fix a file(including build it) - commit to local git OK...i have to learn something new. Thanks for the hint. Best Regards, Carsten

Re: [Openocd-development] Codecheck

2009-12-16 Thread Carsten Breuer
Hi Lennert, hi all, While I am of the opinion that git is the greatest thing since sliced bread, I don't think that it is a good idea to require that people learn some VCS they aren't familiar with to contribute to a project. Thanks for your help. I will give git a chance and see how it

Re: [Openocd-development] Codecheck

2009-12-16 Thread Carsten Breuer
Hi Igor, There is an emerging opinion that checking for malloc failures in application code is counterproductive: OK, that is not my point of view ;-). Writing to a zero pointer is allways wrong code, even if we think that someone somewhere would clean up the mess we have created. it is

Re: [Openocd-development] Codecheck

2009-12-16 Thread Carsten Breuer
Hi Amicalement, Nonetheless: Malloc can fail and we have to take care of that. But when it fails, what *can* you do apart from trying to fail as gracefully as possible? And failing gracefully is impossible for an embedded target cross-debugger. Well, on Windows you get a ugly message box

Re: [Openocd-development] OpenOCD Coding (was broken)

2009-12-16 Thread Carsten Breuer
The correct function is selected by the compiler and the overhead is IMO in our area not an issue. In embedded developpment, IMO can be argued to be not precise enough. Well, we talk about the PC-side of an embedded system. So we have more then enough horse power here. The overhead is: On

Re: [Openocd-development] Codecheck

2009-12-16 Thread Carsten Breuer
Hi all, Well, this is really interesting. If we use this, i think it is necessary to use even another name and avoid anything that points to the name malloc to avoid any future discussions about this topic. Perhaps we should use something like: void *allocate_or_exit(size); This would make it

Re: [Openocd-development] Codecheck

2009-12-16 Thread Carsten Breuer
, schrieb Carsten Breuer: Hi all, Well, this is really interesting. If we use this, i think it is necessary to use even another name and avoid anything that points to the name malloc to avoid any future discussions about this topic. Perhaps we should use something like: void

Re: [Openocd-development] OpenOCD broken

2009-12-13 Thread Carsten Breuer
-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

Re: [Openocd-development] Cross Platform Debugger

2009-12-13 Thread Carsten Breuer
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

Re: [Openocd-development] OpenOCD broken

2009-12-13 Thread Carsten Breuer
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 { }

Re: [Openocd-development] OpenOCD broken

2009-12-13 Thread Carsten Breuer
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

[Openocd-development] register 'r13_svc' not found

2009-12-12 Thread Carsten Breuer
Hi all, i have got during the last weeks some snapshots from git and get always the same error message: Error: 500 35843 armv4_5.c:1102 armv4_5_run_algorithm_inner(): BUG: register 'r13_svc' not found. I wonder here that the file name is armv4_5.c, because i use the configuration file of a

[Openocd-development] OpenOCD broken

2009-12-12 Thread Carsten Breuer
Hi all, treat warning as errors (-wall) is a fine thing but sometimes breaks the build.. In my last git pull i get an error in src/flash/nor/stellaris.c, line 644: LOG_DEBUG(FMPPE%d = %#8.8x (status %d), i, lockbits, status); This is the same with the official download snapshot i have

Re: [Openocd-development] FIXED: register 'r13_svc' not found

2009-12-12 Thread Carsten Breuer
Hi David, Error: 500 35843 armv4_5.c:1102 armv4_5_run_algorithm_inner(): BUG: register 'r13_svc' not found. The register name is now sp_svc. I just checked in a bugfix for that. Works perfect now, thanks a lot!!! Best Regards, Carsten ___

Re: [Openocd-development] Cross Platform Debugger

2009-12-12 Thread Carsten Breuer
Hi Michael, is there any other GDB then insight or the EclipsePlugin under windows? command line gdb Not really ;-) Insight and Eclipse are just applications using gdb. You could write your own if you dislike those. Aside from that there Yep, that's perhaps the way to go. I have thought