By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 1,260 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

Simple code leads to segfault.. help

P: n/a
Hi, can someone explain why the following simple C code segfaulted?
I've stared it for 30mins but couldn't find the problem. Thx in advance

#include <stdio.h>

int main() {

char *one;
char *two;

fgets(one, 200, stdin);
printf("one is %s", one);

fgets(two, 200, stdin);
printf("two is %s", two);

return 0;
}

Sep 16 '06 #1
Share this Question
Share on Google+
41 Replies


P: n/a
SkyBlue wrote:
Hi, can someone explain why the following simple C code segfaulted?
I've stared it for 30mins but couldn't find the problem. Thx in advance

#include <stdio.h>

int main() {

char *one;
char *two;

fgets(one, 200, stdin);
printf("one is %s", one);

fgets(two, 200, stdin);
printf("two is %s", two);

return 0;
}
If you thought that this would work then I'm afraid
you need to go back to your C textbook(s) and study
carefully before you attempt to write another programme
even a toy one.

You never initialize one and two so fgets attempts
to write on some random area of memory. Hence
segfault. What you need is for one and two to point
to some area of memory which has at least 200 bytes
available. How you do that is one of the many reasons
you need to return to your textbooks(s).
you need to go back to your textbooks.

Sep 16 '06 #2

P: n/a
SkyBlue wrote:
Hi, can someone explain why the following simple C code segfaulted?
I've stared it for 30mins but couldn't find the problem. Thx in advance

#include <stdio.h>

int main() {

char *one;
char *two;

fgets(one, 200, stdin);
printf("one is %s", one);

fgets(two, 200, stdin);
printf("two is %s", two);

return 0;
}
You left out too much needed code. Consider..

#include <stdio.h>
#include <stdlib.h>
#define LEN 200

int main(void)
{
char *one;
char *two;

if ((one = malloc(LEN)) == NULL)
puts("Memory Allocation Error."), exit(EXIT_FAILURE);

if ((two = malloc(LEN)) == NULL)
puts("Memory Allocation Error."), exit(EXIT_FAILURE);

fgets(one, LEN, stdin);
printf("one is %s", one);

fgets(two, LEN, stdin);
printf("two is %s", two);

return 0;
}

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Sep 16 '06 #3

P: n/a
SkyBlue posted:
char *one;
char *two;

Both of these variables are pointers. They are a non-const pointer to a
non-const char.

A pointer variable is just like any other variable -- it consumes memory
and stores data by arranging bits in a particular pattern.

The purpose of an int is to store an integer.
The purpose of a double is to store a floating-point number.
The purpose of a pointer is to store a memory address.

What is a memory address? 10? 5737? 2972529? I suppose we can presume it's
some sort of number, no?

On the particular system you're working with, a pointer variable might
consume 32 bits in memory; therefore, to store the memory address 2972529,
the pointer might store the following bit-pattern in memory:

00000000001011010101101101110001

Now, I'm going to shift the attention away from pointers for the moment,
and tell you a little about "automatic storage variables". When you define
a variable within a function, it's called an automatic storage variable
(unless of course you define it as "static" -- in which case it would be a
static duration variable.). If an automatic variable is not assigned a
value (as in your code snippet), then its value is indeterminant -- it
contains white noise, a bit-pattern left over from when that piece of
memory was last used. You have defined two automatic variables, but you
have not initialised them; therefore, they contain garbage, a random
number, a random memory address.

You then invoke "fgets" and provide it with these two random memory
addresses. In order to read or write memory, you must obliged to do so, you
must be permitted to do so. How do we gain permission to read and write a
certain block of memory... ? By allocating that memory for our own use, of
course. There's a function in the Standard Library called "malloc"; when
calling it, you specify how many bytes of memory you wish to allocate, and
the function returns the address of the newly allocated block of memory. So
let's store a valid address in our char pointers:

char *const one = malloc(512);
char *const two = malloc(512);

The values stored in "one" and "two" are not random -- they are the
addresses of dynamically allocated blocks of memory which are yours to
manipulate however you please.

Don't forget to then free the memory by passing the memory addresses to
"free":

free(one);
free(two);

I simplified a lot of the above (e.g. I haven't talked about trapping, or
the invocation of undefined behaviour by accessing an un-initialised
variable), but hopefully you get the idea.

--

Frederick Gotham
Sep 16 '06 #4

P: n/a
SkyBlue wrote:
Hi, can someone explain why the following simple C code segfaulted?
I've stared it for 30mins but couldn't find the problem. Thx in advance

#include <stdio.h>

int main() {

char *one;
char *two;

fgets(one, 200, stdin);
^^^
You have allocated no memory for one to point to. How should I spend
the other 29:59?
Sep 16 '06 #5

P: n/a
Frederick Gotham wrote:
SkyBlue posted:
> char *one;
char *two;


Both of these variables are pointers. They are a non-const pointer to a
non-const char.

A pointer variable is just like any other variable -- it consumes memory
and stores data by arranging bits in a particular pattern.

The purpose of an int is to store an integer.
The purpose of a double is to store a floating-point number.
The purpose of a pointer is to store a memory address.

What is a memory address? 10? 5737? 2972529? I suppose we can presume it's
some sort of number, no?

On the particular system you're working with, a pointer variable might
consume 32 bits in memory; therefore, to store the memory address 2972529,
the pointer might store the following bit-pattern in memory:

00000000001011010101101101110001

Now, I'm going to shift the attention away from pointers for the moment,
and tell you a little about "automatic storage variables". When you define
a variable within a function, it's called an automatic storage variable
(unless of course you define it as "static" -- in which case it would be a
static duration variable.). If an automatic variable is not assigned a
value (as in your code snippet), then its value is indeterminant -- it
contains white noise, a bit-pattern left over from when that piece of
memory was last used. You have defined two automatic variables, but you
have not initialised them; therefore, they contain garbage, a random
number, a random memory address.

You then invoke "fgets" and provide it with these two random memory
addresses. In order to read or write memory, you must obliged to do so, you
must be permitted to do so. How do we gain permission to read and write a
certain block of memory... ? By allocating that memory for our own use, of
course. There's a function in the Standard Library called "malloc"; when
calling it, you specify how many bytes of memory you wish to allocate, and
the function returns the address of the newly allocated block of memory. So
let's store a valid address in our char pointers:

char *const one = malloc(512);
char *const two = malloc(512);

The values stored in "one" and "two" are not random -- they are the
addresses of dynamically allocated blocks of memory which are yours to
manipulate however you please.
Shouldn't you test whether malloc was successful?
Don't forget to then free the memory by passing the memory addresses to
"free":

free(one);
free(two);

I simplified a lot of the above (e.g. I haven't talked about trapping, or
the invocation of undefined behaviour by accessing an un-initialised
variable), but hopefully you get the idea.
The point of free() is to allow the re-use of allocated memory within
the program. To free() allocated memory just prior to program
termination is harmless but useless. The OS will reclaim all allocated
memory when your program terminates.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Sep 16 '06 #6

P: n/a
Joe Wright wrote:
The point of free() is to allow the re-use of allocated memory within
the program. To free() allocated memory just prior to program
termination is harmless but useless. The OS will reclaim all allocated
memory when your program terminates.
You may believe this, but that doesn't make it so. Your OS may behave
this way, but that doesn't make it true elsewhere. Unless you can show
where the standard for C requires this, keep your non-portable,
system-specific opinions to yourself. Your flat claim is patently false.

Sep 16 '06 #7

P: n/a
Martin Ambuhl wrote:
Joe Wright wrote:
The point of free() is to allow the re-use of allocated memory within
the program. To free() allocated memory just prior to program
termination is harmless but useless. The OS will reclaim all allocated
memory when your program terminates.

You may believe this, but that doesn't make it so. Your OS may behave
this way, but that doesn't make it true elsewhere. Unless you can show
where the standard for C requires this, keep your non-portable,
system-specific opinions to yourself. Your flat claim is patently false.
How do you know that the claim is false ? Do you have
an example of an operating system which doesn't
reclaim allocated memory ?

Sep 16 '06 #8

P: n/a
Joe Wright said:

<snip>
The point of free() is to allow the re-use of allocated memory within
the program. To free() allocated memory just prior to program
termination is harmless but useless. The OS will reclaim all allocated
memory when your program terminates.
That kind of thinking costs money, when main() becomes foo(), and foo() is
called in a loop. Fortunately, money is conserved, and the maintenance
programmer's family gets buns for tea.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 16 '06 #9

P: n/a
Spiros Bousbouras posted:
How do you know that the claim is false ? Do you have
an example of an operating system which doesn't
reclaim allocated memory ?

That's a bad argument to put across. I've never seen a C implementation which
has 13-Bit char's, 17-Bit int's, and uses One's Complement -- but I'll shun
any portable code which doesn't make allowances for it.

I haven't got the C Standard, so I don't know what it says about requiring to
"free" all memory.

--

Frederick Gotham
Sep 16 '06 #10

P: n/a
Martin Ambuhl <ma*****@earthlink.netwrites:
Joe Wright wrote:
>The point of free() is to allow the re-use of allocated memory
within the program. To free() allocated memory just prior to program
termination is harmless but useless. The OS will reclaim all
allocated memory when your program terminates.

You may believe this, but that doesn't make it so. Your OS may behave
this way, but that doesn't make it true elsewhere. Unless you can
show where the standard for C requires this, keep your non-portable,
system-specific opinions to yourself. Your flat claim is patently
false.
Are you assuming that memory that has been free()d *will* be reclaimed
by the operating system? If so, what is your basis for that
assumption?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 16 '06 #11

P: n/a
Frederick Gotham <fg*******@SPAM.comwrites:
Spiros Bousbouras posted:
>How do you know that the claim is false ? Do you have
an example of an operating system which doesn't
reclaim allocated memory ?

That's a bad argument to put across. I've never seen a C
implementation which has 13-Bit char's, 17-Bit int's, and uses One's
Complement -- but I'll shun any portable code which doesn't make
allowances for it.
I agree with the general point, but if CHAR_BIT is 13, int must be at
least 26 bits (though it could have 9 padding bits).
I haven't got the C Standard, so I don't know what it says about
requiring to "free" all memory.
Why don't you have the C standard? Just grab a copy of n1124.pdf.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 16 '06 #12

P: n/a
Keith Thompson posted:
I agree with the general point, but if CHAR_BIT is 13, int must be at
least 26 bits (though it could have 9 padding bits).

Yes, 26 object representation bits consisting of 17 value representation bits
and 9 padding bits. ; )

Why don't you have the C standard? Just grab a copy of n1124.pdf.

I didn't realise it was free... I just downloaded it now!

--

Frederick Gotham
Sep 16 '06 #13

P: n/a
Frederick Gotham <fg*******@SPAM.comwrites:
Spiros Bousbouras posted:
>How do you know that the claim is false ? Do you have
an example of an operating system which doesn't
reclaim allocated memory ?

That's a bad argument to put across. I've never seen a C
implementation which has 13-Bit char's, 17-Bit int's, and uses One's
Complement -- but I'll shun any portable code which doesn't make
allowances for it.
Well, any code that doesn't make allowances for that kind of thing
isn't portable.

On the other hand, not all code has to be portable. If you have no
need to run your code on a platform with CHAR_BIT>8, *and* if there's
a real advantage in assuming that CHAR_BIT==8, then I see no great
problem in writing code that depends on that assumption. (For
example, I think POSIX guarantees CHAR_BIT==8, and a few other things;
if I'm using POSIX-specific library functions, there's not much point
in allowing for 9-bit chars.)

But I would advocate making any such assumptions explicit, so if
someone tries to compile the code on some exotic system that doesn't
satisfy the assumptions, the error is caught as early and as cleanly
as possible.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 16 '06 #14

P: n/a
Keith Thompson wrote:
Martin Ambuhl <ma*****@earthlink.netwrites:
>Joe Wright wrote:
>>The point of free() is to allow the re-use of allocated memory
within the program. To free() allocated memory just prior to program
termination is harmless but useless. The OS will reclaim all
allocated memory when your program terminates.
You may believe this, but that doesn't make it so. Your OS may behave
this way, but that doesn't make it true elsewhere. Unless you can
show where the standard for C requires this, keep your non-portable,
system-specific opinions to yourself. Your flat claim is patently
false.

Are you assuming that memory that has been free()d *will* be reclaimed
by the operating system?
There is nothing in my post from which you can extrapolate such an
assumption.
If so, what is your basis for that
assumption?
What is your basis for trying to force assumptions onto me and then
pretending I have some obligation to justify your claimed assumption.

Please try a little honesty.
Sep 16 '06 #15

P: n/a
Frederick Gotham wrote:
Spiros Bousbouras posted:
How do you know that the claim is false ? Do you have
an example of an operating system which doesn't
reclaim allocated memory ?


That's a bad argument to put across. I've never seen a C implementation which
has 13-Bit char's, 17-Bit int's, and uses One's Complement -- but I'll shun
any portable code which doesn't make allowances for it.
But I wasn't putting any argument across nor did I
need to because it wasn't me who was advocating an
opinion. It was Martin Ambuhl who wrote that the
claim (that every operating system will reclaim allocated
memory after the programme finishes) was false so he
needs to come up with the arguments or supporting
evidence.

Having said that I do consider it improbable that such an
operating system exists simply on the basis that it would
be so bad that noone would use it plus it would probably be
easy to fix things so that it did reclaim allocated memory
after the programme finished.

" but I'll shun any portable code which doesn't make allowances for
it."

Does your code make provisions for every occurence allowed
by the standard no matter how improbable ? Do you for
example check the return value of printf in your code ? I doubt
it. Do you consider more probable that some operating system
won't reclaim memory than that printf will return a negative
value ? I don't.

Sep 16 '06 #16

P: n/a
Martin Ambuhl <ma*****@earthlink.netwrites:
Keith Thompson wrote:
>Martin Ambuhl <ma*****@earthlink.netwrites:
>>Joe Wright wrote:
The point of free() is to allow the re-use of allocated memory
within the program. To free() allocated memory just prior to program
termination is harmless but useless. The OS will reclaim all
allocated memory when your program terminates.
You may believe this, but that doesn't make it so. Your OS may behave
this way, but that doesn't make it true elsewhere. Unless you can
show where the standard for C requires this, keep your non-portable,
system-specific opinions to yourself. Your flat claim is patently
false.
Are you assuming that memory that has been free()d *will* be
reclaimed
by the operating system?

There is nothing in my post from which you can extrapolate such an
assumption.
I didn't say there was. That's why I asked the question.
>If so, what is your basis for that
assumption?

What is your basis for trying to force assumptions onto me and then
pretending I have some obligation to justify your claimed assumption.
I have not done so.
Please try a little honesty.
Please try a little reading comprehension. I asked a question.
Rather than answering it, you chose to make assumptions about what was
behind it.

If you're not assuming that memory that has been free()d will be
reclaimed by the OS, then the answer to my first question would be a
simple no, and the second question, as I expicitly acknowledged, would
not be applicable.

Was your suggestion that I "try a little honesty" meant to imply that
I've been dishonest? If so, please explain. (And please read this
paragraph more carefully than you seem to have read my previous
questions.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 16 '06 #17

P: n/a
Keith Thompson wrote:
Please try a little reading comprehension. I asked a question.
Rather than answering it, you chose to make assumptions about what was
behind it.
You asked a question that imputed to me an assumption. It was an
assumption I never made, about an issue which I never speculated on.
You made the assumption out of your own imagination: you answer it. You
have repeatedly pulled this puerile parlor trick of imputing to people
assumptions they never made and then demanding answers, hiding behind
the obvious facade of "I just asked a question." This may impress the
other kiddies at your day care center, but honest adults don't do this.
Go back to your sandbox.
Sep 16 '06 #18

P: n/a
Martin Ambuhl <ma*****@earthlink.netwrites:
Keith Thompson wrote:
>Please try a little reading comprehension. I asked a question.
Rather than answering it, you chose to make assumptions about what was
behind it.

You asked a question that imputed to me an assumption. It was an
assumption I never made, about an issue which I never speculated
on. You made the assumption out of your own imagination: you answer
it. You have repeatedly pulled this puerile parlor trick of imputing
to people assumptions they never made and then demanding answers,
hiding behind the obvious facade of "I just asked a question." This
may impress the other kiddies at your day care center, but honest
adults don't do this. Go back to your sandbox.
Bye.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 16 '06 #19

P: n/a
Keith Thompson said:
Martin Ambuhl <ma*****@earthlink.netwrites:
>Joe Wright wrote:
>>The point of free() is to allow the re-use of allocated memory
within the program. To free() allocated memory just prior to program
termination is harmless but useless. The OS will reclaim all
allocated memory when your program terminates.

You may believe this, but that doesn't make it so. Your OS may behave
this way, but that doesn't make it true elsewhere. Unless you can
show where the standard for C requires this, keep your non-portable,
system-specific opinions to yourself. Your flat claim is patently
false.

Are you assuming that memory that has been free()d *will* be reclaimed
by the operating system?
I don't see how you can reasonably infer that Martin is assuming any such
thing. If anything, he is asserting the opposite - i.e. that there is no
reason to assume it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 16 '06 #20

P: n/a
Martin Ambuhl said:
Keith Thompson wrote:
>Please try a little reading comprehension. I asked a question.
Rather than answering it, you chose to make assumptions about what was
behind it.

You asked a question that imputed to me an assumption. It was an
assumption I never made, about an issue which I never speculated on.
True enough, but...
You made the assumption out of your own imagination: you answer it. You
have repeatedly pulled this puerile parlor trick of imputing to people
assumptions they never made and then demanding answers, hiding behind
the obvious facade of "I just asked a question." This may impress the
other kiddies at your day care center, but honest adults don't do this.
Go back to your sandbox.
....I think this is an over-reaction.

Over-reactions do, of course, make for lively and sometimes entertaining
reading, but nevertheless they rarely reflect credit on their authors.

I suggest you guys both get yourselves down to the fridge and see if there's
any beer left. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 16 '06 #21

P: n/a
Richard Heathfield wrote:
Joe Wright said:

<snip>
>The point of free() is to allow the re-use of allocated memory within
the program. To free() allocated memory just prior to program
termination is harmless but useless. The OS will reclaim all allocated
memory when your program terminates.

That kind of thinking costs money, when main() becomes foo(), and foo() is
called in a loop. Fortunately, money is conserved, and the maintenance
programmer's family gets buns for tea.
I'm trying to read the paragraph above. How should main() become foo()?
I'm probably as anal as anyone about pairing malloc() and free() calls
within my programs. It's simply good practice.

That malloc() stuff can call sbrk() stuff to have the OS allocate memory
to our process, our free() stuff probably doesn't cause the OS to
reclaim any memory. On termination of our process, the OS will reclaim
all memory allocated to it.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Sep 16 '06 #22

P: n/a
Keith Thompson wrote:
Please try a little reading comprehension. I asked a question.
Rather than answering it, you chose to make assumptions about what was
behind it.
Idiot! I answered your question. To repeat your question:
Are you assuming that memory that has been free()d *will* be reclaimed
by the operating system? If so, what is your basis for that
assumption?
You are obviously too stupid to understand, so I will make it as clear
as possible: I do not make that assumption. Got it?

You made up the assumption, asked me (as if it were somehow related to
anything I wrote, which it is not) if I held it. I was clear that the
source of that assumption was you, not me. I never wrote anything on
which your baby pseudo-cross examination could be based. Go away.
Sep 16 '06 #23

P: n/a
Richard Heathfield wrote:
...I think this is an over-reaction.

Over-reactions do, of course, make for lively and sometimes entertaining
reading, but nevertheless they rarely reflect credit on their authors.
But I answered his question: whether I assumed <Keith Thompson
fabrication>. He then claimed I had not answered it. This can only be
true if I _did_ make his assumption and then had refused to answer his
second question. But that second question assumes an answer to the
first question. His first question was dishonest: his claim that I did
not answer was even more dishonest.
Sep 16 '06 #24

P: n/a
Joe Wright said:
Richard Heathfield wrote:
>Joe Wright said:

<snip>
>>The point of free() is to allow the re-use of allocated memory within
the program. To free() allocated memory just prior to program
termination is harmless but useless. The OS will reclaim all allocated
memory when your program terminates.

That kind of thinking costs money, when main() becomes foo(), and foo()
is called in a loop. Fortunately, money is conserved, and the maintenance
programmer's family gets buns for tea.

I'm trying to read the paragraph above. How should main() become foo()?
You write what you think is an application. It has a main() and everything.
It's huge. Easily a quarter of a million lines. It goes into production. A
few years later, someone spots that it isn't /really/ an application - it's
just a library routine! And so they s/main/foo/ (or some more fitting name,
obviously), and call the thing over and over again, in a loop. Suddenly,
memory is dripping out of the side-panels and forming puddles under the
raised floor.

When I was at MumbleCo, I was working on just such a program. Unfortunately,
at the time I didn't have the clout to make the project lead realise the
importance of good housekeeping. Along with quite a few others, I worked on
that program for over a year, and then it finally went in, and I wandered
off to greener pa$ture$, as they say.

Some years later, I found myself working for CoughCo, who had paid MumbleCo
a significant sum of money for the program (I don't know whether it was a
transfer of ownership or a mere licensing deal, and it doesn't really
matter for the purpose of this account). It was no coincidence that CoughCo
hired me, of course. They were after my experience of the program.

Anyway, CoughCo decided that this wasn't a program really. It was just a
subroutine. Admittedly, at 250KLOC or so, it was a rather *big* subroutine,
but a subroutine nonetheless. And so they gave main a new name, and called
it from their own main. In a loop. And that's when the memory usage hit the
ceiling.

Good housekeeping isn't just pedantry in practice. It's part of defensive
programming.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 16 '06 #25

P: n/a
Richard Heathfield <in*****@invalid.invalidwrites:
Martin Ambuhl said:
>Keith Thompson wrote:
>>Please try a little reading comprehension. I asked a question.
Rather than answering it, you chose to make assumptions about what was
behind it.

You asked a question that imputed to me an assumption. It was an
assumption I never made, about an issue which I never speculated on.

True enough, but...
No, not really.

If neither Martin and Richard understood what I was trying to say, I
probably didn't write clearly enough. I honestly thought that my
meaning was clear.

I'll post again later and try to explain what I actually meant.

Martin: this was a simple misunderstanding, entirely unintentional on
my part. I have not deliberately forced any assumption on you.

Your accusation that I have been dishonest is stupid and offensive.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 17 '06 #26

P: n/a
In article <4n************@individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:
>You asked a question that imputed to me an assumption. It was an
assumption I never made, about an issue which I never speculated on.
Your post - in response to an assertion that it was unnecessary to
free memory before exiting, because the OS will do it - could quite
naturally be taken as implying that you *should* free memory, because
the OS won't necessarily do it. That would only make sense if the OS
reclaimed memory that you freed, which is equally susceptible to your
rather rude comment:
Unless you can
show where the standard for C requires this, keep your non-portable,
system-specific opinions to yourself.
Now perhaps you didn't mean to imply that you should free memory, but
I don't think you can blame people for inferring that.

-- Richard
Sep 17 '06 #27

P: n/a
Richard Heathfield wrote:
Joe Wright said:

<snip>
>The point of free() is to allow the re-use of allocated memory
within the program. To free() allocated memory just prior to
program termination is harmless but useless. The OS will reclaim
all allocated memory when your program terminates.

That kind of thinking costs money, when main() becomes foo(), and
foo() is called in a loop. Fortunately, money is conserved, and
the maintenance programmer's family gets buns for tea.
However there exist systems in which free is O(n), where n is the
count of allocations made. This makes freeing everything on exit
O(n*n), and can be a real drag.

This was the motivation for my writing nmalloc for DJGPP, see:

<http://cbfalconer.home.att.net/download/>

The problem arose when validating my hashlib package. Closing the
database requires freeing all the associated storage. The O(n*n)
effect showed up dramatically when there were a few hundred
thousand items involved, and manifested itself as a heavy delay on
program exit. I didn't check every system in existance, but found
that the problem existed on DJGPP, LCC-WIN32, and VC. The problem
arises in combining freed areas.

nmalloc makes free O(1), and thus the complete free becomes O(n).
No matter how fast the underlying system is, O(n*n) response will
catch you sooner or later.

The point of all this is that avoiding the final free action in a
program can avoid those delays. The test suite for hashlib enables
either action.

A further point is that this demonstrates the efficacy of open
source. I could fix DJGPP. I couldn't fix the others.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

--
Posted via a free Usenet account from http://www.teranews.com

Sep 17 '06 #28

P: n/a
"Spiros Bousbouras" <sp****@gmail.comwrites:
Does your code make provisions for every occurence allowed
by the standard no matter how improbable ? Do you for
example check the return value of printf in your code ? I doubt
it. Do you consider more probable that some operating system
won't reclaim memory than that printf will return a negative
value ? I don't.
If my code depended on printf() succeeding, I would indeed check
the return value. However, most printf() statements provide no
real value to the program: they just output information on how
the program runs, nothing more.

Considering that my system depends on having some of its memory
free (after all, it's finite!) I would free() memory before the
program terminates. Your mentality may differ.

--
Andrew Poelstra <http://www.wpsoftware.net/projects>
To reach me by email, use `apoelstra' at the above domain.
"Do BOTH ends of the cable need to be plugged in?" -Anon.
Sep 17 '06 #29

P: n/a
Keith Thompson <ks***@mib.orgwrites:
Are you assuming that memory that has been free()d *will* be reclaimed
by the operating system? If so, what is your basis for that
assumption?
Since there's some confusion on this point:

To me it appears that this is just a question. It doesn't appear to be
making any assumptions about what the answer might be. It certainly
doesn't appear offensive in any way.

--
Andrew Poelstra <http://www.wpsoftware.net/projects>
To reach me by email, use `apoelstra' at the above domain.
"Do BOTH ends of the cable need to be plugged in?" -Anon.
Sep 17 '06 #30

P: n/a
Keith Thompson posted:
But I would advocate making any such assumptions explicit, so if
someone tries to compile the code on some exotic system that doesn't
satisfy the assumptions, the error is caught as early and as cleanly
as possible.
#if CHAR_BIT 8
#error ......................
#endif

--

Frederick Gotham
Sep 17 '06 #31

P: n/a
Spiros Bousbouras posted:
Does your code make provisions for every occurence allowed
by the standard no matter how improbable ?

Yes.

Improbability is irrelevant.

If I say that a certain snippet is portable, I mean that that snippet is
portable according to the C89 Standard (on this newsgroup).

--

Frederick Gotham
Sep 17 '06 #32

P: n/a
Andrew Poelstra said:
Keith Thompson <ks***@mib.orgwrites:
>Are you assuming that memory that has been free()d *will* be reclaimed
by the operating system? If so, what is your basis for that
assumption?

Since there's some confusion on this point:

To me it appears that this is just a question. It doesn't appear to be
making any assumptions about what the answer might be. It certainly
doesn't appear offensive in any way.
No, it doesn't appear offensive to me, either. But you'd be surprised at how
easily people can take offence. Any of us. For example, you'd probably be
offended if I called you a... well, let's not go there. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 17 '06 #33

P: n/a
CBFalconer said:
Richard Heathfield wrote:
>Joe Wright said:

<snip>
>>The point of free() is to allow the re-use of allocated memory
within the program. To free() allocated memory just prior to
program termination is harmless but useless. The OS will reclaim
all allocated memory when your program terminates.

That kind of thinking costs money, when main() becomes foo(), and
foo() is called in a loop. Fortunately, money is conserved, and
the maintenance programmer's family gets buns for tea.

However there exist systems in which free is O(n), where n is the
count of allocations made. This makes freeing everything on exit
O(n*n), and can be a real drag.
Having your application catch amnesia can be a real drag, too. If better
ways of doing the Right Thing can be found, that's fabulous, but the
absence of those better ways does not mean we should do the Wrong Thing
instead.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 17 '06 #34

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>Martin Ambuhl <ma*****@earthlink.netwrites:
....
>You may believe this, but that doesn't make it so. Your OS may behave
this way, but that doesn't make it true elsewhere. Unless you can
show where the standard for C requires this, keep your non-portable,
system-specific opinions to yourself. Your flat claim is patently
false.

Are you assuming that memory that has been free()d *will* be reclaimed
by the operating system? If so, what is your basis for that
assumption?
It makes you realize just how sad Martin Ambuhl's life must be (when you
read his hateful, hysterical posts)

Sep 17 '06 #35

P: n/a
In article <4n************@individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:
(Good ole Keith wrote)
>Are you assuming that memory that has been free()d *will* be reclaimed
by the operating system?

There is nothing in my post from which you can extrapolate such an
assumption.
>If so, what is your basis for that
assumption?

What is your basis for trying to force assumptions onto me and then
pretending I have some obligation to justify your claimed assumption.

Please try a little honesty.
Chick fight!!!

Sep 17 '06 #36

P: n/a
In article <4n************@individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:
>Keith Thompson wrote:
>Please try a little reading comprehension. I asked a question.
Rather than answering it, you chose to make assumptions about what was
behind it.

You asked a question that imputed to me an assumption. It was an
assumption I never made, about an issue which I never speculated on.
You made the assumption out of your own imagination: you answer it. You
have repeatedly pulled this puerile parlor trick of imputing to people
assumptions they never made and then demanding answers, hiding behind
the obvious facade of "I just asked a question." This may impress the
other kiddies at your day care center, but honest adults don't do this.
Go back to your sandbox.
Girls, girls, girls!!!

Now, kiss and make up. We forgive you.

Sep 17 '06 #37

P: n/a
In article <-6******************************@bt.com>,
Richard Heathfield <in*****@invalid.invalidwrote:
....
>I suggest you guys both get yourselves down to the fridge and see if there's
any beer left. :-)
Agreed. Keeping in mind, of course, that the term "guys" is being used
here in its modern, generic sense.

Sep 17 '06 #38

P: n/a
In article <ee***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
>In article <4n************@individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:
>>You asked a question that imputed to me an assumption. It was an
assumption I never made, about an issue which I never speculated on.

Your post - in response to an assertion that it was unnecessary to
free memory before exiting, because the OS will do it - could quite
naturally be taken as implying that you *should* free memory, because
the OS won't necessarily do it. That would only make sense if the OS
reclaimed memory that you freed, which is equally susceptible to your
rather rude comment:
>Unless you can
show where the standard for C requires this, keep your non-portable,
system-specific opinions to yourself.

Now perhaps you didn't mean to imply that you should free memory, but
I don't think you can blame people for inferring that.
Never argue with a pig. You won't get anywhere, and the pig likes it.

Sep 17 '06 #39

P: n/a
In article <4n************@individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:
>Keith Thompson wrote:
>Please try a little reading comprehension. I asked a question.
Rather than answering it, you chose to make assumptions about what was
behind it.

Idiot! I answered your question. To repeat your question:
>Are you assuming that memory that has been free()d *will* be reclaimed
by the operating system? If so, what is your basis for that
assumption?

You are obviously too stupid to understand, so I will make it as clear
as possible: I do not make that assumption. Got it?

You made up the assumption, asked me (as if it were somehow related to
anything I wrote, which it is not) if I held it. I was clear that the
source of that assumption was you, not me. I never wrote anything on
which your baby pseudo-cross examination could be based. Go away.
Let's take a vote: Who should go away - Keith or Martin?
I vote neither - both are too entertaining, each in their own way.

Sep 17 '06 #40

P: n/a
In article <m3************@wpsoftware.net>,
Andrew Poelstra <ap*******@false.sitewrote:
>Keith Thompson <ks***@mib.orgwrites:
>Are you assuming that memory that has been free()d *will* be reclaimed
by the operating system? If so, what is your basis for that
assumption?

Since there's some confusion on this point:

To me it appears that this is just a question. It doesn't appear to be
making any assumptions about what the answer might be. It certainly
doesn't appear offensive in any way.
It's only offensive in the mind of a nutjob.

Sep 17 '06 #41

P: n/a
Kenny McCormack wrote:
In article <4n************@individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:
>>Keith Thompson wrote:
Let's take a vote: Who should go away - Keith or Martin?
I vote neither - both are too entertaining, each in their own way.
I vote : PLONK
Sep 17 '06 #42

This discussion thread is closed

Replies have been disabled for this discussion.