------- Comment #49 from rogerio at rilhas dot com 2010-08-11 23:22 ------- (In reply to comment #40) > (In reply to comment #39) > > (In reply to comment #37)
> Why do you think GCC makes it the address of a copy? Well, the first observation was dumpung the memory around the returned address to see that the other parameters were not there. The second observation was to see that the original object pushed by the caller of direct_format was writen to an address which was not the one obtained in "format_indirect". Both are strong indicators. The first because I see the disassembly showing a sequence of pushes for all parameters (hence, knowing x86, I trust they will be adjacent although I can't check individual movements because I was unable to trace individual assenbly instructions, but I checked the stack address after the pushes and they are all sequential in memory). These parameters are never changed in the stack, and keep adjacent all the time. So, accessing "format_address" should reveal them. The second is very difficult to observe in compiled code because any access to "&format" before passing it as a parameter to "format_indirect" seems to fix the problem (this is the basis for my workaround). However, I was able to hardcode some printf's to locations where I knew the variables would be and observe the results: the pushed parameters are kept adjacent, but the address_format is somewhere else. My guess is that it is pointing to the "rom" address where the string is stored in the executable, but I cannot be sure. > You are wrong here. The next paragraph, 6.5.6/8, explains that, > "... otherwise the behavior is undefined. If the result points one past > the last element of the array object, it shall not be used as the operator > of a unary * operator that is evaluated.". Where I point you to > 6.5.3.2/3 if you now claim that x[2] isn't invoking the unary * operator. You are the ones saying that char** format_address is equivalent to a 1-entry array. I have stated often that the array to which PTR4 points is an array of 4 entries, backed by cdecl. But if your interpretation is that access to X+4 fails because the behaviour is undefined because GCC generates code as that for a 1-entry array at address X, and then generates some code to make accesses to address X+4 or X+8 (and so on) fail, then no problem: just have GCC return the correct address X and I'll do the accesses in assembly where I can trust what happens when I access X+4. Note that your argument (of undefined behaviour) is only valid for declared arrays, which I still think is not the case here. Or, at least, it points to a 4-entry array. Also note that your argument does not backup the claim why GCC can return a wrong address for &format. I also believe that you know that if GCC did return the original address X on the stack then the "undefined" behaviour of [X+1] would be to return the 4 bytes at X+4 without any problem, right? Or does GCC generate specific code to make this memory access fail? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
