AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nigelenki at comcast dot net
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
--- Comment #1 from nigelenki at comcast dot net 2006-10-25 20:41 ---
Created an attachment (id=12492)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12492action=view)
decrypt_1.2.c
C source file, there's a big block that says GCC MISCOMPILATION above the
printf triggering
--- Comment #4 from nigelenki at comcast dot net 2006-10-25 21:42 ---
Issue was passing an unsigned long int to a %i instead of %li format specifier
in printf(). I didn't know my C library altered anything if %n wasn't
specified... oh well, my bug.
--
http://gcc.gnu.org/bugzilla
--- Comment #14 from nigelenki at comcast dot net 2006-07-11 06:25 ---
(In reply to comment #13)
(In reply to comment #12)
(In reply to comment #10)
(In reply to comment #8)
...
You make the assumption that I somehow know the bug is in f(). What if I
have
a 64
--- Comment #16 from nigelenki at comcast dot net 2006-07-11 07:08 ---
(In reply to comment #15)
(In reply to comment #14)
...
Yes but now he has a limited number of code paths to go wrong on.
That is not true. he just knows the last function and nothing more, this is
where
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nigelenki at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
: nigelenki at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334
--- Comment #2 from nigelenki at comcast dot net 2006-07-11 02:43 ---
The program may be on an end user system that A) has insufficient debugging
data compiled in (though I'd imagine you know what function it's in anyway); or
B) has an end user that can't/won't debug (typical). It may
--- Comment #4 from nigelenki at comcast dot net 2006-07-11 03:09 ---
(In reply to comment #3)
If an end user gets a stack smash failure, they should report the bug to the
developer and have the developer fix it.
This is what is normally done for anyother bug, why should
--- Comment #2 from nigelenki at comcast dot net 2006-07-11 03:27 ---
And the developer is going to debug a program nice and slow when those obscure,
hard to trigger bugs come along.
I was just toying with metasploit the other day. Threw an exploit at Windows
to get me a remote VNC
--- Comment #5 from nigelenki at comcast dot net 2006-07-11 04:44 ---
(In reply to comment #4)
See bug #28328 comment #5 on why this should be closed as WONTFIX/INVALID or
the likes.
Eh close it WONTFIX because it's not gcc's job. Like I said, the stack smash
handler can
--- Comment #8 from nigelenki at comcast dot net 2006-07-11 04:56 ---
(In reply to comment #6)
(In reply to comment #4)
Thank you, I see the problem, there's a patch attached. Your distribution
should have a new version some time in a couple days.
Here is how normal GCC bugs
--- Comment #12 from nigelenki at comcast dot net 2006-07-11 05:49 ---
(In reply to comment #10)
(In reply to comment #8)
That is just a simple (obvious) example, you seem to not understand how real
code looks like. You might instead have:
int f(int a, int b)
{
int f[10
)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nigelenki at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28036
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nigelenki at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24292
--- Comment #1 from nigelenki at comcast dot net 2005-10-09 23:49 ---
Created an attachment (id=9949)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9949action=view)
the dot-i file thingy you guys wanted
the thingy that appeared in a completely different directory than related .c
16 matches
Mail list logo
