On Mon, 2006-12-11 at 18:35 +0100, Jan Engelhardt wrote:
[...]
> I can just second this. What should be marked const is [1]the things
> pointed to, not [2]the local copy of a function argument.
>
> This[2] is what I believe almost every other software project does,
Yes, also for the reason to
>> > Mark the bit reversal functions as being const as they always return the
>> > same output for any given input.
>>
>> Well, we should mark the argument const too, no?
>
>The argument is just an integer; I'm not sure that marking it const actually
>achieves anything, except to tell the
On Mon, 11 Dec 2006, David Howells wrote:
>
> Ah. I thought that was just for supporting old versions of gcc. I didn't
> realise it was for handling strange compilers.
I'm not sure how much (if at all) the Intel compiler is actually used, and
for all I know it may even support
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > Mark the bit reversal functions as being const as they always return the
> > same output for any given input.
>
> Well, we should mark the argument const too, no?
The argument is just an integer; I'm not sure that marking it const actually
achieves
On Mon, 11 Dec 2006, David Howells wrote:
>
> Mark the bit reversal functions as being const as they always return the same
> output for any given input.
Well, we should mark the argument const too, no?
Does anythign actually improve from this? Also, we should actually use
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > I'm not sure that's a good idea. You have to be careful not to cause
> > confusion with ordinary "const".
>
> It's all in the naming. You could call it 'purefunc' or somesuch.
No, not "pure". That's something else.
> __attribute__ is very very
Akinobu Mita <[EMAIL PROTECTED]> wrote:
> __attribute_pure__ ?
I'm not sure "pure" is better than const in this case. Although it *does* look
at a global variable (byte_rev_table), that variable is constant. In effect,
the functions output does only depend on its input. The R/O data it
Andreas Schwab wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
* another annotation to consider is C99 keyword 'restrict'.
This is useless as long as we compile with -fno-strict-aliasing (and I
don't think this will ever change).
Yes, just as useless as __attribute__((bitwise))... :)
Jeff Garzik <[EMAIL PROTECTED]> writes:
> * another annotation to consider is C99 keyword 'restrict'.
This is useless as long as we compile with -fno-strict-aliasing (and I
don't think this will ever change).
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH,
David Howells wrote:
Jeff Garzik <[EMAIL PROTECTED]> wrote:
* naked __attribute__ is ugly. define something short and memorable in
include/linux/compiler.h.
I'm not sure that's a good idea. You have to be careful not to cause confusion
with ordinary "const".
It's all in the naming. You
On Mon, Dec 11, 2006 at 12:35:36PM +, David Howells wrote:
> 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
>
> extern u8 const byte_rev_table[256];
>
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> * overall, I agree with this type of change. several Linux lib functions
> could use this sort of annotation.
Yes. I just happened to notice bitrev.c at the end of my git pull and wondered
if it was what it sounded like...
> * I question its usefulness
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 <[EMAIL PROTECTED]>
---
include/linux/bitrev.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Mark the bit reversal functions as being const as they always return the same
output for any given input.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
include/linux/bitrev.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/bitrev.h
Mark the bit reversal functions as being const as they always return the same
output for any given input.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
include/linux/bitrev.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/bitrev.h
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 [EMAIL PROTECTED]
---
include/linux/bitrev.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On Mon, Dec 11, 2006 at 12:35:36PM +, David Howells wrote:
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
David Howells wrote:
Jeff Garzik [EMAIL PROTECTED] wrote:
* naked __attribute__ is ugly. define something short and memorable in
include/linux/compiler.h.
I'm not sure that's a good idea. You have to be careful not to cause confusion
with ordinary const.
It's all in the naming. You could
Jeff Garzik [EMAIL PROTECTED] writes:
* another annotation to consider is C99 keyword 'restrict'.
This is useless as long as we compile with -fno-strict-aliasing (and I
don't think this will ever change).
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH,
Andreas Schwab wrote:
Jeff Garzik [EMAIL PROTECTED] writes:
* another annotation to consider is C99 keyword 'restrict'.
This is useless as long as we compile with -fno-strict-aliasing (and I
don't think this will ever change).
Yes, just as useless as __attribute__((bitwise))... :)
Akinobu Mita [EMAIL PROTECTED] wrote:
__attribute_pure__ ?
I'm not sure pure is better than const in this case. Although it *does* look
at a global variable (byte_rev_table), that variable is constant. In effect,
the functions output does only depend on its input. The R/O data it requires
is
Jeff Garzik [EMAIL PROTECTED] wrote:
I'm not sure that's a good idea. You have to be careful not to cause
confusion with ordinary const.
It's all in the naming. You could call it 'purefunc' or somesuch.
No, not pure. That's something else.
__attribute__ is very very ugly, an hinders
On Mon, 11 Dec 2006, David Howells wrote:
Mark the bit reversal functions as being const as they always return the same
output for any given input.
Well, we should mark the argument const too, no?
Does anythign actually improve from this? Also, we should actually use
__attribute_const__
Linus Torvalds [EMAIL PROTECTED] wrote:
Mark the bit reversal functions as being const as they always return the
same output for any given input.
Well, we should mark the argument const too, no?
The argument is just an integer; I'm not sure that marking it const actually
achieves
On Mon, 11 Dec 2006, David Howells wrote:
Ah. I thought that was just for supporting old versions of gcc. I didn't
realise it was for handling strange compilers.
I'm not sure how much (if at all) the Intel compiler is actually used, and
for all I know it may even support
Mark the bit reversal functions as being const as they always return the
same output for any given input.
Well, we should mark the argument const too, no?
The argument is just an integer; I'm not sure that marking it const actually
achieves anything, except to tell the function that it
On Mon, 2006-12-11 at 18:35 +0100, Jan Engelhardt wrote:
[...]
I can just second this. What should be marked const is [1]the things
pointed to, not [2]the local copy of a function argument.
This[2] is what I believe almost every other software project does,
Yes, also for the reason to
27 matches
Mail list logo
