From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17674 invoked by alias); 11 Aug 2010 23:43:38 -0000 Received: (qmail 17581 invoked by uid 48); 11 Aug 2010 23:43:26 -0000 Date: Wed, 11 Aug 2010 23:43:00 -0000 Message-ID: <20100811234326.17580.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rogerio at rilhas dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00920.txt.bz2 ------- Comment #50 from rogerio at rilhas dot com 2010-08-11 23:43 ------- (In reply to comment #48) > >No, cdecl states that &x+1==&y, and that &x+2==&z. > Maybe the ABI says that but that does not mean you can access "&x + 1" to get > to &y at least in a "standard" defined way. That is the whole point of it > acting as it was an array of size 1. Please note what you are saying. You mean that if, under GCC, I write some code like: void func_anything(void) { char** PTR4=random_anywhere_in_valid_user_space_including_stack(); char* a=PTR4[0]; char* b=PTR4[1]; char* c=PTR4[2]; char* d=PTR4[3]; } Are you telling me that GCC will not generate code to get propper values for "b", "c", and "d" because reading past "a" is undefined? Note that the random function does not define an "array in the C sense", it just returns a pointer no different than "format_address". The randomizer could, in fact, by something like my_malloc_hand_crafted_with_no_relation_to_malloc_and_allocating_memory_directly_from_the_os()... are you saying I would not be able to predictably access any of its bytes (since it would not be related to an array of bytes "in the C sense"? Now instead of a randomizer or a my_malloc I just called get_random_address_exclusivelly_in_stack_space(), would access fail then? And if instead I just called: func foo(int x, int y, int z) { int* PTR4=get_random_address_from_triplet(&x, &y, &z); int new_var=*PTR4; } Would it fail here for new_var? If not, I could just write something like: func foo(int x, int y, int z) { int* PTR4_x=get_random_address_from_triplet_but_make_sure_its_x(&x, &y, &z); int new_x=*PTR4_x; int* PTR4_y=get_random_address_from_triplet_but_make_sure_its_y(&x, &y, &z); int new_y=*PTR4_y; int* PTR4_z=get_random_address_from_triplet_but_make_sure_its_z(&x, &y, &z); int new_z=*PTR4_z; } Would this work? I'm not sure where this conversation is going to, but if this code worked I could be a pretty good workaround for my indirect format. It must work, right, I don't know which part of C99 says is, but if it didn«t work then GCC would be useless and we know it is not. So, the only possible conclusion is that "format_address" does not behave as a 1-entry array, because all these examples would lead to undefined results, and so it must, in the very least, correspond to a 4-entry array (because I know I can read the RAM locations with code generated by GCC). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249