On Thursday 17 December 2009, Carsten Breuer wrote:
> > 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
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 g
Carsten Breuer wrote:
>> Perhaps we should use something like:
>>
>> void *allocate_or_exit(size);
>
> I would also make some defines in types.h:
>
> #define malloc YOU_SHOULD_NEVER_EVER_USE_MALLOC
> #define calloc YOU_SHOULD_NEVER_EVER_USE_CALLOC
>
> With this, developers can't use malloc
> acc
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, th
On Wednesday 16 December 2009, Carsten Breuer wrote:
> If it is guarantied, that malloc exits
> under linux, we can also just use
> a define for that:
As I understand it, ANSI C says it returns NULL when
it can't allocate memory. Anything else would be
phenominally rude.
For the record, I've nev
Hi all,
> Perhaps we should use something like:
>
> void *allocate_or_exit(size);
I would also make some defines in types.h:
#define malloc YOU_SHOULD_NEVER_EVER_USE_MALLOC
#define calloc YOU_SHOULD_NEVER_EVER_USE_CALLOC
With this, developers can't use malloc
accidentally.
If it is guarantied
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 i
On Wednesday 16 December 2009, Igor Skochinsky wrote:
> Actually, I think a common emalloc() function that (in the unlikely
> event of malloc failure) prints an error message and exits the app is
> a better choice than sticking checks everywhere.
I was tempted to suggest something like this. It c
Actually, probably not a bad idea for a long-term fix. AFAIK, Posix
OSes will inform you of malloc failures with SIGKILL rather than NULL.
The article on gmane.comp.audio.jackit had some very good discussion
on this point, so emulating that functionality under Windows is probably
a decent way to go
On Wednesday 16 December 2009, Igor Skochinsky wrote:
> Actually, I think a common emalloc() function that (in the unlikely
> event of malloc failure) prints an error message and exits the app is
> a better choice than sticking checks everywhere.
Not a bad idea for a near-term fix...
Hello Carsten,
Wednesday, December 16, 2009, 11:57:23 PM, you wrote:
Just one point.
>> 2) it bloats the code, in some case substantially, and obscures
>> the "real" code flow
CB> The real code flow ends in nothing. There are embedded CPU's that have
CB> no problem with writing to zero. They ju
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
-Oorspronkelijk bericht-
Van: openocd-development-boun...@lists.berlios.de namens Øyvind Harboe
Verzonden: wo 12/16/09 21:43
Aan: Thomas Kindler
CC: openocd-development@lists.berlios.de
Onderwerp: Re: [Openocd-development] Codecheck
On Wed, Dec 16, 2009 at 9:36 PM, Thomas Kindler wrote
On Wednesday 16 December 2009, Thomas Kindler wrote:
>
> > for (int idx = 0; idx < 255; idx++)
> > {
> > void *p = malloc(0x);
> > }
> >
>
> That's why I said "reasonably sized". If you malloc() inside a file
> parser, malloc() based on unverified user input, or malloc() huge
> bu
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
Carsten Breuer wrote:
> Hi Thomas, hi all
>
>
>> On a normal, modern operating system, (reasonably sized) mallocs should
>> never fail, as the system will start thrashing and killing off processes
>> long before malloc() fails.
>
> Well, try:
>
> for (int idx = 0; idx < 255; idx++)
> {
> v
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 w
Carsten Breuer a écrit :
> Nonetheless: Malloc can fail and we have to take care of that.
Well, yes for the first part, and maybe or even no for the second.
Yes, malloc can fail.
But when it fails, what *can* you do apart from trying to fail as
gracefully as possible? And failing gracefully is
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
Hi Thomas, hi all
> On a normal, modern operating system, (reasonably sized) mallocs should
> never fail, as the system will start thrashing and killing off processes
> long before malloc() fails.
Well, try:
for (int idx = 0; idx < 255; idx++)
{
void *p = malloc(0x);
}
and your do
On Wednesday 16 December 2009, Lennert Buytenhek wrote:
> 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.
>
> E.g. if someone is already
On Wed, Dec 16, 2009 at 10:21 PM, Albert ARIBAUD wrote:
> Øyvind Harboe a écrit :
>
>> The zy1000 has "infinite" ram w.r.t. small allocations(32 or
>> 64mBytes depending on revision), so not checking small
>> allocations is *highly unlikely * to cause problems for any
>> embedded host with oodles
s.de
> Subject: Re: [Openocd-development] Codecheck
>
> On Wed, Dec 16, 2009 at 09:46:29PM +0100, Øyvind Harboe wrote:
>
> > > for number_of_mallocs:
> > > {
> > > - fix the file
> > > - see if it compiles.
> > > - create a patch
> >
Hello Carsten,
Wednesday, December 16, 2009, 9:00:58 PM, you wrote:
>>> 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.
CB> OK, then i will start to fix all
Øyvind Harboe a écrit :
> The zy1000 has "infinite" ram w.r.t. small allocations(32 or
> 64mBytes depending on revision), so not checking small
> allocations is *highly unlikely * to cause problems for any
> embedded host with oodles of ram(megabytes).
To be completely honest, it depends. If ther
On Wed, Dec 16, 2009 at 9:56 PM, Lennert Buytenhek
wrote:
> On Wed, Dec 16, 2009 at 09:46:29PM +0100, Øyvind Harboe wrote:
>
>> > for number_of_mallocs:
>> > {
>> > - fix the file
>> > - see if it compiles.
>> > - create a patch
>> > - send it too you.
>> > }
>>
>> No.
>>
>> - fix a fi
On Wednesday 16 December 2009, Carsten Breuer wrote:
> Before i do anything, i want to know if the
> OpenOcd Developers are interested in improving
> the code for better maintainance.
Absolutely. We're also interested in having other
developers help with that work. :)
__
On Wed, Dec 16, 2009 at 09:46:29PM +0100, Øyvind Harboe wrote:
> > 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
While I am of the opini
On Wed, Dec 16, 2009 at 9:22 PM, Carsten Breuer
wrote:
> 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 rema
On Wed, Dec 16, 2009 at 9:36 PM, Thomas Kindler wrote:
> Carsten Breuer wrote:
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
Carsten Breuer wrote:
> Is there any windows client that you can suggest?
> Something like TortoiseGIT?
Sure. TortoiseGit.
;)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-dev
Carsten Breuer wrote:
>>> 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
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 sp
On Wed, Dec 16, 2009 at 9:00 PM, Carsten Breuer
wrote:
> 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 al
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 understa
On Wed, Dec 16, 2009 at 2:30 PM, Carsten Breuer
wrote:
> 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
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 is
37 matches
Mail list logo
