[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[faure at kde dot org]

------- Comment #2 from faure at kde dot org  2005-10-20 10:25 -------
Could a -W option be added so that, if I want gcc to abort on such errors, it
can be asked to do that? (without aborting on all other warnings, of course)

This 'undefined behavior' does crash at runtime, so it is really important to
catch such mistakes at compile time, and simple warnings often go unnoticed...


-- 

faure at kde dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |faure at kde dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[wallaces3 at yahoo dot com]

------- Comment #3 from wallaces3 at yahoo dot com  2009-08-13 04:02 -------
I totally agree with David Faure, please make this warning controllable:
-Werror=invalid-offsetof

All other warnings have a type that can be ignored, but when using the
-fdiagnostics-show-option option to see what the warning type is for this
non-POD warning I was amazed that it does not have a type.  In the
gcc/Warnings-Options.html the type is listed as invalid-offsetof
Please, please, please make this warning controllable.
Thanks.


-- 

wallaces3 at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wallaces3 at yahoo dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[redi at gcc dot gnu dot org]

------- Comment #4 from redi at gcc dot gnu dot org  2009-08-13 10:31 -------
(In reply to comment #1)
> It cannot be as it is only undefined behavior and the C++ (and C standard by the way) says that 
> undefined behavior cannot be an error only a warning.

I don't know about C, but C++ says:

"permissible undefined behavior ranges from ignoring the situation completely
with unpredictable results, to behaving during translation or program execution
in a documented manner characteristic of the environment (with or without
the issuance of a diagnostic message), to terminating a translation or
execution (with the issuance of a diagnostic message)." [defns.undefined]

So it is permissible to terminate translation and issue a diagnostic.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[joseph at codesourcery dot com]

------- Comment #5 from joseph at codesourcery dot com  2009-08-13 12:23 -------
Subject: Re:  Warning "cannot pass objects of non-POD type"
 should be an error

On Thu, 13 Aug 2009, redi at gcc dot gnu dot org wrote:

> I don't know about C, but C++ says:
> 
> "permissible undefined behavior ranges from ignoring the situation completely
> with unpredictable results, to behaving during translation or program execution
> in a documented manner characteristic of the environment (with or without
> the issuance of a diagnostic message), to terminating a translation or
> execution (with the issuance of a diagnostic message)." [defns.undefined]
> 
> So it is permissible to terminate translation and issue a diagnostic.

You have to read the relevant standard text carefully to determine whether 
it is the program that is undefined, or a particular execution of the 
program, in this particular instance of undefined behavior.  If the 
undefinedness is a property of the program (for example, ODR violation), 
translation may be terminated.  If the undefinedness is a property of a 
particular execution of the program (for example, signed integer 
overflow), translation may not be terminated unless all possible 
executions of the program exhibit that undefined behavior.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[redi at gcc dot gnu dot org]

------- Comment #6 from redi at gcc dot gnu dot org  2009-08-13 12:51 -------
(In reply to comment #3)
> I totally agree with David Faure, please make this warning controllable:
> -Werror=invalid-offsetof
> 
> All other warnings have a type that can be ignored, but when using the
> -fdiagnostics-show-option option to see what the warning type is for this
> non-POD warning I was amazed that it does not have a type.  In the
> gcc/Warnings-Options.html the type is listed as invalid-offsetof

I don't think the docs do say that.  -Winvalid-offsetof may be related to
non-POD types but is distinct from this error.

(In reply to comment #5)
> You have to read the relevant standard text carefully to determine whether 
> it is the program that is undefined, or a particular execution of the 
> program, in this particular instance of undefined behavior.  If the 
> undefinedness is a property of the program (for example, ODR violation), 
> translation may be terminated.  If the undefinedness is a property of a 
> particular execution of the program (for example, signed integer 
> overflow), translation may not be terminated unless all possible 
> executions of the program exhibit that undefined behavior.

Passing a non-POD class type to a variadic function is a property of the
program, detectable at compile time, so I think it would be conforming to make
it an error (please correct me if I've misunderstood.)

I don't feel strongly about making it always an error, but I disagree that this
request is INVALID because the standard forbids making it an error.  It seems
like a valid enhancement to add a new warning option so this users can choose
to make it an error.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[redi at gcc dot gnu dot org]

------- Comment #7 from redi at gcc dot gnu dot org  2009-08-21 16:51 -------
The relevant text in the standard is changing to make it
conditionally-supported, and it's now documented that this isn't supported by
GCC:
http://gcc.gnu.org/onlinedocs/gcc/Conditionally_002dsupported-behavior.html

On that basis it seems correct to make it a hard error for -std=c++0x at least.


-- 

redi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[manu at gcc dot gnu dot org]

-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[manu at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]



------- Comment #8 from manu at gcc dot gnu dot org  2010-04-15 18:08 -------
GCC 4.5 gives an error. 
pr19291.C: In function ‘int main()’:
pr19291.C:6:19: error: cannot pass objects of non-trivially-copyable type
‘struct std::string’ through ‘...’

So FIXED as far as i can see.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-06 14:04 -------
(In reply to comment #0)
> <code>
> #include <string>
> #include <cstdio>
> int main()
> {
>   std::string s("Hello World");
>   printf("%s\n", s);
>   return 0;
> }
> </code>


It cannot be as it is only undefined behavior and the C++ (and C standard by the way) says that 
undefined behavior cannot be an error only a warning.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291