https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #13 from Jonny Grant <jg at jguk dot org> ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Jonny Grant from comment #8)
> > Do you agree this warning output should be changed to clarify?
>
> Yes, there's plenty of room to improve it.
>
> > I understand your reply about it being non-POD when a C++ STL string is
> > added. Which adds the implicitly-defined copy constructor. Should it not say
> > "implicitly-defined copy constructor for 'struct info'"? instead of "this
> > function" ?
>
> That might be an improvement, but may not be easy to do. I doubt the code
> generating that warning knows it's in an implicitly-defined member.
>
> > Think also better for GCC to show the typedef 'info_t' - would you agree?
>
> No, I don't think so.
>
> What's the point in that typedef anyway?
In C++ it is allowed to omit the struct keyword where there is no ambiguity. I
just always write it.
The typedef keyword allows a programmer to assign an alternative name, and save
the "struct" keyword in C.
>
>
> (In reply to Jonny Grant from comment #10)
> > I wonder if the "POD" location of the struct
>
> What does that mean?
As I understand it, the POD location of the warning is shown when there are no
implicit copy-constructor. That is cpp line 12.
header.cpp: In function ‘void test(info)’:
header.cpp:12:10: error: ‘copy’ is used uninitialized in this function
[-Werror=uninitialized]
temp = copy;
~~~~~^~~~~~
Where there is an implicit copy constructor, it shows the wrong file, and wrong
function.
header.h: In function ‘int main()’:
header.h:8:16: error: ‘temp.info::registered’ is used uninitialized in this
function [-Werror=uninitialized]
typedef struct info
^~~~
