public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Nicolas Noble <nicolas@nobis-crew.org> To: gcc-gnats@gcc.gnu.org Subject: c++/7562: strange behaviour with typedef and consts Date: Fri, 09 Aug 2002 14:06:00 -0000 [thread overview] Message-ID: <20020809203729.2297.qmail@the-babel-tower.nobis-crew.org> (raw) >Number: 7562 >Category: c++ >Synopsis: const with typedefs doesn't work as expected. >Confidential: no >Severity: non-critical >Priority: low >Responsible: unassigned >State: open >Class: rejects-legal >Submitter-Id: net >Arrival-Date: Fri Aug 09 13:46:00 PDT 2002 >Closed-Date: >Last-Modified: >Originator: >Release: 3.1 >Organization: >Environment: System: Linux the-babel-tower 2.4.18 #2 Sun Apr 28 23:46:35 CEST 2002 i686 unknown Architecture: i686 host: i386-slackware-linux-gnu build: i386-slackware-linux-gnu target: i386-slackware-linux-gnu configured with: ../gcc-3.1/configure --prefix=/usr --enable-shared --with-gnu-ld --enable-threads --verbose --target=i386-slackware-linux --host=i386-slackware-linux >Description: Here is a problem I saw first with the zlib header. It's very easy to understand, I think you'll be able to understand with the How-To-Repeat section. In brief, it's when having a "const" with a previously typedef'ed type, the compiler forgets the "const", which only produces a warning in C compilation mode, but produces an error in C++ compilation mode. >How-To-Repeat: Here is the simple source code: $ cat typedef.cc typedef void * voidp; void func1(const voidp p) { } void func2(const void * p) { func1(p); } and what happen: $ gcc-3.1 -c typedef.cc typedef.cc: In function `void func2(const void*)': typedef.cc:6: invalid conversion from `const void*' to `void*' which is the worse case I think. With a .c extension it only does that: $ gcc-3.1 -c typedef.c typedef.c: In function `func2': typedef.c:6: warning: passing arg 1 of `func1' discards qualifiers from pointer target type >Fix: Actually the only "fix" I was able to think of was to forget typedef'ing the voidp, but this is a pain with the zlib.h since it has "voidp" everywhere. Another solution, but very ugly, is to #define voidp void * for example. >Release-Note: >Audit-Trail: >Unformatted:
next reply other threads:[~2002-08-09 20:46 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-08-09 14:06 Nicolas Noble [this message] 2002-08-09 14:16 Geoff Keating 2002-08-09 14:16 Graham Stott 2002-08-09 14:51 Nicolas Noble
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=20020809203729.2297.qmail@the-babel-tower.nobis-crew.org \ --to=nicolas@nobis-crew.org \ --cc=gcc-gnats@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).