Re: [PATCH v4 0/3] Take four on fixing OPT_SET_PTR issues

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v4 0/3] Take four on fixing OPT_SET_PTR issues

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:00:35

Marat Radchenko [off-list ref] writes:
Patches summary:
1. Fix initial issue (incorrect cast causing crash on 64-bit MSVC)
2. Improve OPT_SET_PTR to prevent same errors in future
3. Purge OPT_SET_PTR away since nobody uses it

*Optional* patch №3 is separated from №1 and №2 so that if someone someday
decides to return OPT_SET_PTR back by reverting №3, it will be returned
in a sane state.

Decision of (not) merging №3 is left as an exercise to the reader due to
my insufficient knowledge of accepted practices in Git project.
SET_PTR() may not be used, but are there places where SET_INT() is
abused with a cast-to-pointer for the same effect?  I didn't check,
but if there are such places, converting them to use SET_PTR() with
their existing cast removed may be a better way to go.

My suspicion is that there would be none, as switching the behaviour
based on a small integer flag value is far easier than swapping the
pointer to a pointee to be operated on, when responding to a command
line option.

Re: [PATCH v4 0/3] Take four on fixing OPT_SET_PTR issues

From: Jeff King <hidden>
Date: 2016-06-15 23:00:35

On Mon, Mar 31, 2014 at 10:23:44AM -0700, Junio C Hamano wrote:
SET_PTR() may not be used, but are there places where SET_INT() is
abused with a cast-to-pointer for the same effect?  I didn't check,
but if there are such places, converting them to use SET_PTR() with
their existing cast removed may be a better way to go.
Anyone doing that should be beaten with a clue stick.

Fortunately, I grepped through and I did not see any cases. My clue
stick remains untouched.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help