This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Unreviewed patch for c-decl.c


Hi,

Thank you for your review and comments.

This would appear to restrict allocation of a declaration-via-typedef
to .data until you consider that (1) the array elements are const, (2)
array types are not modifiable lvalues.  Therefore neither the array
type nor the array element type can be modified, therefore they are both
const, therefore they can safely be located in .rodata.

The majority of surveyed compilers for a variety of architectures do
place the data in .rodata regardless of whether they are defined via a
typedef or not.  Furthermore, gcc is itself inconsistent on this issue:

 - declaration via typedef results in the variable being assigned to the
.data section
 - direct declaration (no typedef) results in the variable being
assigned to the .rodata section
 - the C++ compiler assigns both declaration via typedef and direct
declaration of the variable to .rodata

I am not aware of any change in C++ that should make the behaviour of
such a declaration any different to C89.

Therefore I think though there is no requirement for an ANSI-compliant C compiler to place 
the variable in .rodata, it the natural section for a const array to be assigned to.

Furthermore, it is the user's expectation that the data will be placed
in .rodata (and doing so will prevent accidental modification, e.g. as a
result of a buffer overrun, etc.).  

Finally, gcc is inconsistent in its handling of const arrays and differs from all 
other surveyed compilers in this regard.

Regards,
Dhananjay


> -----Original Message-----
> From: Joseph S. Myers [mailto:jsm@polyomino.org.uk]
> Sent: Wednesday, October 01, 2003 12:46 AM
> To: Dhananjay R. Deshpande
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: Unreviewed patch for c-decl.c
> 
> 
> On Tue, 30 Sep 2003, Dhananjay R. Deshpande wrote:
> 
> > http://gcc.gnu.org/ml/gcc-patches/2003-09/msg01485.html
> 
> But the qualifiers of an array element type *aren't* qualifiers of the
> array type, and even if you use typedefs to apply the 
> qualifiers directly
> to the array type, they still become qualifiers of the 
> element type not of
> the array type (6.7.3#8).  You need a much more detailed 
> justification of
> why giving the array type the wrong qualifiers would never cause a
> violation of the C standard.
> 
> -- 
> Joseph S. Myers
> jsm@polyomino.org.uk
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]