All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Franck Bui-Huu <fbuihuu@gmail.com>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Kill __bzero()
Date: Mon, 5 Nov 2007 11:24:29 +0000	[thread overview]
Message-ID: <20071105112429.GC27893@linux-mips.org> (raw)
In-Reply-To: <472D8058.5080209@gmail.com>

On Sun, Nov 04, 2007 at 09:18:32AM +0100, Franck Bui-Huu wrote:

>   1/ Its unconventional prototype is error prone: its prototype is
>   the same as memset one but was documented by mips_ksym.c like the
>   following:
> 
> 	   extern void *__bzero(void *__s, size_t __count);
> 
>   2/ For the caller, it makes no difference to call memset instead
>   since it has to setup the second parameter of __bzero to 0.
> 
>   3/ It's not part of the Linux user access API, so no module can use
>   it.
> 
>   4/ It needs to be exported with EXPORT_SYMBOL and therefore consumes
>   some extra bytes.
> 
>   5/ It has only one user.
> 
> Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
> ---
> 
>  I'm wondering if I'm missing something, because this function seems
>  so ugly and useless in the first place, that I can't refrain to
>  submit a patch to get rid of it.

Memset is almost always only ever invoked with a zero argument.  So the
idea was to have something like this:

extern void *__memset(void *__s, int __c, size_t __count);
extern void *bzero(void *__s, size_t __count);

static inline void *memset(void *s, int c, size_t count)
{
	if (__builtin_constant_p(c) && c == 0) {
		bzero(s, count);
		return s;
	} else
		return __memset(s, __c, count);
}

But that was never quite implemented like this as you noticed.

As for the differences in the return value, they're because of of
clear_user and __clear_user which return the number of bytes that could
_not_ be cleared in $a2.  Memset being invoked through the normal C calling
conventions ignores this value while it's the actual result of interest for
__clear_user.

I hope that explains things a little.

  Ralf

  parent reply	other threads:[~2007-11-05 11:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-04  8:18 [PATCH] Kill __bzero() Franck Bui-Huu
2007-11-04 15:42 ` Atsushi Nemoto
2007-11-04 20:02   ` Franck Bui-Huu
2007-11-05 11:24 ` Ralf Baechle [this message]
2007-11-05 21:51   ` Franck Bui-Huu
2007-11-05 23:18     ` Ralf Baechle
2007-11-06  7:42       ` Franck Bui-Huu
2007-11-06 10:36         ` Ralf Baechle
2007-11-06 16:18           ` Franck Bui-Huu

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=20071105112429.GC27893@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=fbuihuu@gmail.com \
    --cc=linux-mips@linux-mips.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.