R
Richard Heathfield
Bart said:
Why did you write those last four sentences?
Why did you write those last four sentences?
B
Bart
Richard said:Bart said:
Why did you write those last four sentences?
In the hope that he may actually read them. Maybe I'll try your
one-line reply approach.
Regards,
Bart.
F
fermineutron
Richard said:Why did you write those last four sentences?
Probably because he wants to shut me up without actually answering my
question.
Interestingly enough, regarding the comments made about me not reading
the messages and following advice given, When the advice is given on
the particular issue that i am asking about i ussually follow through
on it. And there is no proof that I do not make a mental note on advice
which is offtopic. In some cases it is possible that i will post code
that has same bugs as were addressed earlier in a different thread that
i started, example would be using scanf function to read in a file
name, this was addressed by Richard H. while back, now i know that
while loop with getc function is better but for quck coding of the
parts of code which i am likely to change in the future anyways, scanf
will do.
The question about .data Segment of compiled C code still stands,
unless it was answered while i am typing this messege.
B
Bart
fermineutron said:
See. You did it again.
The question was already answered, but you didn't notice.
C doesn't need to have a stack only "automatic storage". When an
implementation does have a stack it creates automatic objects on the
stack so that recursive function calls work correctly. Just look at the
disassembly output of your compiler to see what I mean.
But as you should already know if you read more carefully, this is all
off-topic in comp.lang.c.
Regards,
Bart.
B
Bill Medland
Agreed that it's OT but (in your environment):fermineutron said:
Static variables go in the data segment
Automatic variables go in the stack segment
Code goes in the code segment.
W
Walter Roberson
Bart said:
Even if an implementation has stacks, it does not necessarily put
automatic objects on a stack. Recursive function calls work just
as well if the implementation places automatics in a heap that
is distinct from the memory address space used for malloc(). Or it
could use some other kind of dynamic memory request to the operating
system. [But as best I can recall at the moment, it cannot use
malloc() itself -- I believe I've encountered wording in C89 along
the lines of "An implementation shall behave as if no library function
calls malloc().]
Keep in mind that some implementations explicitly seperate control
information (e.g., return addresses, possibly saved registers)
and data information (e.g., all program variables and dynamic memory)
so saying that an implementation has a stack doesn't really tell you
what it -does- with that stack. And of course as far as the C
standard is concerned, the way it handles such matters is not
of interest except to the implementers.
B
Bart
Walter said:
Yeah, I know, but all this is beyond the attention span of
fermineutron.
Regards,
Bart.
K
Keith Thompson
fermineutron said:
Please provide context when you post a followup. Google Groups used
to have a bug that made this difficult, but it was corrected some time
ago. See <http://cfaj.freeshell.org/google/>.
I happen to be reading this entire thread at once, but someone jumping
into the middle is going to have trouble following the discussion.
That may well be true, but we don't discuss Intel based computers
here.
[snip]
The C compiler does whatever it needs to do to make the program behave
in accordance with the semantics defined by the C standard. The
standard doesn't mention "segments", or "stack", or "heap". If the
generated code happens to use those constructs, that's fine, but they
may not even exist on the target system.
What the standard *does* say is that there are three "storage
durations": static, automatic, and allocated. Static objects (either
declared outside any function, or declared within a function with the
"static" keyword) exist throughout the lifetime of the program.
Automatic objects vanish on exit from the scope (function or block) in
which the're declared. Allocated objects are created by malloc() and
destroyed by free() (see also calloc() and realloc()).
Though the standard doesn't say so, an implementation may typically
place different limits on the total sizes of objects of the three
storage durations. If you run into such a limit, changing the storage
duration may avoid the problem. For example, you declared some very
large objects inside main(), so they have automatic storage duration;
changing them to static (by adding the "static" keyword, or by
declaring them outside main()) or allocated (by allocating them with
malloc() rather than declaring them directly) *might* solve your
problem. Be careful; changing the storage duration can change the
semantics of your program.
It's very common for the limit on automatic objects (which *might* be
allocated on a "stack") to be relatively low.
F
Flash Gordon
fermineutron said:
It is still off topic as Richard pointed out. Try asking in an assembler
group, although from what you have said about assembler your knowledge
of how to program in it is just as bad as your knowledge of C.
F
fermineutron
Agreed that it's OT but (in your environment):
Thank you Bill.
Finnaly someone just addressing the particurar issue that I was asking
about.
By the way, placing automatic vars in the stack segment, is it a choice
of the compiler author or does C standard requires it to be so?
Thank you Bill.
Finnaly someone just addressing the particurar issue that I was asking
about.
By the way, placing automatic vars in the stack segment, is it a choice
of the compiler author or does C standard requires it to be so?
K
Keith Thompson
fermineutron said:
How could the C standard possibly require it? The standard doesn't
even mention the word "stack", and it uses the word "segment" only
in a completely different context.
If you want to know what the standard actually requires, grab a copy
of <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf>.
E
Eric Sosman
fermineutron wrote On 10/27/06 16:47,:
Your follow-up question has already been answered more
than once on this thread. (One sentence, thirteen or fourteen
words. Will he read the whole thing?)
Your follow-up question has already been answered more
than once on this thread. (One sentence, thirteen or fourteen
words. Will he read the whole thing?)
F
fermineutron
The posts between my last one and Bills post which is addressed in my
last one, were made while i was typing the last post so the question in
my last post is alreday answered.
THANK YOU everyone who posted something usefull, currently i can think
of only 1 exception to that group, not going to say who.
last one, were made while i was typing the last post so the question in
my last post is alreday answered.
THANK YOU everyone who posted something usefull, currently i can think
of only 1 exception to that group, not going to say who.
F
fermineutron
By the way if any one is curious, changing my automatic variables from
structures to pointer to structures and (malloc)ing the actual
structures solves the array size issue.
structures to pointer to structures and (malloc)ing the actual
structures solves the array size issue.
K
Keith Thompson
fermineutron said:
*Please* provide context when you post a followup.
See <http://cfaj.freeshell.org/google/>.
B
Bart
fermineutron said:
You're quite confused with C as well as Intel assembly language. But
there's no point writing any kind of explanation because you never read
past the first two sentences. Then, thinking you understand everything
you go on and write heaps of totally misguided and incorrect code. I
bet that's how you read your C and assembly books too.
Learning to program takes patience and care. Your approach is never
going to get you anywhere.
Regards,
Bart.
F
fermineutron
Thank you Bill,
Finally a short and clear answer to the particular question i asked. By
the way, do you happen to know if placeing automatic vars on stack is a
compiler specific/standard or is it a part of C standard itself, hence
in C all automatic vars will allways be on stack as long as the
compiler complies with C standard?
C
CBFalconer
fermineutron said:
No it doesn't, because it is off topic here.
M
Mark McIntyre
C doesn't have a pass-by-reference method. Are you using C++ by
mistake?
I would not be surprised if the problem is that your compiler has a
limitation on automatic and dynamic objects, and you;re exceeding it.
Read the documentation, and consider a more modern compiler....
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
M
Mark McIntyre
Thats fine, but this is comp.lang.c, not comp.assembler, and not
comp.intel.based.computers. This means that discussion of assembler
and intel stack systems is offtopic I'm afraid.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan