Re: Segmentation fault
Yes, quite right. I was not being critical of gcc, but of my own coding
orientation. I've reached similar conclusions as you outline
There is a rather large body of material I desperately need to read and
absorb. That's exactly the problem I'm trying to contend with in trying to
convert my work to Linux/gcc/x/ppp... and why some gentle assists from the
list are so useful in helping me get started
David
----- Original Message -----
From: Colin Watson <cjw44@cam.ac.uk>
To: <debian-user@lists.debian.org>
Sent: Sunday, February 13, 2000 2:54 AM
Subject: Re: Segmentation fault
> davidturetsky@email.msn.com (davidturetsky) wrote:
> >I see from further investigation that gcc wants me to be more actively
> >concerned with memory management than was required under Visual C, and I
was
> >logging on to apologize for bothering the list. I posted because this
code
> >ran cleanly under Visual C, so I thought I ran into a Linux nuance
> >
> >It looks as though I was running into problems when trying to scan an
input
> >file using c notation which is less efficient of memory, so I'm in the
> >process of revising all of the I/O to use c++ resources.
>
> This surprises me; I'd have thought stdio was more memory-efficient than
> iostreams, if it's an issue at all (which I rather doubt). Regardless, a
> segmentation fault is an indication of a memory access bug in your
> program rather than running out of memory (it may not have happened in
> Visual C simply because you were lucky in the way Visual C allocated
> memory for you), so you may be trying to fix the wrong problem by doing
> all this rewriting. (Of course, you may be lucky and accidentally fix it
> in the process, or the problem may have been that you didn't know how to
> use stdio and are more successful in using iostreams, but I suppose it
> depends whether you actually want to know what you're doing ...)
>
> >In general, I am beginning to notice that gcc's posture is that you do
more
> >for yourself. It also seems to be strictly limited to ANSI c. For
example,
> >there doesn't seem to be any support for min, max, and itoa and I ended
up
> >writing/rewriting that portion of the code
>
> I think you desperately need to read 'info gcc' and 'info libc'. gcc is
> notoriously far from limited to ANSI C. :)
>
> Actually, your problem is not with gcc, it seems to be that the GNU C
> Library (libc/glibc) doesn't have what you want; it's far from limited
> to ANSI C either, but any C programmer worth his/her salt knows that if
> you use extensions in your code you should expect them not to be
> portable. glibc simply has different extensions to Visual C; in general
> I've found it a much more helpful and much better documented C library
> than the Microsoft one, but I may be biased.
>
> Besides, min(), max(), and itoa() are hardly difficult. How about:
>
> #define min(a,b) ((a) < (b) ? (a) : (b))
> #define max(a,b) ((a) > (b) ? (a) : (b))
>
> ... or equivalent function definitions if the double evaluation bothers
> you, and sprintf() instead of itoa()? If you program in ANSI C wherever
> possible to start with rather than lazily using extensions, you'll have
> a much easier time of it.
Reply to: