public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] afs: fsclient.c sparse endian annotations of operation_ID
@ 2008-08-26 22:05 Harvey Harrison
  2008-08-27 11:12 ` David Howells
  0 siblings, 1 reply; 4+ messages in thread
From: Harvey Harrison @ 2008-08-26 22:05 UTC (permalink / raw)
  To: David Howells; +Cc: Andrew Morton, LKML

fs/afs/fsclient.c:319:11: warning: restricted __be32 degrades to integer
fs/afs/fsclient.c:465:21: warning: incorrect type in assignment (different base types)
fs/afs/fsclient.c:465:21:    expected restricted __be32 [usertype] operation_ID
fs/afs/fsclient.c:465:21:    got int
fs/afs/fsclient.c:510:21: warning: incorrect type in assignment (different base types)
fs/afs/fsclient.c:510:21:    expected restricted __be32 [usertype] operation_ID
fs/afs/fsclient.c:510:21:    got int
fs/afs/fsclient.c:1304:10: warning: restricted __be32 degrades to integer
fs/afs/fsclient.c:1366:21: warning: incorrect type in assignment (different base types)
fs/afs/fsclient.c:1366:21:    expected restricted __be32 [usertype] operation_ID
fs/afs/fsclient.c:1366:21:    got int
fs/afs/fsclient.c:1417:21: warning: incorrect type in assignment (different base types)
fs/afs/fsclient.c:1417:21:    expected restricted __be32 [usertype] operation_ID
fs/afs/fsclient.c:1417:21:    got int
fs/afs/fsclient.c:1463:21: warning: incorrect type in assignment (different base types)
fs/afs/fsclient.c:1463:21:    expected restricted __be32 [usertype] operation_ID
fs/afs/fsclient.c:1463:21:    got int

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
 fs/afs/fsclient.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/afs/fsclient.c b/fs/afs/fsclient.c
index 023b95b..2928067 100644
--- a/fs/afs/fsclient.c
+++ b/fs/afs/fsclient.c
@@ -316,7 +316,7 @@ static int afs_deliver_fs_fetch_data(struct afs_call *call,
 	case 0:
 		call->offset = 0;
 		call->unmarshall++;
-		if (call->operation_ID != FSFETCHDATA64) {
+		if (call->operation_ID != __constant_htonl(FSFETCHDATA64)) {
 			call->unmarshall++;
 			goto no_msw;
 		}
@@ -462,7 +462,7 @@ static int afs_fs_fetch_data64(struct afs_server *server,
 	call->reply3 = buffer;
 	call->service_id = FS_SERVICE;
 	call->port = htons(AFS_FS_PORT);
-	call->operation_ID = FSFETCHDATA64;
+	call->operation_ID = __constant_htonl(FSFETCHDATA64);
 
 	/* marshall the parameters */
 	bp = call->request;
@@ -507,7 +507,7 @@ int afs_fs_fetch_data(struct afs_server *server,
 	call->reply3 = buffer;
 	call->service_id = FS_SERVICE;
 	call->port = htons(AFS_FS_PORT);
-	call->operation_ID = FSFETCHDATA;
+	call->operation_ID = __constant_htonl(FSFETCHDATA);
 
 	/* marshall the parameters */
 	bp = call->request;
@@ -1301,7 +1301,7 @@ static int afs_deliver_fs_store_status(struct afs_call *call,
 
 	/* unmarshall the reply once we've received all of it */
 	store_version = NULL;
-	if (call->operation_ID == FSSTOREDATA)
+	if (call->operation_ID == __constant_htonl(FSSTOREDATA))
 		store_version = &call->store_version;
 
 	bp = call->buffer;
@@ -1363,7 +1363,7 @@ static int afs_fs_setattr_size64(struct afs_server *server, struct key *key,
 	call->service_id = FS_SERVICE;
 	call->port = htons(AFS_FS_PORT);
 	call->store_version = vnode->status.data_version + 1;
-	call->operation_ID = FSSTOREDATA;
+	call->operation_ID = __constant_htonl(FSSTOREDATA);
 
 	/* marshall the parameters */
 	bp = call->request;
@@ -1414,7 +1414,7 @@ static int afs_fs_setattr_size(struct afs_server *server, struct key *key,
 	call->service_id = FS_SERVICE;
 	call->port = htons(AFS_FS_PORT);
 	call->store_version = vnode->status.data_version + 1;
-	call->operation_ID = FSSTOREDATA;
+	call->operation_ID = __constant_htonl(FSSTOREDATA);
 
 	/* marshall the parameters */
 	bp = call->request;
@@ -1460,7 +1460,7 @@ int afs_fs_setattr(struct afs_server *server, struct key *key,
 	call->reply = vnode;
 	call->service_id = FS_SERVICE;
 	call->port = htons(AFS_FS_PORT);
-	call->operation_ID = FSSTORESTATUS;
+	call->operation_ID = __constant_htonl(FSSTORESTATUS);
 
 	/* marshall the parameters */
 	bp = call->request;
-- 
1.6.0.340.g84854




^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] afs: fsclient.c sparse endian annotations of operation_ID
  2008-08-26 22:05 [PATCH] afs: fsclient.c sparse endian annotations of operation_ID Harvey Harrison
@ 2008-08-27 11:12 ` David Howells
  2008-08-27 11:17   ` David Miller
  0 siblings, 1 reply; 4+ messages in thread
From: David Howells @ 2008-08-27 11:12 UTC (permalink / raw)
  To: Harvey Harrison; +Cc: dhowells, Andrew Morton, LKML

Harvey Harrison <harvey.harrison@gmail.com> wrote:

> +		if (call->operation_ID != __constant_htonl(FSFETCHDATA64)) {

Doesn't htonl() resolve to this for a constant argument?  Following through
the definitions, it certainly looks like it ought to:

	<linux/byteorder/generic.h>
	#undef htonl
	#define ___htonl(x) __cpu_to_be32(x)

	<linux/byteorder/little_endian.h>
	#define __cpu_to_be32(x) ((__force __be32)__swab32((x)))

	<linux/byteorder/swab.h>
	#  define __swab32(x) \
	(__builtin_constant_p((__u32)(x)) ? \
	 ___constant_swab32((x)) : \
	 __fswab32((x)))

at least for GCC with optimisation enabled.

Of course, linux/byteorder.h and linux/swab.h seem to do much the same.  Any
idea why we have both sets?  There seems to be unnecessary redundancy.

David

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] afs: fsclient.c sparse endian annotations of operation_ID
  2008-08-27 11:12 ` David Howells
@ 2008-08-27 11:17   ` David Miller
  2008-08-28  2:22     ` Al Viro
  0 siblings, 1 reply; 4+ messages in thread
From: David Miller @ 2008-08-27 11:17 UTC (permalink / raw)
  To: dhowells; +Cc: harvey.harrison, akpm, linux-kernel

From: David Howells <dhowells@redhat.com>
Date: Wed, 27 Aug 2008 12:12:24 +0100

> Harvey Harrison <harvey.harrison@gmail.com> wrote:
> 
> > +		if (call->operation_ID != __constant_htonl(FSFETCHDATA64)) {
> 
> Doesn't htonl() resolve to this for a constant argument?  Following through
> the definitions, it certainly looks like it ought to:

Yes it does.

The __constant_*() interfaces should only be uses for things that
must be evaluated at compile time (static data initializations,
switch statement case values etc.).

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] afs: fsclient.c sparse endian annotations of operation_ID
  2008-08-27 11:17   ` David Miller
@ 2008-08-28  2:22     ` Al Viro
  0 siblings, 0 replies; 4+ messages in thread
From: Al Viro @ 2008-08-28  2:22 UTC (permalink / raw)
  To: David Miller; +Cc: dhowells, harvey.harrison, akpm, linux-kernel

On Wed, Aug 27, 2008 at 04:17:05AM -0700, David Miller wrote:
> From: David Howells <dhowells@redhat.com>
> Date: Wed, 27 Aug 2008 12:12:24 +0100
> 
> > Harvey Harrison <harvey.harrison@gmail.com> wrote:
> > 
> > > +		if (call->operation_ID != __constant_htonl(FSFETCHDATA64)) {
> > 
> > Doesn't htonl() resolve to this for a constant argument?  Following through
> > the definitions, it certainly looks like it ought to:
> 
> Yes it does.
> 
> The __constant_*() interfaces should only be uses for things that
> must be evaluated at compile time (static data initializations,
> switch statement case values etc.).

It's not just "must be evaluated at compile time"; it's "must be C constant
expressions", which is much stricter.  And no, in the case quoted above
__constant_ form is not needed.  Just use htonl()...

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-08-28  2:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-26 22:05 [PATCH] afs: fsclient.c sparse endian annotations of operation_ID Harvey Harrison
2008-08-27 11:12 ` David Howells
2008-08-27 11:17   ` David Miller
2008-08-28  2:22     ` Al Viro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox