------- Comment #4 from listor1 dot rombobeorn at comhem dot se 2005-12-06 22:21 ------- Subject: Re: Discriminant is left uninitialized.
laurent at guerby dot net wrote: > The problem is that you are using "Unbounded_String" in your record, and > this brings in lots of dope information for Finalization purposes. Your comment puzzles me. Do you really mean that the unbounded string is what causes the problem? Yes, I understand that it's involved in triggering the bug, but do you mean I should expect problems when using a controlled type inside a record type? > I assume you used 'address and stuff in your test case but not in your > original program. Yes. That was only to make the test case reproducible. > Could you provide a test case without 'address that has a > suspicious behaviour (even if not all the times)? I'm attaching uninitialized_field_2.adb, which is the same program but without the address clauses. Here's what I get when I run it: $ gnatmake uninitialized_field_2.adb gcc -c uninitialized_field_2.adb gnatbind -x uninitialized_field_2.ali gnatlink uninitialized_field_2.ali $ ./uninitialized_field_2 Initialized with Unified_Encoding_Record aggregate: With predefined "=" - A1a and A2a: equal Initialized with Character_Encoding aggregate: With predefined "=" - A1b and A2b: not equal With redefined "=" - B1c and B2c: equal OS of A1a: LINUX OS of A2a: LINUX OS of A1b: raised CONSTRAINT_ERROR : uninitialized_field_2.adb:92 invalid data Björn Persson ------- Comment #5 from listor1 dot rombobeorn at comhem dot se 2005-12-06 22:21 ------- Created an attachment (id=10429) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10429&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25245
