This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/11751] wrong evaluation order of an expression
- From: "pinskia at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 23 Feb 2005 20:51:19 -0000
- Subject: [Bug c/11751] wrong evaluation order of an expression
- References: <20030731175202.11751.me@elitsa.net>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23 20:51 -------
(In reply to comment #30)
> I'm not sure what you mean by the system(...) call... I understand that the code
> is undefined (meaning its up to the compiler vendor to implement as they see
> fit). I think the most fitting way is to have the above two cases unified in
> behaviour... isn't one of the reasons that operators were added to C++ was to
> allow user-defined types to mimic the functionality and usability of the native
> C types?
Undefined means that we can do anything. Which where the system call comes from. The point is that
this undefined, there does not even have be a constancy in the behavior across optimization levels,
types or anything else.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751