mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: David Howells <dhowells@redhat.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>,
	torvalds@osdl.org, akpm@osdl.org, linux-kernel@vger.kernel.org,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: Mark bitrevX() functions as const
Date: Mon, 11 Dec 2006 07:57:00 -0500	[thread overview]
Message-ID: <457D559C.2030702@garzik.org> (raw)
In-Reply-To: <29447.1165840536@redhat.com>

David Howells wrote:
> Mark the bit reversal functions as being const as they always return the same
> output for any given input.
> 
> Signed-Off-By: David Howells <dhowells@redhat.com>
> ---
> 
>  include/linux/bitrev.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/bitrev.h b/include/linux/bitrev.h
> index 05e540d..032056b 100644
> --- a/include/linux/bitrev.h
> +++ b/include/linux/bitrev.h
> @@ -5,11 +5,11 @@ #include <linux/types.h>
>  
>  extern u8 const byte_rev_table[256];
>  
> -static inline u8 bitrev8(u8 byte)
> +static inline __attribute__((const)) u8 bitrev8(u8 byte)
>  {
>  	return byte_rev_table[byte];
>  }
>  
> -extern u32 bitrev32(u32 in);
> +extern __attribute__((const)) u32 bitrev32(u32 in);


Comments:

* overall, I agree with this type of change.  several Linux lib 
functions could use this sort of annotation.

* I question its usefulness on static [inline] functions, because the 
compiler should be able to figure out side effects.  have you examined 
before-and-after asm to see if the code generation changes for the 
inlined area?

* naked __attribute__ is ugly.  define something short and memorable in 
include/linux/compiler.h.

* another annotation to consider is C99 keyword 'restrict'.

	Jeff




  reply	other threads:[~2006-12-11 12:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-11 12:35 David Howells
2006-12-11 12:57 ` Jeff Garzik [this message]
2006-12-11 13:37   ` Andreas Schwab
2006-12-11 13:53     ` Jeff Garzik
2006-12-11 13:14 ` David Howells
2006-12-11 13:32   ` Jeff Garzik
2006-12-11 14:18   ` David Howells
2006-12-11 13:25 ` Akinobu Mita
2006-12-11 14:22 ` David Howells
2006-12-11 16:05 ` Linus Torvalds
2006-12-11 16:12 ` David Howells
2006-12-11 16:34   ` Linus Torvalds
2006-12-11 17:35   ` Jan Engelhardt
2006-12-11 17:51     ` Bernd Petrovitsch

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=457D559C.2030702@garzik.org \
    --to=jeff@garzik.org \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@osdl.org \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=viro@zeniv.linux.org.uk \
    /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®