On Mon, 11 May 1998, David Spencer wrote:
> > Yes, the code was buggy of course, it's a small wonder that the
> > non-optimized binary didn't coredump as well, because I was writing
> > beyond the end of a string... Thanks for the explanation anyway! I've
> > never programmed any assembler, so I
Linus Åkerlund wrote:
>
> Yes, the code was buggy of course, it's a small wonder that the
> non-optimized binary didn't coredump as well, because I was writing
> beyond the end of a string... Thanks for the explanation anyway! I've
> never programmed any assembler, so I really have no idea what
>
> "l" == Linus Åkerlund <[EMAIL PROTECTED]> writes:
[]
l> loading a text file into it, storing it in a linked list. The problem
l> is that when I compile it with -O or -O2, it coredumps, and when I
l> compile it without optimization, it works fine. I'm sure I've done
l> something w
On Sat, 9 May 1998, William T Wilson wrote:
> The short answer, then, is yes, optimization can affect your code if your
> code is buggy to begin with. :) Try using the -Wall option to gcc and
> see if it turns up any obvious errors.
Yes, the code was buggy of course, it's a small wonder that t
On Sat, 9 May 1998, [iso-8859-1] Linus Åkerlund wrote:
> something wrong, probably something with malloc(), but how come it
> works when I compile it without optimization? There really shouldn't
> be a difference in whether the program works or not, right?
No; optimization changes your code, aft
Hello!
Yet another one of those things that I absolutely can't understand
has happened to me again. I've written a little program in C,
a simple text editor, using ncurses, and the problems start when I'm
loading a text file into it, storing it in a linked list. The problem
is that when I compile
