public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: "Giovanni Bajo" <giovannibajo@libero.it> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: c++/10065: -pedantic has strange side effects; what is accepted in -std=c++98 Date: Mon, 19 May 2003 13:36:00 -0000 [thread overview] Message-ID: <20030519133600.31289.qmail@sources.redhat.com> (raw) The following reply was made to PR c++/10065; it has been noted by GNATS. From: "Giovanni Bajo" <giovannibajo@libero.it> To: "Baldwin, Arthur W" <Arthur.Baldwin@gd-ais.com>, <gcc-bugs@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org> Cc: Subject: Re: c++/10065: -pedantic has strange side effects; what is accepted in -std=c++98 Date: Mon, 19 May 2003 15:27:06 +0200 Baldwin, Arthur W <Arthur.Baldwin@gd-ais.com> wrote: > I do not understand the resolution of this problem. The response below says > in part: > > Variable sized array are not supposed to be disabled with > -ansi or -std=c++98 because they can't possibly conflict > with well-formed ISO programs. > > The reason I reported the issue is that I cannot compile a program with > variable sized arrays with flags such as -ansi or -std=c++98. The compiler > (gcc-3.2.2 on Linux) issues errors and aborts the build. With -pedantic, > however, I get a warning, but the build completes. Older versions of the > compiler handled the variable sized arrays without any flags. Sorry if I wasn't clear. There are two different issues in your code: ************************* First issue (within main()): you are assigning arrays (lines 19 "y = x", and 28 "y2 = x2"). This is forbidden by ISO C++ standard. GCC correctly emits an error about this: arrayTest.cc:19: ISO C++ forbids assignment of arrays arrayTest.cc:28: ISO C++ forbids assignment of arrays Now, this is a hard error, as it should be. The workaround is memcpy(), of course. *BUT*, GCC currently has a bug: when you add -pedantic, some errors magically turns into warnings (this very problem is tracked by PR10032). So your compilation incorrectly succeeds with -pedantic because of this bug. This behaviour has nothing to do with -ansi or -std, becuase they don't have this magic bug. You can isolate your main() function into a separate file, and experiment with it to check what I'm saying. As you can see, this funciton does not contain variable length arrays, so it has nothing to do with it (and the error message does not speak about variable length array, it speaks about assignment of arrays). ************************* Second issue (within printMatrix()): you are using variable lentgh arrays here. This is a GCC extension, so it is accepted by GCC. -ansi (or -std) turn off _only_ GCC extensions that might conflict (as in: change the meaning / reject) of a well-formed ISO C++ program. Since a well-formed ISO C++ program would be invalid with variable length array, this extension does not conflict with the standard in any way, and it is not turned off with -ansi/-std. If one wants to disable GCC extension altogether, the right option is "-pedantic" (or "-pedantic-errors"). When you put "-pedantic" on the command line, GCC emits a warning about your variable length arrays (as it should): arrayTest.cc:38: warning: ISO C++ forbids variable-size array `matrixType' arrayTest.cc:38: warning: ISO C++ forbids variable-size array `matrixType' If you put "-pedantic-error", it emits an error about it (as it should). Everything works as expected. You can isolate your printMatrix() function and check this behaviour. > The question is: Does gcc support variable sized arrays or not, Yes, and it works for you in fact. Exactly like it should. > and will > the compiler support the variable sized arrays into the future? I can't foresee the future, but if it will be ever removed, be sure that there will be some deprecation warning for at least one major version. For now, it's ok. > We have > legacy, delivered code that exploits the variable-sized array capability of > an older compiler, and I have to know whether we should prepare to rewrite > the code in a maintenance upgrade when we evolve to a new OS and new > compiler. At the moment, the only way I could redeliver the code would be > to compile with -pedantic, and then explain away the warnings. Without > -pedantic, IT WON'T COMPILE. This has _nothing_ to do with variable length array. Your code is ill-formed because it copies two arrays, in line 19 and 28. I don't know if this used to be a GCC extension, but surely it is not anymore. You should rewrite your code in those lines to use memcpy(). The fact that it works with -pedantic is only a side effect of the bug tracked by PR10032 (-pedantic sometimes incorrectly turns errors into warnings, allowing compilation of ill-formed code). > Sorry if I'm being dense about the response, but it doesn't seem to address > my concern. I hope that everything is clear now. The only issue in your PR is about -pendatic turning errors into warnings, and it's already tracked by another open PR. So I closed yours. Giovanni Bajo
next reply other threads:[~2003-05-19 13:36 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-05-19 13:36 Giovanni Bajo [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-05-16 1:59 giovannibajo 2003-03-22 4:22 bangerth
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030519133600.31289.qmail@sources.redhat.com \ --to=giovannibajo@libero.it \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).