All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Duffy <cduffy@spamcop.net>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Changeset for reisermodule x86_64 compilation w/ -Wall
Date: Tue, 11 Oct 2005 12:51:05 -0500	[thread overview]
Message-ID: <434BFB89.7040409@spamcop.net> (raw)
In-Reply-To: <c70212ac8ffe5e7ba23dfc096862f542@us.ibm.com>

Hollis Blanchard wrote:
> On Oct 11, 2005, at 3:14 AM, Charles Duffy wrote:
> 
>> Compiling with -Wall is failing for me without application of this 
>> patch. I'm fairly sure someone else has independently proposed (pretty 
>> much) the same thing, but given that it didn't get applied, I'm 
>> reproposing it here.
>>
>> # HG changeset patch
>> # User cduffy@spamcop.net
>> # Node ID f3f8213f8d895c1b4e29647132aaea8633fb4825
>> # Parent  e69413dca6844c87885121a7360fa7c2b11cdea9
>> fix 64-bit compilation
>>
>> diff -r e69413dca684 -r f3f8213f8d89 
>> tools/pygrub/src/fsys/reiser/reisermodule.c
>> --- a/tools/pygrub/src/fsys/reiser/reisermodule.c       Sat Oct  8 
>> 09:22:01 2005
>> +++ b/tools/pygrub/src/fsys/reiser/reisermodule.c       Tue Oct 11 
>> 07:51:18 2005
>> @@ -46,7 +46,7 @@
>>
>>         if (!dal) return;
>>
>> -       close((int)dal->dev);
>> +       close((size_t)dal->dev);
>>         dal_free(dal);
>>  }
> 
> 
> I don't understand this change. My close(2) man page says close takes an 
> int, not a size_t.
> 
> Charles, what is the exact -Wall error you're seeing? I can't seem to 
> find "dal", but just a guess... is 'dal->dev' a 'void *'?
> 

Sadly, this query came *after* I wiped SLES10.1 off my development box. 
Gentoo doesn't install the reiserfstools headers, and consequently 
pygrub doesn't try to build the code in question and I'm unable to 
reproduce the issue.

It smells to me like you're right, though -- I *think* the error was 
indeed "cast from pointer to integer of different size" -- and if so, 
then what I've proposed isn't the right fix; something like 
close((int)(size_t)dal->dev) would be closer, though stuffing a FD in a 
spot intended for a pointer seems pretty hokey in any event.

      reply	other threads:[~2005-10-11 17:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-11  8:14 Changeset for reisermodule x86_64 compilation w/ -Wall Charles Duffy
2005-10-11 15:34 ` Hollis Blanchard
2005-10-11 17:51   ` Charles Duffy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=434BFB89.7040409@spamcop.net \
    --to=cduffy@spamcop.net \
    --cc=hollisb@us.ibm.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.