* fs/fat.c assumes that 0UL is the same for 32bit and 64bit archs
@ 2005-02-16 8:56 Omniflux
2005-03-02 21:01 ` Yoshinori K. Okuji
0 siblings, 1 reply; 4+ messages in thread
From: Omniflux @ 2005-02-16 8:56 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 287 bytes --]
fs/fat.c assumes that 0UL is the same for 32bit and 64bit archs, but it
is not.
There are four locations in fs/fat.c where a 32bit unsigned int is set
equal to 0UL. This causes warnings when compiling on 64bit architectures
as 0UL is 0xffffffffffffffff (64bits) there.
--
Omniflux
[-- Attachment #2: 0UL-fix.diff --]
[-- Type: text/plain, Size: 1145 bytes --]
--- grub2/fs/fat.c 2004-08-28 07:14:29.000000000 -0600
+++ grub2.modified/fs/fat.c 2005-02-16 00:39:25.271409504 -0700
@@ -243,7 +243,7 @@
else
{
/* FAT12 or FAT16. */
- data->root_cluster = ~0UL;
+ data->root_cluster = 0xffffffff;
if (data->num_clusters <= 4085 + 2)
{
@@ -293,7 +293,7 @@
/* Start from the root directory. */
data->file_cluster = data->root_cluster;
- data->cur_cluster_num = ~0UL;
+ data->cur_cluster_num = 0xffffffff;
data->attr = GRUB_FAT_ATTR_DIRECTORY;
return data;
@@ -318,7 +318,7 @@
/* This is a special case. FAT12 and FAT16 doesn't have the root directory
in clusters. */
- if (data->file_cluster == ~0UL)
+ if (data->file_cluster == 0xffffffff)
{
size = (data->num_root_sectors << GRUB_DISK_SECTOR_BITS) - offset;
if (size > len)
@@ -613,7 +613,7 @@
data->file_size = grub_le_to_cpu32 (dir.file_size);
data->file_cluster = ((grub_le_to_cpu16 (dir.first_cluster_high) << 16)
| grub_le_to_cpu16 (dir.first_cluster_low));
- data->cur_cluster_num = ~0UL;
+ data->cur_cluster_num = 0xffffffff;
return dirp;
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fs/fat.c assumes that 0UL is the same for 32bit and 64bit archs
2005-02-16 8:56 fs/fat.c assumes that 0UL is the same for 32bit and 64bit archs Omniflux
@ 2005-03-02 21:01 ` Yoshinori K. Okuji
2005-03-02 21:20 ` Marco Gerards
0 siblings, 1 reply; 4+ messages in thread
From: Yoshinori K. Okuji @ 2005-03-02 21:01 UTC (permalink / raw)
To: The development of GRUB 2
On Wednesday 16 February 2005 09:56, Omniflux wrote:
> fs/fat.c assumes that 0UL is the same for 32bit and 64bit archs, but
> it is not.
>
> There are four locations in fs/fat.c where a 32bit unsigned int is
> set equal to 0UL. This causes warnings when compiling on 64bit
> architectures as 0UL is 0xffffffffffffffff (64bits) there.
Marco, did you look at this patch?
Okuji
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fs/fat.c assumes that 0UL is the same for 32bit and 64bit archs
2005-03-02 21:01 ` Yoshinori K. Okuji
@ 2005-03-02 21:20 ` Marco Gerards
2005-03-02 21:40 ` Yoshinori K. Okuji
0 siblings, 1 reply; 4+ messages in thread
From: Marco Gerards @ 2005-03-02 21:20 UTC (permalink / raw)
To: The development of GRUB 2
"Yoshinori K. Okuji" <okuji@enbug.org> writes:
> On Wednesday 16 February 2005 09:56, Omniflux wrote:
>> fs/fat.c assumes that 0UL is the same for 32bit and 64bit archs, but
>> it is not.
>>
>> There are four locations in fs/fat.c where a 32bit unsigned int is
>> set equal to 0UL. This causes warnings when compiling on 64bit
>> architectures as 0UL is 0xffffffffffffffff (64bits) there.
>
> Marco, did you look at this patch?
Yes. Sorry, I forgot to reply after I got back. :)
The patch looked fine to me. I have encountered this problem as well
on 64 bits archs but I ddi not test the patch yet myself, I can't at
the moment.
Because this seems to be the only way to fix this problem, I don't
think there are copyright issues and the patch can be applied. Right?
Thanks,
Marco
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fs/fat.c assumes that 0UL is the same for 32bit and 64bit archs
2005-03-02 21:20 ` Marco Gerards
@ 2005-03-02 21:40 ` Yoshinori K. Okuji
0 siblings, 0 replies; 4+ messages in thread
From: Yoshinori K. Okuji @ 2005-03-02 21:40 UTC (permalink / raw)
To: The development of GRUB 2
On Wednesday 02 March 2005 22:20, Marco Gerards wrote:
> Because this seems to be the only way to fix this problem, I don't
> think there are copyright issues and the patch can be applied.
> Right?
How about this instead of 0xffffffff:
~((grub_uint32_t) 0)
I don't know which is better.
You don't have to care about the copyright, because the change is very
small.
Okuji
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-03-02 21:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-16 8:56 fs/fat.c assumes that 0UL is the same for 32bit and 64bit archs Omniflux
2005-03-02 21:01 ` Yoshinori K. Okuji
2005-03-02 21:20 ` Marco Gerards
2005-03-02 21:40 ` Yoshinori K. Okuji
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.