On Mon, Feb 28, 2005 at 06:29:39PM +0100, [EMAIL PROTECTED] wrote:
>
>
> On Mon, 28 Feb 2005, Stelian Pop wrote:
>
> > On Mon, Feb 28, 2005 at 04:06:14PM +0100, [EMAIL PROTECTED] wrote:
> >
> > > + /* Setting par[]'s elems at 0. */
> > > + memset(par, 0, NPAR*sizeof(
On Mon, Feb 28, 2005 at 06:29:39PM +0100, [EMAIL PROTECTED] wrote:
> Well, without it, it gives :
>
>
>
> --- old/drivers/char/vt.c 2004-12-24 22:35:25.0 +0100
> +++ new/drivers/char/vt.c 2005-02-28 18:19:11.782717810 +0100
> @@ -1655,8 +1655,8 @@
> vc_state = ESnormal;
> return;
> case
On Mon, 28 Feb 2005, Stelian Pop wrote:
> On Mon, Feb 28, 2005 at 04:06:14PM +0100, [EMAIL PROTECTED] wrote:
>
> > + /* Setting par[]'s elems at 0. */
> > + memset(par, 0, NPAR*sizeof(unsigned int));
>
> No need for the comment here, everybody understands C.
I knew
On Mon, Feb 28, 2005 at 04:06:14PM +0100, [EMAIL PROTECTED] wrote:
> + /* Setting par[]'s elems at 0. */
> + memset(par, 0, NPAR*sizeof(unsigned int));
No need for the comment here, everybody understands C.
Stelian.
--
Stelian Pop <[EMAIL PROTECTED]>
-
To unsubs
>> - for(npar = 0 ; npar < NPAR ; npar++)
>> + for(npar = NPAR - 1; npar >= 0; npar--)
>> par[npar] = 0;
>if you really want to clean this up..
Well, actually, I was not myself entirely convinced about it... This is the
reason for I wrote "please _don't_ apply this, but tell me what you think
[EMAIL PROTECTED] said:
> Surlignage Russell King <[EMAIL PROTECTED]>:
> > On Mon, Feb 28, 2005 at 02:13:57PM +0100, [EMAIL PROTECTED] wrote:
> > > NPAR times :-). As I stated, npar is unsigned.
> > I think that's disgusting then - it isn't obvious what's going on, which
> > leads to mistakes.
>
Hello!
> I agree :) . But, if we look to the code, we can notice that there is actually
> no reason for npar to be unsigned. What do you think of this version?
What does it try to solve? Your version is in no way better than the previous
one.
The previous one was more readable and it's quite po
> - for(npar = 0 ; npar < NPAR ; npar++)
> + for(npar = NPAR - 1; npar >= 0; npar--)
> par[npar] = 0;
if you really want to clean this up.. why not use memset() instead ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Surlignage Russell King <[EMAIL PROTECTED]>:
> On Mon, Feb 28, 2005 at 02:13:57PM +0100, [EMAIL PROTECTED] wrote:
> > NPAR times :-). As I stated, npar is unsigned.
>
> I think that's disgusting then - it isn't obvious what's going on, which
> leads to mistakes.
>
> For the sake of a micro-optim
On Mon, 28 Feb 2005 15:02:32 +0100, Arjan van de Ven
<[EMAIL PROTECTED]> wrote:
> \
> > > >> + for(npar = NPAR-1; npar < NPAR; npar--)
> > >
> > > >How many times do you want this for loop to run?
> > >
> > > NPAR times :-). As I stated, npar is unsigned.
> > >
> >
> > for (npar = NPAR - 1; npar >=
\
> > >> + for(npar = NPAR-1; npar < NPAR; npar--)
> >
> > >How many times do you want this for loop to run?
> >
> > NPAR times :-). As I stated, npar is unsigned.
> >
>
> for (npar = NPAR - 1; npar >= 0; npar--)
>
> would be more readable and may be even faster on a dumb compiler than
> your
On Mon, 28 Feb 2005 14:13:57 +0100, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> >On Mon, Feb 28, 2005 at 01:57:59PM +0100, [EMAIL PROTECTED] wrote:
> >> Please _don't_ apply this, but tell me what you think about it.
>
> >It's broken. 8)
>
> >> --- old/drivers/char/vt.c 2004-12-24 22:35:25.
On Mon, 28 Feb 2005 [EMAIL PROTECTED] wrote:
We could change an affectation into an incrementation by this patch, and,
so far I know, incrementing is quicker than or as quick as setting
a variable (depends on the architecture).
Please _don't_ apply this, but tell me what you think about it.
Note th
On Mon, Feb 28, 2005 at 02:13:57PM +0100, [EMAIL PROTECTED] wrote:
>
> >On Mon, Feb 28, 2005 at 01:57:59PM +0100, [EMAIL PROTECTED] wrote:
> >> Please _don't_ apply this, but tell me what you think about it.
>
> >It's broken. 8)
>
> >> --- old/drivers/char/vt.c 2004-12-24 22:35:25.0 +010
On Mon, Feb 28, 2005 at 02:13:57PM +0100, [EMAIL PROTECTED] wrote:
> NPAR times :-). As I stated, npar is unsigned.
I think that's disgusting then - it isn't obvious what's going on, which
leads to mistakes.
For the sake of a micro-optimisation such as this, it's far more important
that the code
>On Mon, Feb 28, 2005 at 01:57:59PM +0100, [EMAIL PROTECTED] wrote:
>> Please _don't_ apply this, but tell me what you think about it.
>It's broken. 8)
>> --- old/drivers/char/vt.c 2004-12-24 22:35:25.0 +0100
>> +++ new/drivers/char/vt.c 2005-02-28 12:53:57.933256631 +0100
>> @@ -1655,9
On Mon, Feb 28, 2005 at 01:57:59PM +0100, [EMAIL PROTECTED] wrote:
> Please _don't_ apply this, but tell me what you think about it.
It's broken. 8)
> --- old/drivers/char/vt.c 2004-12-24 22:35:25.0 +0100
> +++ new/drivers/char/vt.c 2005-02-28 12:53:57.933256631 +0100
> @@ -16
We could change an affectation into an incrementation by this patch, and,
so far I know, incrementing is quicker than or as quick as setting
a variable (depends on the architecture).
Please _don't_ apply this, but tell me what you think about it.
Note that npar is unsigned.
Signed-off-by: Emman
18 matches
Mail list logo