emacs-devel
[Top][All Lists]
Advanced

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

Re: Omitting Windows-specific parts from infrastructure changes


From: Eli Zaretskii
Subject: Re: Omitting Windows-specific parts from infrastructure changes
Date: Wed, 21 Jan 2015 17:48:38 +0200

> Date: Tue, 20 Jan 2015 13:28:10 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
>         it still works, in the places where the MS-Windows code still uses 
> strcat 
>         instead of stpcpy.
> 
>     Beg your pardon, but how do you know this?
> 
> Because I made an extra effort to check, as part of following up this 
> conversation.

Which changeset did you check?  There were quite a few of them.  It
could be that some of them didn't break anything, but some certainly
did.

And leaving portions of Emacs out of the set of files that is kept in
good shape is bad for maintenance, so even changes that don't break
need to be made everywhere, at least as a goal.

>     just post those notes once when you first do the examination
>
> I don't have any notes to post.  I don't write notes for this sort of thing.

"Notes" is just a word.  I'm asking you to post the information that
can be used by someone else to find the places which you omitted from
the scope of your changes.  That information is certainly available to
you when you are working on the changeset, so just publish it whenever
it's the most convenient moment for you.

> Honestly, I don't see why this is such a big deal. Anyone who's curious about 
> uses of strcat in the MS-Windows code can easily search the code for 
> instances of the string "strcat".

_After_ we know that the changeset had to deal with strcat following
strcpy, yes, it's a simple thing to find those places.  But that's
exactly what I'm asking you to publish -- the description of what to
look for, either as plain text or as a script that does the job, if
you used such a script and have it available.

Without this information, one has to somehow glean it by
reverse-engineering your commits.  Which is not easy, because they are
complex and quite often include changes not directly related to the
main issue of the changeset.  So this process is error-prone and takes
precious time.

Take your suggested changes in bug#19634: I think you left out at
least one place in w32 files, but I cannot be sure without knowing
calls to which functions should be converted to use CALLN.  I need to
read a 1800-odd line patch to try to understand that, whereas it would
have taken you no more than a single sentence to describe that
clearly.

Honestly, I don't see why it's such a big deal to make this job much
easier by simply publishing the information that is clear to you and
at your fingertips when you work on the changeset.  It is a very small
overhead for you, and a huge benefit for me.  So I'm asking you to
please humor me with this small favor.

> And if nobody bothers to do the search, that's fine too.

That might be your personal goal, but please don't punish your fellow
developers that happen to disagree with you on that.  We all have our
personal preferences, but we shouldn't go after fellow developers
whose preferences are different.  If we do, what kind of team are we?



reply via email to

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