Re: [PATCH 0/4] drop some int x = x hacks to silence gcc warnings
On Thu, Mar 21, 2013 at 11:44:02AM -0400, Jeff King wrote: I am for dropping = x and leaving it uninitialized at the declaration site, or explicitly initializing it to some reasonable starting value (e.g. NULL if it is a pointer) and adding a comment to say that the initialization is to squelch compiler warnings. I'd be in favor of that, too. In many cases, I think the fact that gcc cannot trace the control flow is a good indication that it is hard for a human to trace it, too. And in those cases we would be better off restructuring the code slightly to make it more obvious to both types of readers. Two patches to follow. [5/4]: fast-import: clarify inline logic in file_change_m [6/4]: run-command: always set failed_errno in start_command And here are two more; with these, our code base should be free of x = x initializations (at least according to clang). [7/4]: submodule: clarify logic in show_submodule_summary [8/4]: match-trees: drop x = x initializations Not pressing, obviously, but since I had just analyzed the code yesterday, I wanted to do it while they were still fresh in my mind. -Peff -- 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
Re: [PATCH 0/4] drop some int x = x hacks to silence gcc warnings
Am 3/21/2013 12:03, schrieb Jeff King: I was fooling around with clang and noticed that it complains about the int x = x construct under -Wall. That is IMHO a deficiency in clang, since the idiom has a well-defined use in silencing -Wuninitialized warnings. IMO, that's a myth. The construct invokes undefined behavior at least since C99, and the compilers are right to complain about it. But you might just say that standards are not worth the paper they are printed on, and you may possibly be right for practical reasons. But I still consider it a myth that int x = x is an idiom. I'm in the C business since more than 25 years, and the first time I saw the idiom was in git code. Is there any evidence that the construct is used elsewhere? Have I been in the wrong corner of the C world for such a long time? -- Hannes -- 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
Re: [PATCH 0/4] drop some int x = x hacks to silence gcc warnings
On Thu, Mar 21, 2013 at 12:45:37PM +0100, Johannes Sixt wrote: Am 3/21/2013 12:03, schrieb Jeff King: I was fooling around with clang and noticed that it complains about the int x = x construct under -Wall. That is IMHO a deficiency in clang, since the idiom has a well-defined use in silencing -Wuninitialized warnings. IMO, that's a myth. The construct invokes undefined behavior at least since C99, and the compilers are right to complain about it. While undefined behavior does leave the compiler free to do anything, including nasal demons, it would be a very poor implementation that did anything except leave random bytes in the value. And it also means that gcc is free to take it as a hint to silence the warning; given that clang tries to be compatible with gcc, I'd think it would want to do the same. But I may be wrong that the behavior from gcc is intentional or common (see below). But you might just say that standards are not worth the paper they are printed on, and you may possibly be right for practical reasons. But I still consider it a myth that int x = x is an idiom. I'm in the C business since more than 25 years, and the first time I saw the idiom was in git code. Is there any evidence that the construct is used elsewhere? Have I been in the wrong corner of the C world for such a long time? Git code was my introduction to it, too, and I was led to believe it was idiomatic, so I can't speak further on that. I think it was Junio who introduced me to it, so maybe he can shed more light on the history. -Peff -- 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
Re: [PATCH 0/4] drop some int x = x hacks to silence gcc warnings
Johannes Sixt wrote: Am 3/21/2013 12:03, schrieb Jeff King: I was fooling around with clang and noticed that it complains about the int x = x construct under -Wall. That is IMHO a deficiency in clang, since the idiom has a well-defined use in silencing -Wuninitialized warnings. IMO, that's a myth. The construct invokes undefined behavior at least since C99, and the compilers are right to complain about it. And I complained about this a couple months ago, as the compiler on HP-NonStop stumbles across this too (by emitting a warning) Bye, Jojo -- 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
Re: [PATCH 0/4] drop some int x = x hacks to silence gcc warnings
Joachim Schmitz wrote: Johannes Sixt wrote: Am 3/21/2013 12:03, schrieb Jeff King: I was fooling around with clang and noticed that it complains about the int x = x construct under -Wall. That is IMHO a deficiency in clang, since the idiom has a well-defined use in silencing -Wuninitialized warnings. IMO, that's a myth. The construct invokes undefined behavior at least since C99, and the compilers are right to complain about it. And I complained about this a couple months ago, as the compiler on Actually on August 20th, 2012... HP-NonStop stumbles across this too (by emitting a warning) Bye, Jojo -- 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
Re: [PATCH 0/4] drop some int x = x hacks to silence gcc warnings
Jeff King p...@peff.net writes: Git code was my introduction to it, too, and I was led to believe it was idiomatic, so I can't speak further on that. I think it was Junio who introduced me to it, so maybe he can shed more light on the history. I think we picked the convention up from the kernel folks. At least that is how I first met the construct. The uninitialized_var(x) macro was (and still is) used to mark these The compiler is too dumb to realize, but we know what we are doing cases: $ git grep '#define uninitialized_var' include/ include/linux/compiler-gcc.h:#define uninitialized_var(x) x = x include/linux/compiler-intel.h:#define uninitialized_var(x) x but they recently had a discussion, e.g. http://thread.gmane.org/gmane.linux.kernel.openipmi/1998/focus=1383705 so... -- 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
Re: [PATCH 0/4] drop some int x = x hacks to silence gcc warnings
Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net writes: Git code was my introduction to it, too, and I was led to believe it was idiomatic, so I can't speak further on that. I think it was Junio who introduced me to it, so maybe he can shed more light on the history. I think we picked the convention up from the kernel folks. At least that is how I first met the construct. The uninitialized_var(x) macro was (and still is) used to mark these The compiler is too dumb to realize, but we know what we are doing cases: $ git grep '#define uninitialized_var' include/ include/linux/compiler-gcc.h:#define uninitialized_var(x) x = x include/linux/compiler-intel.h:#define uninitialized_var(x) x but they recently had a discussion, e.g. http://thread.gmane.org/gmane.linux.kernel.openipmi/1998/focus=1383705 so... While flipping the paragraphs around before sending the message out I managed to lose the important one. Here is roughly what I wrote: I am for dropping = x and leaving it uninitialized at the declaration site, or explicitly initializing it to some reasonable starting value (e.g. NULL if it is a pointer) and adding a comment to say that the initialization is to squelch compiler warnings. -- 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
Re: [PATCH 0/4] drop some int x = x hacks to silence gcc warnings
On Thu, Mar 21, 2013 at 08:19:43AM -0700, Junio C Hamano wrote: $ git grep '#define uninitialized_var' include/ include/linux/compiler-gcc.h:#define uninitialized_var(x) x = x include/linux/compiler-intel.h:#define uninitialized_var(x) x but they recently had a discussion, e.g. http://thread.gmane.org/gmane.linux.kernel.openipmi/1998/focus=1383705 so... While flipping the paragraphs around before sending the message out I managed to lose the important one. Here is roughly what I wrote: I am for dropping = x and leaving it uninitialized at the declaration site, or explicitly initializing it to some reasonable starting value (e.g. NULL if it is a pointer) and adding a comment to say that the initialization is to squelch compiler warnings. I'd be in favor of that, too. In many cases, I think the fact that gcc cannot trace the control flow is a good indication that it is hard for a human to trace it, too. And in those cases we would be better off restructuring the code slightly to make it more obvious to both types of readers. Two patches to follow. [5/4]: fast-import: clarify inline logic in file_change_m [6/4]: run-command: always set failed_errno in start_command -Peff -- 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
Re: [PATCH 0/4] drop some int x = x hacks to silence gcc warnings
Jeff King wrote: Two patches to follow. [5/4]: fast-import: clarify inline logic in file_change_m This one is clearly a bug / missing feature in gcc's control flow analysis, but your workaround looks reasonable. [6/4]: run-command: always set failed_errno in start_command Very sane. Thanks. -- 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
