------- Comment #6 from rogerio at rilhas dot com 2010-08-12 15:33 ------- (In reply to comment #4) > Pretty please, before filing further bugs take time and learn C. > The pointer subtraction triggers undefined behavior, because one pointer > points > to one object and the other pointer points to different object.
Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. I'm subtracting 2 pointers of the same type. If you knew how to read you would have seen that p1 and p2 are of the same type. Or maybe you just don't know C, but I'm sure you can learn it so that you can be helpful to the GCC team and not waste my time. > See ISO C99, 6.5.6/9. I did read it, but it is not the case here, you got it wrong. > In particular, in this testcase the functions are inlined Where did you get that idea from??? They are not inlined, you are wrong, check the assembler before imagining what is hapening. > and thus i and strp > are just normal automatic variables in main, obviously nothing guarantees how > they are laid out in the stack. Wrong, you should learn your C. You could have understood this by yourself if you realized that &i works but &10 doesn't. If you knew your basic C you would know that both "strp" and "i" were passed by value, and so they are not the original in the "main" but instead copies in "bug_example". I'm sure you would want it not to be so, to save face, but you said it now you're stuck with it. But even if it isn't inlined, the behavior > would be undefined. Wrong again. Undefined by C99 but not undefined by cdecl. I didn't specify "inline", so GCC should have made cdecl. If it didn't then GCC should not claim to be cdecl. So choose: is it GCC's bug possibility 1 or possibility 2? (is it really that easy for you to write such wrong answers for everyone to see and keep wasting my time like this??? ... do you think that helps GCC?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
