[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-diffutils] [PATCH 2/3] portability: declare variables first in

From: Peter Rosin
Subject: Re: [bug-diffutils] [PATCH 2/3] portability: declare variables first in blocks
Date: Mon, 13 Feb 2012 09:08:44 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

Jim Meyering skrev 2012-02-12 19:13:
> Peter Rosin wrote:
>> * src/dir.c (diff_dirs): Declare 'v1' at the top of the block.
>> (find_dir_file_pathname): Likewise for 'p'.
>> * src/io.c (find_and_hash_each_line): Likewise for 'repetitions'.
> Hi Peter,
> I find that such patches hurt readability and maintainability and are
> nearly impossible to justify these days.  If they are indeed required
> for MSVC, I would prefer to maintain a separate c99-to-c89.diff patch
> file that is applied (even manually) by those who need it.

To me, it seems easier and more maintainable to just declare these three
variables at the top of respective block, and *my* ability to read the
code is unaffected by such a tiny difference.  In order to maintain and
keep current such a patch, someone would have to identify culprits
anyway and why not just do the tiny change directly instead of moving
it out to some obscure patch file that...

Oh well, I was just passing and am not the one making decisions around
here.  I'm also not the one actually having to read the code, most of
the time anyway :-)

> I did that for coreutils for a long time, but stopped a few years ago
> because so few people appeared to be using it.  There, I even had a
> "make check" rule that would ensure the .diff file applied cleanly.
> Would you be interested in maintaining such changes for MSVC?  If so,
> please document the version of the compiler so that we will know if/when
> it is likely to be no longer relevant.

I'm not really interested, I wouldn't be using the results anyway as
diff is already available in MSYS and Cygwin.  I'm not even sure what
the value is of diff as a "pure" (i.e. non-MSYS, non-Cygwin) Windows
binary is.  That limited value is also made evident by the fact that
the testsuite behaves as badly on MSYS with the MinGW gcc as it does
when compiled with MSVC.

Regarding what version of the compiler this is, it is at the time of
writing relevant to *all* versions of the MSVC compiler.  Annoying
as that is...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]