On 09/26/2014 10:40 PM, Junio C Hamano wrote: > Michael Haggerty <mhag...@alum.mit.edu> writes: > >> +If you need to close the file descriptor you obtained from a >> +`hold_lock_file_*` function yourself, do so by calling >> +`close_lock_file`. You should never call `close(2)` yourself! > > This is sometimes untenable, isn't it? A caller may want to > freopen(3) a stream on the fd to write into it and then fclose(3); > which would not know to call close_lock_file() but calls close(2).
You are absolutely correct. I carried this text over from the old version, where it was just as inaccurate. I didn't fix it because IMO the correct fix is to add a stdio-oriented entry point to the lockfile API, and teach the lockfile code to handle closing the FILE correctly when necessary. But I didn't want to add even more changes to this patch series, so I am working on this as a separate patch series. I hope to submit it soon. Michael -- Michael Haggerty mhag...@alum.mit.edu -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
