[Bug c/93887] New: -Q --help=warning,c does not list -Wreturn-local-addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93887 Bug ID: 93887 Summary: -Q --help=warning,c does not list -Wreturn-local-addr Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tim.ruehsen at gmx dot de Target Milestone: ---
[Bug c/93886] New: -Q --help=warning,c does not list -Warray-bounds (gcc 10)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93886 Bug ID: 93886 Summary: -Q --help=warning,c does not list -Warray-bounds (gcc 10) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tim.ruehsen at gmx dot de Target Milestone: ---
[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92797 --- Comment #5 from Tim Ruehsen --- (In reply to ibuclaw from comment #4) > At what point does the D demangler kick in? It should only attempt to parse > symbols that begin with '_D'. There is a reproducer attached. See my initial comment on how to use it.
[Bug other/92456] libiberty/make-relative-prefix.c: read buffer overflow in split_directories()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92456 --- Comment #2 from Tim Ruehsen --- (In reply to Martin Liška from comment #1) > @Tim: Can you please send the patch to GCC patches mailing list? It's long ago, but finally found it: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02593.html
[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92797 --- Comment #3 from Tim Ruehsen --- (In reply to Andrew Pinski from comment #2) > (In reply to Tim Ruehsen from comment #1) > > BTW, llvm-cxxfilt does not show this behavior. > > Could it because it does not implement the D demangler? Good point, that seems to be the reason. So please ignore my previous comment.
[Bug demangler/92453] write buffer overflow in cplus_demangle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92453 --- Comment #3 from Tim Ruehsen --- (In reply to Christian Biesinger from comment #2) > Could you send your patch to gcc-patches per > https://gcc.gnu.org/contribute.html#patches ? Thanks! I did that some days ago: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02682.html
[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92797 --- Comment #1 from Tim Ruehsen --- BTW, llvm-cxxfilt does not show this behavior.
[Bug demangler/92797] New: cplus_demangle() produces huge amount of output (on trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92797 Bug ID: 92797 Summary: cplus_demangle() produces huge amount of output (on trunk) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: tim.ruehsen at gmx dot de Target Milestone: --- Created attachment 47418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47418=edit 700mb output reproducer c++file `cat slow-unit-150de9e10e6b2b6e62a6bac5b4c1fc87602ef3c6` (the attached reproducer file) creates output of >700Mb.
[Bug demangler/92795] New: Another slowness issue in the demangler (on trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92795 Bug ID: 92795 Summary: Another slowness issue in the demangler (on trunk) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: tim.ruehsen at gmx dot de Target Milestone: --- c++filt '_ZZ1_DO1z1psp1VEz1VE2On' takes ~1200s to finish. Relevant part of the callback #6 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #7 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #8 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #9 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #10 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #11 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #12 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #13 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #14 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #15 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #16 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #17 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #18 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #19 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #20 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #21 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #22 0x514263 in d_find_pack /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11 #23 0x50d514 in d_print_comp_inner /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5685:33 #24 0x503a44 in d_print_comp /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3 #25 0x514138 in d_print_subexpr /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4540:3 #26 0x51150c in d_print_comp_inner /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5514:4 #27 0x503a44 in d_print_comp /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3 #28 0x512ce5 in d_print_mod /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c #29 0x50f6d4 in d_print_comp_inner /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5155:4 #30 0x503a44 in d_print_comp /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3 #31 0x50edc2 in d_print_comp_inner /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5331:2 #32 0x503a44 in d_print_comp /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3 #33 0x51384c in d_print_function_type /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6084:5 #34 0x510d8d in d_print_comp_inner /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5216:4 #35 0x503a44 in d_print_comp /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3 #36 0x510628 in d_print_comp_inner /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4813:2 #37 0x503a44 in d_print_comp /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3 #38 0x50dda3 in d_print_comp_inner /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4708:7 #39 0x503a44 in d_print_comp /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3 #40 0x50335e in cplus_demangle_print_callback /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4352:5 #41 0x504a5e in d_demangle_callback /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6345:16 #42 0x504325 in d_demangle /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6367:12 #43 0x504209 in cplus_demangle_v3 /home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6524:10 #44 0x4fbc44 in cplus_demangle /home/tim/src/binutils-gdb/libiberty/./cplus-dem.c:166:13
[Bug demangler/92453] write buffer overflow in cplus_demangle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92453 --- Comment #1 from Tim Ruehsen --- Created attachment 47279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47279=edit Fix write buffer overflow in cplus_demangle() Correctly calculate the demangled size by using two passes.
[Bug other/92456] New: libiberty/make-relative-prefix.c: read buffer overflow in split_directories()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92456 Bug ID: 92456 Summary: libiberty/make-relative-prefix.c: read buffer overflow in split_directories() Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: tim.ruehsen at gmx dot de Target Milestone: --- Created attachment 47209 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47209=edit Patch proposal to fix the issue In L189 if (dirs[num_dirs - 1] == NULL) 'num_dirs' can be 0 if name is an empty string. Same in L129. The attached patch fixes both.
[Bug demangler/92453] New: write buffer overflow in cplus_demangle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92453
Bug ID: 92453
Summary: write buffer overflow in cplus_demangle()
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
The following code, compiled in libiberty/ causes a write buffer overflow in
cplus_demangle().
### repro1.c ###
#include "../include/demangle.h"
void main(void)
{
cplus_demangle("a_dSO__dSO__d_d", DMGL_GNAT);
}
###
gcc repro1.c -o repro1 libiberty.a
valgrind ./repro1
==4906== Invalid write of size 1
==4906==at 0x10B763: ada_demangle (cplus-dem.c:477)
==4906==by 0x10B8CE: cplus_demangle (cplus-dem.c:195)
==4906==by 0x10B219: main (in /home/tim/src/binutils-gdb/libiberty/repro1)
==4906== Address 0x4a4e057 is 0 bytes after a block of size 23 alloc'd
==4906==at 0x483577F: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4906==by 0x1184F0: xmalloc (xmalloc.c:147)
==4906==by 0x10B372: ada_demangle (cplus-dem.c:252)
==4906==by 0x10B8CE: cplus_demangle (cplus-dem.c:195)
==4906==by 0x10B219: main (in /home/tim/src/binutils-gdb/libiberty/repro1)
[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 --- Comment #8 from Tim Ruehsen --- Here is a good blog post about pointer overflow: https://blog.regehr.org/archives/1395
[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 --- Comment #7 from Tim Ruehsen --- Thanks for the explanations :-)
[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 --- Comment #2 from Tim Ruehsen --- Is ssize_t C99 ? Could you point to the specs so that any reader can verify that ? And by UB you mean, gcc sometimes gives 0 and sometimes 1 ? Even if it's UB, the behavior should be consistent. Since this is a real world issue - how can I reliably detect if 'p + n' would overflow or not if the checks sometimes work and sometimes not.
[Bug c/91946] New: wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946
Bug ID: 91946
Summary: wrong result comparing pointer with pointer+offset
with -m32
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
The following code compiled with -m32 (alternatively when on a 32bit system)
shows wrong output with gcc 8.3.0 and gcc 9.2.1. gcc 7.4.0 is not affected.
This leads to a possible RCE (remote code execution) in at least one real world
executable.
#include
void main(void) {
char *a=0xf3e0080c;
size_t n=235429897;
char *b = a + n;
printf("%p %p %d %d\n", a, a + n, a > a + n, a > b);
}
output with gcc 8.3.0 and 9.2.1:
0xf3e0080c 0x1e86815 0 1
output with gcc 7.4.0:
0xf3e0080c 0x1e86815 1 1
output with clang 8.0.1:
0xf3e0080c 0x1e86815 1 1
expected output:
0xf3e0080c 0x1e86815 1 1
[Bug c/90690] New: Undocumented -Werror-implicit-function-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90690 Bug ID: 90690 Summary: Undocumented -Werror-implicit-function-declaration Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tim.ruehsen at gmx dot de Target Milestone: --- The command line option '-Werror-implicit-function-declaration' is listed by `gcc -Q --help=warning[,C]` and also accepted by gcc 4.6 up to 9.1. But `man gcc` doesn't mention this command line option. If this has been obsoleted by `-Werror=implicit-function-declaration`, please do not list it with '-Q --help=warning'. We use this to automatically enable *all* warnings (something like clang's -Weverything). Thank you !
[Bug c/84883] No warning when dereferencing an array as a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84883 --- Comment #2 from Tim Ruehsen --- (In reply to Martin Sebor from comment #1) > (b) could be implemented in the C/C++ front ends which do have access > to the algorithm but not to data flow analysis, so the warning there would > be quite simplistic (basically limited to type and name matching) and could > be prone to false positives. If someone makes up a patch and give it to me, I can take the time to test with a decent amount of projects. So that we can get figures about how often the bug triggers and how many false positives there are. Without this, you are guessing. And I meanwhile had two occurrences where such an option would have saved several hours of work.
[Bug c/84883] New: No warning when dereferencing an array as a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84883 Bug ID: 84883 Summary: No warning when dereferencing an array as a pointer Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tim.ruehsen at gmx dot de Target Milestone: --- Created attachment 43669 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43669=edit Small test code It would be nice to a warning (option) if accidentally dereferencing an array instead of a pointer. struct BCHAN bchan[5], *bchanp = bchan + 3; bchanp->x = 1; // that's how it's supposed to be bchan->x = 1; // arg, typo. but now bchan[0].x has been written I experienced this in a pretty large codebase. This was causing *very* rare weird behavior and it's detection was more of a lucky punch. It is certainly valid C, but what a about an -Warray-deref ?
[Bug sanitizer/81598] -fsanitize=enum does not detect range violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81598
--- Comment #2 from Tim Ruehsen ---
(In reply to Jakub Jelinek from comment #1)
> This isn't a load, it is a cast, we sanitize just loads from memory.
Hmmm, seems ok if the compiler doesn't warn.
But the sanitizer IMO should trigger.
What if this cast has been done in a function returning flag_t ?
This could even be buggy code in an external library.
Then the sanitizer should definitely trigger.
And it doesn't with this code:
#include
typedef enum {
FLAG1 = (1 << 0),
FLAG2 = (1 << 1),
} flag_t;
static flag_t setter(int x)
{
return (flag_t) x;
}
int main(void)
{
int x = 5;
flag_t flags = setter(x);
printf("flags = %X\n", flags);
return 0;
}
$ g++-7 -O0 -fsanitize=undefined -fsanitize=enum -fno-sanitize-recover
enum_undef.cc
$ ./a.out
flags = 5
Hopefully, -O0 doesn't optimize into a single cast.
[Bug sanitizer/81598] New: -fsanitize=enum does not detect range violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81598
Bug ID: 81598
Summary: -fsanitize=enum does not detect range violation
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
g++'s (nor gcc's) -fsanitize=enum doesn't detect enum range violation.
The documentation says that it does.
Having this little C/C++ code (enum_undef.cc):
#include
typedef enum {
FLAG1 = (1 << 0),
FLAG2 = (1 << 1),
} flag_t;
int main(void)
{
int x = 5;
flag_t flags = (flag_t) x;
printf("flags = %X\n", flags);
return 0;
}
$ g++-7 -fsanitize=undefined -fsanitize=enum enum_undef.cc
$ $ ./a.out
flags = 5
In comparison, clang detects this kind of violation:
$ clang++-5.0 -fsanitize=undefined -fsanitize=enum enum_undef.cc
$ ./a.out
enum_undef.cc:13:25: runtime error: load of value 5, which is not a valid value
for type 'flag_t'
flags = 5
Adding -fno-sanitize-recover doesn't make a difference for gcc/g++.
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #51 from Tim Ruehsen --- (In reply to Martin Sebor from comment #50) > Yes, -Wnull-dereference is only in GCC 6 and later. -Wnonnull is in 5 and > prior but it does only a superficial job of checking (it only detects null > pointer constants). in GCC 7, -Wnonnull does a better job (but it's still > far from perfect). This option is not for C ? gcc 6.3.0 with options '-Q --help=warnings,C' doesn't print it out. But '-Q --help=warnings' does. Correct or missing (and if missing what else is missing with C !?).
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #42 from Tim Ruehsen tim.ruehsen at gmx dot de --- (In reply to Jeffrey A. Law from comment #41) Actually I think we want the concept of never returns NULL, both as an attribute and as a property the compiler can discover by analysis. Given that property on the return value, it can be propagated into call sites. ++ That sounds like very useful feature.
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #28 from Tim Ruehsen tim.ruehsen at gmx dot de --- I far as I can read, not a patch is missing. A review + commit is missing. How can you ask for more developers (=patches) when the work is ignored ? Don't get me wrong, I just try to understand how this should work.
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 Tim Ruehsen tim.ruehsen at gmx dot de changed: What|Removed |Added CC||tim.ruehsen at gmx dot de --- Comment #23 from Tim Ruehsen tim.ruehsen at gmx dot de --- *PLEASE* put this on higher priority. In 25 years of C development I saw thousands of crashes due to NULL pointer dereferences. Many of them could have been avoided by simply printing a warning. You really save lifes ! And millions of working hours searching for obvious bugs. The requested warning is an absolutely must-have (enabled by default). Seeing this bug open since 2004 is... well ... I have no words. (Don't get me wrong: I make a deep kneefall for gcc and it's developers)
[Bug c/53871] Please warn about endless loops if they are obvious
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871 --- Comment #4 from Tim Ruehsen tim.ruehsen at gmx dot de 2012-07-10 07:58:26 UTC --- (In reply to comment #3) I have thought a lot how to attract more and new developers to GCC who will be willing to develop things that are not a priority for current developers, but I don't have any solution to offer. There is not one solution, but a mixture of approaches may attract some developers. What about these Summer of Code things, why not writing articles for developer magazins. There is a need for good and easy tutorials about GIMPLE and gcc plugins. After your last post, I read about gcc plugins - very interesting indeed. A quick search revealed some articles/tutorials, but non of them gave me an instant kick to rush into. As far as I could see, you have to be an GIMPLE expert, before you start reading one of these articles. That might discourage some potential plugin developers. However, in terms of human resources, there is simply no one interested in working on this, ... I am a senior developer, and I use gcc every day. But I wasn't aware of gcc's plugin feature. Just spread the word and you might get some interested people.
[Bug c/53871] Please warn about endless loops if they are obvious
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871 --- Comment #2 from Tim Ruehsen tim.ruehsen at gmx dot de 2012-07-09 11:50:19 UTC --- (In reply to comment #1) (In reply to comment #0) Obvious endless loops could be reported, e.g. if the loop condition doesn't change and the loop can't be left otherwise. There has been discussions about this since more than ten years ago and nothing has happened: http://gcc.gnu.org/ml/gcc/1999-08n/msg00720.html More than 12 years of discussions... sigh. My understanding is that the probability of an existing GCC dev implementing this is very close to zero for various reasons: People are busy with other things, not trivial to implement for non-trivial code, risk of being too noisy, and there are other tools better at this job like splint and Clang's static analyzer. Neither splint nor clang understands gcc/ibm/intel nested functions, which I use a lot (yes, I know of the stack execution issue). Clang community so far refused to implement it, they propably never will. At least they have 'blocks' which might be a good alternative to nested functions. Splint isn't developed since 2007. Many years ago, I put nested functions on splint's wishlist - same answer as yours: go and implement it yourself !. (If I had time to to that, I wouldn't have put it on the wishlist but created a patch.) Maybe it's time for a gcc static analyzer...
[Bug c/53871] New: Please warn about endless loops if they are obvious
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871
Bug #: 53871
Summary: Please warn about endless loops if they are obvious
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tim.rueh...@gmx.de
Obvious endless loops could be reported, e.g. if the loop condition doesn't
change and the loop can't be left otherwise.
Example:
// x is declared non-volatile
while (x!=0);
while (x!=0) {
a++;
}
An optional -Wendless-loop could detect such issues with all kind of loops.
splint 3.1.2 says about the above axamples:
Suspected infinite loop. No value used in loop test (a) is modified by test or
loop body.
This appears to be an infinite loop. Nothing in the body of the loop or the
loop test modifies the value of the loop test. Perhaps the specification of a
function called in the loop body is missing a modification. (Use -infloops to
inhibit warning)
[Bug c/49748] char * const * cannot be assigned to char const * const *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49748
Tim Ruehsen tim.ruehsen at gmx dot de changed:
What|Removed |Added
CC||tim.ruehsen at gmx dot de
--- Comment #3 from Tim Ruehsen tim.ruehsen at gmx dot de 2012-02-23 14:12:00
UTC ---
Just to clarify it and to add a complete program.
x.c
void f(const char *const *args) {}
int main(int argc, char **argv) {
f(argv);
return 0;
}
Compiling with g++ (4.6.2) will do without warning.
Compiling with gcc (4.6.2) gives:
x.c: In function 'main':
x.c:4:2: warning: passing argument 1 of 'f' from incompatible pointer type
[enabled by default]
x.c:1:6: note: expected 'const char * const*' but argument is of type 'char **'
This is somewhat annoying when trying to harden older C sources with
-Wwrite-strings.
One has to insert (very) many casts to avoid the above warning.
This is much work that could be avoided by an apropriate -W option.
