Proposed solution for bug 44384, "builtin_object_size_ treatment of multidimensional arrays is unexpected"

[Mark Eklund]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I am trying to get a solution for bug 44384, "builtin_object_size_
treatment of multidimensional arrays is unexpected", and would like 
to know if my approach is right.

First, a quick recap of the issue.

The issue at hand is that __builtin_object_size(ptr, type) always treats
multidimensional arrays as whole objects instead of treating each
dimension as a sub-object which results in unexpected results from
__builtin_object_size(ptr, type) when type & 1 does not equal zero.

As this is of significant interest, I have started to work on a possible
solution to this issue.  Basically, the function, addr_objec_size(),
appears to be the heart of the __builtin_object_size() function.
However, after tracing the gcc source to see how the sizeof operator
works as well as checking to see how gcc handles cases such as:

void foo(char *)
{
//stuff
}

int main()
{
char c[10][20][30];

foo(c);
foo(c[2]);
}

I am of the opinion that addr_object_size() lacks the necessary
information to correctly determine which dimension of c is really being
looked at.  Therefore, I am looking at ways to somehow append some of
the original type data to the arguments passed in to addr_object_size()
and then use that information where appropriate.  One approach I am
considering is to append the data to the end of the tree before
fold_unary_loc() returns with the hopes that the appended data will be
available to addr_object_size().

However, I would like some feedback as to whether this is the proper
approach to take, and if so, what the best function to attempt this in
would be.  I have already tried convert_for_assignment() (which seems to
be too early).  This leads me to believe that the function I am looking
for might be one of the functions that handle the conversion of the
generic tree to the gimple tree.

Again any feedback that would help point me in the right direction would
be appreciated.

Thanks,

=mark

- -- 
Mark Eklund
Software Engineer
Product Development
mekl...@cisco.com
Cisco Systems, Inc.
170 West Tasman Dr
San Jose, CA 95134 USA
United States
Cisco.com - http://www.cisco.com

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2QkvwACgkQQ0N2P/sOd5he+QCgltwvrRjSvOwSUgaDxLzLqasD
husAoLZQ+FUNx5smq4VyCo9heJl+VT2a
=myNY
-END PGP SIGNATURE-

Re: Proposed solution for bug 44384, "builtin_object_size_ treatment of multidimensional arrays is unexpected"

[Mark Eklund]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 3/28/11 10:37 AM, Richard Guenther wrote:
>> On Mon, Mar 28, 2011 at 3:54 PM, Mark Eklund  wrote:



>> 
>> Again any feedback that would help point me in the right direction would
>> be appreciated.
>> 
> What do you want to do with the information from __builtin_object_size?
> Note that it was invented for a single special reason, it is probably not
> suitable for anything else (and its somewhat fragile implementation shouldn't
> be complicated by other usages).

I use FORTIFY_SOURCE with a USE_FORTIFY_LEVEL of 2
and was surprised that the below code allowed
writing into fu[4][0].  I expected that at a
level of 1, but not 2.

#include 

int bar ()
{
char fu[10][10];
strcpy(fu[3], "ten counts");
return 0;
}

=mark

> 
>> Richard.
> 
> Thanks,
> 
> =mark
> 
>>

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2TPHoACgkQQ0N2P/sOd5jAcgCffteA2GdpVSgJNEjspiWJ943G
whkAni8sqeumrnOvizMDorW/ZkveNV+4
=GKWj
-END PGP SIGNATURE-