Re: [cp-patches] RFC: fix warning in cpio_df
Il giorno gio, 08/11/2007 alle 13.06 +0100, Mark Wielaard ha scritto: Hi Robert, On Wed, 2007-11-07 at 22:13 +0100, Robert Schuster wrote: this patch marks the parameters of cpio_df as possibly unused and silents the warning/lets the build continue with -Wall. Which system is this? I am not really opposed to the patch, but it would of course be better to figure out how to correctly return something for your setup if at all possible. Yes, please, I had troubles figuring out this. As for the patch, I did that way to catch exactly the systems where no statvfs is available. Can you try using statfs? If it's a system where df is available we can try to steal some code from there also. Thanks, Mario
Re: [cp-patches] RFC: fix warning in cpio_df
On Thu, 2007-11-08 at 16:44 +0100, Robert Schuster wrote:
Now if HAVE_STATVFS is not defined the compiler is correct mourning that
'path' and 'type' are not used. I have seen code (in classpath) where
this issue is solved this way:
JNIEXPORT long long
cpio_df (const char *path, CPFILE_DF_TYPE type)
{
long long result = 0L;
#if defined(HAVE_STATVFS)
... much stuff
#else
(void) path;
(void) type;
#endif
return result;
}
See Java_gnu_java_nio_KqueueSelectorImpl_kevent_1set for example.
Yes, right. I've also fixed similar problems a while ago and we decided
to use the unused attribute.
- twisti
Re: [cp-patches] RFC: fix warning in cpio_df
Hi.
Mario Torre schrieb:
Il giorno gio, 08/11/2007 alle 13.06 +0100, Mark Wielaard ha scritto:
Hi Robert,
On Wed, 2007-11-07 at 22:13 +0100, Robert Schuster wrote:
this patch marks the parameters of cpio_df as possibly unused and
silents the warning/lets the build continue with -Wall.
Which system is this?
I am not really opposed to the patch, but it would of course be better
to figure out how to correctly return something for your setup if at all
possible.
Yes, please, I had troubles figuring out this.
As for the patch, I did that way to catch exactly the systems where no
statvfs is available.
Can you try using statfs? If it's a system where df is available we can
try to steal some code from there also.
This is Debian Lenny/Sid x86. I am not sure whether it is normal that
statvfs is not available on it but even then I think the problem is more
a tiny glitch in the code:
JNIEXPORT long long
cpio_df (const char *path, CPFILE_DF_TYPE type)
{
long long result = 0L;
#if defined(HAVE_STATVFS)
... much stuff
#endif
return result;
}
Now if HAVE_STATVFS is not defined the compiler is correct mourning that
'path' and 'type' are not used. I have seen code (in classpath) where
this issue is solved this way:
JNIEXPORT long long
cpio_df (const char *path, CPFILE_DF_TYPE type)
{
long long result = 0L;
#if defined(HAVE_STATVFS)
... much stuff
#else
(void) path;
(void) type;
#endif
return result;
}
See Java_gnu_java_nio_KqueueSelectorImpl_kevent_1set for example.
Regards
Robert
signature.asc
Description: OpenPGP digital signature
Re: [cp-patches] RFC: fix warning in cpio_df
Il giorno gio, 08/11/2007 alle 16.44 +0100, Robert Schuster ha scritto:
Hi.
Can you try using statfs? If it's a system where df is available we can
try to steal some code from there also.
This is Debian Lenny/Sid x86. I am not sure whether it is normal that
statvfs is not available on it but even then I think the problem is more
a tiny glitch in the code:
Hi Robert.
That's strange, probably I've messed up with configure so... I don't
think it's a bug in Debian, maybe I'm just doing the wrong tests to
check fro statvfs...
JNIEXPORT long long
cpio_df (const char *path, CPFILE_DF_TYPE type)
{
long long result = 0L;
#if defined(HAVE_STATVFS)
... much stuff
#endif
return result;
}
Now if HAVE_STATVFS is not defined the compiler is correct mourning that
'path' and 'type' are not used. I have seen code (in classpath) where
this issue is solved this way:
(void) path;
(void) type;
Seems ok to me, but I don't have nothing to say against adding
__attribute__((unused)) also, so feel free to do what you think it's
best.
I would like to investigate this issue before going on though. I've just
upgraded to fedora 8, so I have to setup a few things, I'll try with
this new system as soon as I can, maybe I can get the same failure.
The thing that let me wonder that I really did something wrong in
configure is that my man page dates to 2003, statvfs was defined by
POSIX.1 in 2001, and Linux has it's own syscall for it, so it's
definitely not that is so much system dependent (well, at least on
Linux).
I hope a configure guru will save us all (Dalibor... ping) :)
Mario
