public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Richard Moser <nigelenki@comcast.net>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] Bug zapper?  :)
Date: Mon, 09 Aug 2004 19:09:55 -0400	[thread overview]
Message-ID: <41180443.9030900@comcast.net> (raw)
In-Reply-To: <200408100042.37159.vda@port.imtp.ilyichevsk.odessa.ua>



Denis Vlasenko wrote:
> On Monday 09 August 2004 23:07, John Richard Moser wrote:
> 

[...]

> 
> 
> The flaw is that you think that kernel folks don't review their code.
> However, if you see some bad code, by all means - send a patch.
> 

Oh, no; as I said, even heavily quality assurance audited code has maybe 
5 bugs per kloc.  Where do the mremap() and munmap() bugs come from? 
Obviously you guys don't get everything.

> Asking others to do large amount of work is not very popular on this list.
> Do something yourself first.

Just do it in passing; you don't have to put a sudden hard effort to do 
these things in.  It'd be nice, but a major undertaking.

What I'm suggesting isn't much though, is it really?  Consider the 
functions function (normal code, not necessarily kernel):

void get_food(char **a) {
*a = malloc(strlen(global_food) + 1);
strcpy(*a, global_food);
}

/*Set our food*/
int set_food(char *food) {
if (!food)
return -1; /*error*/
free(global_food); /*if NULL, nothing happens*/
global_food = malloc(strlen(food) + 1);
strcpy(global_food, food);
return 0;
}

You'll have to forgive the lack of formatting; thunderbird is mean about 
this :/

Anyhow, as you can see, these are quite simple.  Function names are 
self-eplanitory, as is the process.  Assumedly, these are fine.

Now, we could try another approach at this, below.

/* get_food(char **a)
* Gets the current food.
*
* INPUT:
*  - char **a
*    Pointer to a pointer for the outputted food.
* OUTPUT:
*  - Return
*    none.
*  - *a
*    Set to a copy of the current food.
* PROCESS:
*  - Set '*a' to a newly allocated block of memory containing a copy
*    of the current food (global_food)
* STATE CHANGE:
*  none.
*/
void get_food(char **a) {
*a = malloc(strlen(global_food) + 1);
strcpy(*a, global_food);
}

/* set_food(char *food)
* Sets the current food.
*
* INPUT:
*  - char *food
*    Pointer to an ASCIIZ string containing the new food
* OUTPUT:
*  - Return
*    -1 on error
*    0 on success
* PROCESS:
*  - If (food is NULL)
*    - return error (-1)
*  - If (food is not NULL)
*    - Free current food (global_food)
*    - Set current food (global_food) to a newly allocated block
*      of memory containing a copy of 'food'
* STATE CHANGE:
*  - current food (global_food) is set to 'food'
*  - Memory holding previous food is freed
*/
int set_food(char *food) {
if (!food)
return -1; /*error*/
free(global_food); /*if NULL, nothing happens*/
global_food = malloc(strlen(food) + 1);
strcpy(global_food, food);
return 0;
}


These comment blocks are *MUCH* more verbose.  They describe the process 
loosely, but do give enough information to allow understanding without 
questions.

The large amount of extra commentary is worth it, IMHO.
> --
> vda
> 
> 

-- 
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.


  parent reply	other threads:[~2004-08-09 23:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-09 20:07 [RFC] Bug zapper? :) John Richard Moser
     [not found] ` <200408100042.37159.vda@port.imtp.ilyichevsk.odessa.ua>
2004-08-09 23:09   ` John Richard Moser [this message]
2004-08-10  0:58     ` Bernd Eckenfels
2004-08-10  1:55       ` Tommy Reynolds
2004-08-10  2:47     ` Rik van Riel
2004-08-10  3:13       ` John Richard Moser
2004-08-10  8:35     ` Jakob Oestergaard
2004-08-10 15:19       ` John Richard Moser
2004-08-10 21:43         ` Bernd Eckenfels
2004-08-10 21:30 ` V13
2004-08-10 23:35   ` John Richard Moser
2004-08-11  4:50   ` Bernd Eckenfels
  -- strict thread matches above, loose matches on Subject: below --
2004-08-10 21:13 Nick Warne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41180443.9030900@comcast.net \
    --to=nigelenki@comcast.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox