Patchwork util/path: Fix type which is longer than 8 bit for MinGW

login
register
mail settings
Submitter Stefan Weil
Date Oct. 2, 2013, 8:40 p.m.
Message ID <1380746429-634-1-git-send-email-sw@weilnetz.de>
Download mbox | patch
Permalink /patch/280174/
State Accepted
Headers show

Comments

Stefan Weil - Oct. 2, 2013, 8:40 p.m.
While dirent->d_type is 8 bit for most systems, it is 32 bit for MinGW.
Reducing it to 8 bit results in a compiler warning because the macro
is_dir_maybe compares that 8 bit value with 32 bit constants.

Using 'unsigned' instead of 'unsigned char' matches the declaration for
MinGW and does not harm the other systems.

MinGW-w32 is not affected: it does not declare d_type.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
---
 util/path.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Michael Tokarev - Oct. 5, 2013, 9:10 a.m.
03.10.2013 00:40, Stefan Weil wrote:
> While dirent->d_type is 8 bit for most systems, it is 32 bit for MinGW.
> Reducing it to 8 bit results in a compiler warning because the macro
> is_dir_maybe compares that 8 bit value with 32 bit constants.
>
> Using 'unsigned' instead of 'unsigned char' matches the declaration for
> MinGW and does not harm the other systems.
>
> MinGW-w32 is not affected: it does not declare d_type.

That's a good one.

What's the diff between mingw-w32 and mingw?

At any rate, there's - I think - no need to declare it as 'char',
int or unsigned should be just fine.

Thanks, applied to the trivial patches queue.

/mjt
Stefan Weil - Oct. 5, 2013, 9:31 a.m.
Am 05.10.2013 11:10, schrieb Michael Tokarev:
> 03.10.2013 00:40, Stefan Weil wrote:
>> While dirent->d_type is 8 bit for most systems, it is 32 bit for MinGW.
>> Reducing it to 8 bit results in a compiler warning because the macro
>> is_dir_maybe compares that 8 bit value with 32 bit constants.
>>
>> Using 'unsigned' instead of 'unsigned char' matches the declaration for
>> MinGW and does not harm the other systems.
>>
>> MinGW-w32 is not affected: it does not declare d_type.
>
> That's a good one.
>
> What's the diff between mingw-w32 and mingw?
>
> At any rate, there's - I think - no need to declare it as 'char',
> int or unsigned should be just fine.
>
> Thanks, applied to the trivial patches queue.
>
> /mjt


It should be MinGW-w64, not MinGW-w32, because that is the
official project name. Perhaps you can correct that in the commit comment.
But even the MinGW-w64 developers use mingw-w32 when they speak of
MinGW-w64 for 32 bit Windows, so MinGW-w32 is not completely wrong:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Automated%20Builds/

MinGW-w64 is a fork of the original MinGW. The main difference is
that MinGW-w64 supports 32 bit and 64 bit compilers, while MinGW
only supports 32 bit. IMHO MinGW-w64 is better maintained.

For QEMU, I prefer MinGW-w64 because it allows builds without
compiler warnings, so I can use -Werror.

MinGW-w64's dirent.h does not declare d_type and the related macros
DT_DIR, DT_LINK and DT_UNKNOWN. These macros are checked in
the conditional compilation in util/path.c.

Stefan

Patch

diff --git a/util/path.c b/util/path.c
index f0c6962..623219e 100644
--- a/util/path.c
+++ b/util/path.c
@@ -39,7 +39,7 @@  static int strneq(const char *s1, unsigned int n, const char *s2)
 }
 
 static struct pathelem *add_entry(struct pathelem *root, const char *name,
-                                  unsigned char type);
+                                  unsigned type);
 
 static struct pathelem *new_entry(const char *root,
                                   struct pathelem *parent,
@@ -82,7 +82,7 @@  static struct pathelem *add_dir_maybe(struct pathelem *path)
 }
 
 static struct pathelem *add_entry(struct pathelem *root, const char *name,
-                                  unsigned char type)
+                                  unsigned type)
 {
     struct pathelem **e;