mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
Cc: Ken Ashcraft <ken@coverity.com>, linux-kernel@vger.kernel.org
Subject: Re: [CHECKER] Implementation inconsistencies in 2.6.3
Date: Tue, 27 Apr 2004 20:13:10 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.53.0404272006390.1280@chaos> (raw)
In-Reply-To: <20040427230520.GB2662@one-eyed-alien.net>

On Tue, 27 Apr 2004, Matthew Dharm wrote:

> On Tue, Apr 27, 2004 at 03:58:33PM -0700, Ken Ashcraft wrote:
> > > On Tue, Apr 27, 2004 at 02:47:22PM -0700, Ken Ashcraft wrote:
> > >
> > >> ---------------------------------------------------------
> > >> [BUG] (mdharm-usb@one-eyed-alien.net) looks like it should return count
> > >> instead of strlen(buf), but this is in scsiglue.c, so is it special
> > >> code?
> > >>
> > >> example:
> > >> /home/kash/linux/2.6.3/linux-2.6.3/drivers/scsi/scsi_sysfs.c:274:store_rescan_field:
> > >> NOTE:READ: Checking arg count [EXAMPLE=device_attribute.store-2]
> > >>
> > >> /home/kash/linux/2.6.3/linux-2.6.3/drivers/usb/storage/scsiglue.c:321:store_max_sectors:
> > >> ERROR:READ: Not checking arg [COUNTER=device_attribute.store-2]  [fit=1]
> > >> [fit_fn=1] [fn_ex=0] [fn_counter=1] [ex=233] [counter=1] [z >
> > >> 3.20943839741638] [fn-z = -4.35889894354067]
> > >>
> > >> 	return sprintf(buf, "%u\n", sdev->request_queue->max_sectors);
> > >> }
> > >>
> > >> /* Input routine for the sysfs max_sectors file */
> > >>
> > >> Error --->
> > >> static ssize_t store_max_sectors(struct device *dev, const char *buf,
> > >> 		size_t count)
> > >> {
> > >> 	struct scsi_device *sdev = to_scsi_device(dev);
> > >
> > > My understanding was that I was supposed to return the number of bytes in
> > > the buffer that I actually used.  I thought 'count' was the maximum size I
> > > could use.
> > >
> >
> > That sounds feasible.  I can't find any documentation on the interface, so
> > I can't tell.  However, there are ~233 functions that at least reference
> > count.  Many of them are almost identical: they call sscanf or strtol to
> > get a length out of buf, pass that length to some subroutine, and then
> > unconditionally return count.  This is a more representative example than
> > the one listed above.
> >
> > static ssize_t set_pwm_enable1(struct device *dev, const char *buf,
> >                                 size_t count)
> > {
> >         struct i2c_client *client = to_i2c_client(dev);
> >         struct asb100_data *data = i2c_get_clientdata(client);
> >         unsigned long val = simple_strtoul(buf, NULL, 10);
> >         data->pwm &= 0x0f; /* keep the duty cycle bits */
> >         data->pwm |= (val ? 0x80 : 0x00);
> >         asb100_write_value(client, ASB100_REG_PWM1, data->pwm);
> >         return count;
> > }
>
> It seems pretty shady to me to have a function which is passed a value, the
> entire purpose of which is to return it to the caller unchanged.
>
> Perhaps someone on l-k can comment...
>
> Matt

There are many funtions that are called for their effect (like printf),
and many functions that return the same value that they were passed,
like memcpy(), memmove(), strcpy(), strncpy(), etc.

In the subject code, the effect of the function was to condition
some parameters and call another function, returning the same
value it was passed. Sounds good to me.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
            Note 96.31% of all statistics are fiction.



  reply	other threads:[~2004-04-28  0:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-27 21:47 Ken Ashcraft
2004-04-27 22:14 ` Matthew Dharm
2004-04-27 22:58   ` Ken Ashcraft
2004-04-27 23:05     ` Matthew Dharm
2004-04-28  0:13       ` Richard B. Johnson [this message]
2004-04-28 16:15 ` Krzysztof Halasa

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=Pine.LNX.4.53.0404272006390.1280@chaos \
    --to=root@chaos.analogic.com \
    --cc=ken@coverity.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mdharm-kernel@one-eyed-alien.net \
    /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

all inboxes | Powered by JetHome®