Re: c++/10332: Template classes are not instantiated correctly in presense of #pragma pack()

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

The following reply was made to PR c++/10332; it has been noted by GNATS.

From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
To: igusarov at akella dot com
Cc: velco at fadata dot bg, ljrittle at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org,
   gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Subject: Re: c++/10332: Template classes are not instantiated correctly in presense of #pragma pack()
Date: Mon, 14 Apr 2003 18:42:04 -0500 (CDT)

 In article <3E9A8732 dot 7000600 at akella dot com>,
 "Igor A. Goussarov" <igusarov at akella dot com> writes:
 
 >>>> What is the scope of #pragma pack ? 
 Igor> Apparently, from the line it is encountered at till the end of
 Igor> translation unit or till the next #pragma pack.
 >> In that case holding it in a global variable looks appropriate, no ?
 
 >     Up to a certain degree, yes. The concept of "packing" is applied to 
 > structures, thus the packing size is a property of each structure. 
 > Holding it in a global variable is justifiable only if there's 
 > absolutely no chance that this variable could potentially be altered 
 > before it is used to create an internal compiler representation of the 
 > structure in question. I grant that C plain structures are 
 > "instantiated" immediately at the point of their definition. C++ 
 > templates are not. [...]
 
 >     By now, I'm most interested in figuring out the point of view of the 
 > gcc developers: do you tend to think that the current interference of 
 > #pragma pack and templates is an undocumented feature or an incorrect 
 > behaviour?
 
 Agreed.  The proper fix is to either (a) document what is happening,
 only available if no external spec says we are doing something wrong,
 or (b) retain the global flag but capture it's value and bind it for
 use when the C++ template is actually instantiated.
 
 I'd favor (b) unless disallowed by the spec(s) that we claim to
 implement for this pragma.  This is either an easy patch (if the
 infrastructure allows it) or a nightmare (if it doesn't).  FYI, if
 updating the documentation is not enough, this is outside my area to
 productively fix.
 
 Regards,
 Loren