Some cleanup patches for: '...lvalues is deprecated'

Hi Marcelo,

Please appolgies first for wrong presentation of previous post (that was the first and certainly the last time that I used the 'forwarding' option of this webmail interface :( ).

Here are some backport to clean up some warning of type: use of cast experssion
as lvalues is deprecated.
--- linux-2.4.27-rc2-pa4mm/kernel/sysctl.c.Orig 2004-06-29
09:03:42.000000000 +0200
+++ linux-2.4.27-rc2-pa4mm/kernel/sysctl.c 2004-06-29
10:10:31.588030256 +0200

Quoted 11 lines · Joel Soete

Hi Marcelo,

Please appolgies first for wrong presentation of previous post (that was the first and certainly the last time that I used the 'forwarding' option of this webmail interface :( ).

Here are some backport to clean up some warning of type: use of cast experssion as lvalues is deprecated.
--- linux-2.4.27-rc2-pa4mm/kernel/sysctl.c.Orig 2004-06-29
09:03:42.000000000 +0200
+++ linux-2.4.27-rc2-pa4mm/kernel/sysctl.c 2004-06-29
10:10:31.588030256 +0200

kernel/sysctl.c line 893

Quoted 5 lines

kernel/sysctl.c renamed from kernel/sysctl.c.Orig +1 -1

@@ -890,7 +890,7 @@
 				if (!isspace(c))
 					break;
 				left--;
-				((char *) buffer)++;
+				buffer += sizeof(char);

This (although correct in the end) is a wrong thing to do.

It seems to look like the intention is to move the pointer by a char's size, however your change is equivalent to:

	buffer += 1;

And if buffer wasn't void*, which it fortunately is, it would, unlike the older construction, move the pointer by a different size.

So just use

	buffer++;

here, and the intent is then clear.

Quoted 6 lines

(quoted diff) +0 -1

--- linux-2.4.27-rc2-pa4mm/drivers/video/fbcon.c.Orig	2004-06-29 

10:47:31.901491304 +0200
+++ linux-2.4.27-rc2-pa4mm/drivers/video/fbcon.c 2004-06-29
11:13:31.846343640 +0200

drivers/video/fbcon.c line 1883

Quoted 8 lines

drivers/video/fbcon.c renamed from drivers/video/fbcon.c.Orig +4 -1

@@ -1877,7 +1877,10 @@
       font length must be multiple of 256, at least. And 256 is multiple
       of 4 */
    k = 0;
-    while (p > new_data) k += *--(u32 *)p;
+    while (p > new_data) {
+        p = (u8 *)((u32 *)p - 1);
+        k += *(u32 *)p;
+    }

How about

	p -= 4;
	k += *(u32 *)p;

Very interesting but well I am not enough fluent in C to understand this fine detail :(
Can you explain me by an example (let say a long*) what would did "((char *) buffer)++;" versus "buffer += sizeof(char);"
(Don't worry, if don't have time, I will perfectly understand and will experiment by myself)

Quoted 6 lines

So just use

	buffer++;

here, and the intent is then clear.

Yes ;)

Quoted 14 lines · Joel Soete

Hi Marcelo,

Please appolgies first for wrong presentation of previous post (that was the first and certainly the last time that I used the 'forwarding' option of this webmail interface :( ).

Here are some backport to clean up some warning of type: use of cast experssion
as lvalues is deprecated.
--- linux-2.4.27-rc2-pa4mm/kernel/sysctl.c.Orig 2004-06-29
09:03:42.000000000 +0200
+++ linux-2.4.27-rc2-pa4mm/kernel/sysctl.c 2004-06-29
10:10:31.588030256 +0200

kernel/sysctl.c line 893

Quoted 5 lines

kernel/sysctl.c renamed from kernel/sysctl.c.Orig +1 -1

@@ -890,7 +890,7 @@
 				if (!isspace(c))
 					break;
 				left--;
-				((char *) buffer)++;
+				buffer += sizeof(char);

This (although correct in the end) is a wrong thing to do.

It seems to look like the intention is to move the pointer by a char's size, however your change is equivalent to:

	buffer += 1;

And if buffer wasn't void*, which it fortunately is, it would, unlike the older construction, move the pointer by a different size.

So just use

	buffer++;

here, and the intent is then clear.

Except C does not actually allow incrementing a void pointer, since void does not have a size. You can't do arithmetic on one either. GNU C allows this as an extension.

Quoted 5 lines

So just use

	buffer++;

here, and the intent is then clear.

Except C does not actually allow incrementing a void pointer, since void does not have a size.

You can't do arithmetic on one either. GNU
C allows this as an extension.

It's actually this, IIRC:
buffer = ((char *) buffer) + 1;

Hello Daniel,

Quoted 4 lines

Quoted 4 lines

So just use

	buffer++;

Quoted 4 lines

Quoted 1 line

here, and the intent is then clear.

Except C does not actually allow incrementing a void pointer, since void does not have a size.

That make better sense to me because aifair a void * was foreseen to pass any kind of type * as actual parameter?
(So as far as I understand, the aritthm pointer sould be dynamic for the best 'natural' behaviour?)

Quoted 5 lines

You can't do arithmetic on one either. GNU
C allows this as an extension.

It's actually this, IIRC:
buffer = ((char *) buffer) + 1;

-- Original Message --
Date: Tue, 27 Jul 2004 09:54:32 -0300
From: Marcelo Tosatti <[email protected]>
To: Joel Soete <[email protected]>
Cc: Daniel Jacobowitz <[email protected]>,
Vojtech Pavlik <[email protected]>,
Linux Kernel <[email protected]>
Subject: Re: Some cleanup patches for: '...lvalues is deprecated'

Quoted 12 lines · Joel Soete

Hello Daniel,

Quoted 9 lines

Quoted 5 lines

So just use

	buffer++;

here, and the intent is then clear.

Except C does not actually allow incrementing a void pointer, since void does not have a size.

That make better sense to me because aifair a void * was foreseen to

Quoted 2 lines

any kind of type * as actual parameter?
(So as far as I understand, the aritthm pointer sould be dynamic for

Quoted 7 lines

best 'natural' behaviour?)

Quoted 5 lines

You can't do arithmetic on one either. GNU
C allows this as an extension.

It's actually this, IIRC:
buffer = ((char *) buffer) + 1;

Joel,

It seems the current code is working perfectly, generating correct asm code.

Could you come up with a good enough reason to do this cleanup (as far

I am concerned) in 2.4.x series?

Marcelo,

Thanks first for your attention.
Sorry also for delaying this works but I was a bit busy elsewhere.

Quoted 10 lines

-- Original Message --
Date: Tue, 27 Jul 2004 09:54:32 -0300
From: Marcelo Tosatti <[email protected]>
To: Joel Soete <[email protected]>
Cc: Daniel Jacobowitz <[email protected]>,
Vojtech Pavlik <[email protected]>,
Linux Kernel <[email protected]>
Subject: Re: Some cleanup patches for: '...lvalues is deprecated'

Quoted 13 lines

Quoted 12 lines · Joel Soete

Hello Daniel,

Quoted 9 lines

Quoted 5 lines

So just use

	buffer++;

here, and the intent is then clear.

Except C does not actually allow incrementing a void pointer, since void does not have a size.

That make better sense to me because aifair a void * was foreseen to

pass

Quoted 2 lines

Quoted 2 lines

any kind of type * as actual parameter?
(So as far as I understand, the aritthm pointer sould be dynamic for

the

Quoted 8 lines

Quoted 7 lines

best 'natural' behaviour?)

Quoted 5 lines

You can't do arithmetic on one either. GNU
C allows this as an extension.

It's actually this, IIRC:
buffer = ((char *) buffer) + 1;

Quoted 6 lines

Joel,

It seems the current code is working perfectly, generating correct asm code.

Could you come up with a good enough reason to do this cleanup (as far

as

Quoted 3 lines

I am concerned) in 2.4.x series?

My first attention was to cleanup some warning of type "use of cast expression as lvalue is deprecated"
with gcc-3.3.4. But afaik, right now, there are just few warning which didn't break the asm code.

FYI, lvalue casts are treated as errors in gcc 3.5.

-- Original Message --
Date: Fri, 30 Jul 2004 11:11:32 +0200
From: "Joel Soete" <[email protected]>
Subject: Re: Some cleanup patches for: '...lvalues is deprecated'
To: "Jon Oberheide" <[email protected]>
Cc: "Marcelo Tosatti" <[email protected]>,
"Daniel Jacobowitz" <[email protected]>,
"Vojtech Pavlik" <[email protected]>,
"Linux Kernel" <[email protected]>

Hello *,

Quoted 3 lines

FYI, lvalue casts are treated as errors in gcc 3.5.

According to this kind remark, I think so that following attachement patches would be interesting.
Thanks for all relevant remarks to help me to make stuff cleaner.

Joel

PS: I don't yet review the lib/crc32.c (sorry I need more effort to review)

---------------------------------------------------------------------------
Tiscali ADSL LIGHT, 19,95 EUR/mois pendant 6 mois, c'est le moment de

le pas!
http://reg.tiscali.be/default.asp?lg=fr

Attachment: drivers-video-fbcon.diff

Attachment: fs-readdir.diff

Attachment: kernel-sysctl.diff

-- Original Message --
Date: Tue, 27 Jul 2004 09:54:32 -0300
From: Marcelo Tosatti <[email protected]>
To: Joel Soete <[email protected]>
Cc: Daniel Jacobowitz <[email protected]>,
Vojtech Pavlik <[email protected]>,
Linux Kernel <[email protected]>
Subject: Re: Some cleanup patches for: '...lvalues is deprecated'

Quoted 12 lines · Joel Soete

Hello Daniel,

Quoted 9 lines

Quoted 5 lines

So just use

	buffer++;

here, and the intent is then clear.

Except C does not actually allow incrementing a void pointer, since void does not have a size.

That make better sense to me because aifair a void * was foreseen to

Quoted 2 lines

any kind of type * as actual parameter?
(So as far as I understand, the aritthm pointer sould be dynamic for

Quoted 7 lines

best 'natural' behaviour?)

Quoted 5 lines

You can't do arithmetic on one either. GNU
C allows this as an extension.

It's actually this, IIRC:
buffer = ((char *) buffer) + 1;

Joel,

It seems the current code is working perfectly, generating correct asm code.

Could you come up with a good enough reason to do this cleanup (as far

I am concerned) in 2.4.x series?