variable allocated from stack/bss ??

C

CBFalconer

MQ said:
The poster wanted help, I provided that help. Off-topic or not, how
hard is it for the CLC bureaucracy to at least help them out, *then*
tell them that they are at the wrong newsgroup. Sometimes an answer,
if not absolute, is better than no answer at all. And no answer at all
is 90% of this thread.

An off-topic reply will probably not be properly criticized, since
the experts are reading other newsgroups, where the subject is
topical. No one is perfect, so erroneous answers can always
appear. They do the least harm when rapidly corrected.

The OP probably (we have notable exceptions rampant here) didn't
know the subject was off-topic. The (mistaken) answerer has no
such excuse.
 
K

Keith Thompson

Ian Collins said:
How does that make it an invalid uninitialised value?

Strictly speaking, there's no such thing as a trap value; it's called
a trap representation (which is not a value).

The standard isn't entirely consistent about the distinction, though.
 
K

Keith Thompson

MQ said:
The poster wanted help, I provided that help. Off-topic or not, how
hard is it for the CLC bureaucracy to at least help them out, *then*
tell them that they are at the wrong newsgroup. Sometimes an answer,
if not absolute, is better than no answer at all. And no answer at all
is 90% of this thread.

The reasons for *not* providing off-topic information here have been
discussed repeatedly and at great length. How many times do we have
to go over it?
 
J

jacob navia

Keith said:
The argument is that we discuss the C *language* here. The language
has no concept of stack or BSS. Many implementations do; there are
newsgroups that discuss specific implementations.

As I have said many times you are entitled to your opinion but
we discuss what we want here, not what you (or heathfield) want.

The c language has more to it than the standard.
 
J

jacob navia

MQ said:
I realize that the use of stack/BSS is not covered by the C standard,
but for most platforms this is the case. Given that the poster
obviously is working on a platform that uses stack/BSS, the answer is
clear, even though the question is somewhat off-topic

In the other thread, mr thompson and mr heathfield argue that
there could be implementations without stack/bss, and even that there
could be implementations without a machine at all since a human
could compile the stuff (as stated by one of their "supporters")
 
J

jacob navia

santosh said:
I suppose functional equivalents of these would be considered a minimum
in any modern programming environment.

Besides, strictly speaking, the C standard doesn't specify the method
by which C source is executed. I suppose a human who reads a source,
checks it syntactically and semantically, and manages to output the
expected results, could be considered a C compiler and execution
environment.

OK. This is the best.

There is no linker, no debugger, and no machine. The C language
is a human language designed for the people in comp.lang.c
where they discuss at leisure the whys and why nots of helping
anyone that poses a question.

Not that they answer a question but that they just are there to
bother the people that actually answer questions.

OK. Be it.

When I say that all programs under windows use ExitProcess to finish
the clever heathfield answers

"I can always unplug the machine from the mains, then the
process finishes without calling ExitProcess"

When I say that the uninitialized variables section is mapped
in most systems to the BSS section santosh says that there is no machine
CBFacloner says there is no linker and no debugger, and that is it.

C runs without a machine santosh. You are RIGHT!!!
 
R

Richard Heathfield

MQ said:

I realize that the use of stack/BSS is not covered by the C standard,
but for most platforms this is the case.

(a) even if it were true for all today's and yesterday's platforms, that is
no guarantee that it will be true on future platforms, so let's not lock
ourselves into the present, let alone the past;
(b) since it is not covered by the Standard, the C language doesn't address
the issue, and therefore the OP would be better off asking on a
platform-oriented group.
Given that the poster
obviously is working on a platform that uses stack/BSS, the answer is
clear, even though the question is somewhat off-topic

The answer is misleading, because by the very nature of things it gives the
impression that you are giving a "C answer", this being comp.lang.c,
whereas in fact you're guessing at the OP's implementation characteristics
and answering as if you had guessed correctly.
 
R

Richard Heathfield

CBFalconer said:
No it isn't. It may be a trap value.

I think you've misunderstood him, possibly because of a poor use of "valid".
I am fairly sure Mark means that an indeterminately-valued object might
have any old bit pattern whatsoever, and that this certainly includes the
bit pattern representing the value 0.
 
R

Richard Heathfield

santosh said:
I suppose functional equivalents of these would be considered a minimum
in any modern programming environment.

No, Chuck already mentioned a counter-example - interpreters. These don't
require a linker, a debugger, or an executable format. And as computers get
faster and faster, interpreters become ever more practical.
Besides, strictly speaking, the C standard doesn't specify the method
by which C source is executed. I suppose a human who reads a source,
checks it syntactically and semantically, and manages to output the
expected results, could be considered a C compiler and execution
environment.

Right. IIRC Peter Seebach once claimed to be a conforming implementation -
but nobody seems to know where his (required) documentation has got to. :)
 
K

Keith Thompson

jacob navia said:
When I say that the uninitialized variables section is mapped
in most systems to the BSS section santosh says that there is no machine

You didn't say "most".
CBFacloner says there is no linker and no debugger, and that is it.

CBFalconer never said that, or anything resembling it.
C runs without a machine santosh. You are RIGHT!!!

santosh never said that, or anything resembling it.
 
R

Richard Heathfield

jacob navia said:
santosh wrote:

OK. This is the best.

There is no linker, no debugger, and no machine.

You over-state the case. What has been said is that such things are not
*necessary* to an understanding of the C language. And indeed they are not.
That doesn't mean they are not useful and desirable.
The C language
is a human language designed for the people in comp.lang.c
where they discuss at leisure the whys and why nots of helping
anyone that poses a question.

The C language is a human language all right, in the sense that it is
designed by humans and comprehensible by humans. Tricky to speak, but quite
easy to write *if* you understand it properly. Like any language, it works
best if producers and consumers of sentences written in that language agree
on what those sentences mean. Unlike "natural" languages, however, it has a
formal definition which makes that agreement easier provided only that
people stick to the definition.

It is in an attempt to help people understand the C language (the topic of
this newsgroup) that so many of us devote our time and energy to this
newsgroup. And we do so without payment, putting up with constant sniping
from ignorant people who don't really understand the difference between the
C language and mere implementations of that language. Eventually, even the
most patient of us will tire of such abuse, and the group will slowly lose
its expertise. This has already been happening for some time, and we have
lost a great many very good people - genuine experts - from comp.lang.c,
largely thanks to the idiocy displayed by the ignorant.

Not that they answer a question

If you think so, you are more reading-impaired than I realised.
but that they just are there to
bother the people that actually answer questions.

No, but we do post corrections to answers that are misguided, misleading, or
just plain wrong. Like - um... let me see... well, like yours, for
instance. Your track record for being wrong is quite astounding, especially
since you're supposed to be the maintainer of a C compiler.

OK. Be it.

When I say that all programs under windows use ExitProcess to finish
the clever heathfield answers

"I can always unplug the machine from the mains, then the
process finishes without calling ExitProcess"

The point of my saying that, which you appear to have overlooked, is that
your statement was trivially incorrect. You also appear to have overlooked
my more serious counter-example, so I'll repeat it here. I have available
to me *at least* three C compilers (possibly more - I haven't counted
recently), all of which run under Windows, that can take C programs as
input and produce as output executable files which:

(a) run under Windows
(b) do not contain a call to ExitProcess
(c) do not call any DLLs or static libraries that call ExitProcess

So I have good, solid counter-examples to your false claim. (As usual.)
 
C

CBFalconer

Ian said:
How does that make it an invalid uninitialised value?

It contravenes Marks underlined statement above. Trap values
attempt to define, for a particular implementation, what happens
when you invoke undefined behaviour.
 
C

CBFalconer

jacob said:
.... snip ...

There is no linker, no debugger, and no machine. The C language
is a human language designed for the people in comp.lang.c
where they discuss at leisure the whys and why nots of helping
anyone that poses a question.

Congratulations, this is a fairly correct statement. The C
language is intended for human use. The C compiler translates a
_valid_ C program, expressed in the defined (by the standard) C
language, into something equivalent that can be understood by some
other entity, such as a machine. It might also be a small {1}
green triped from Aldebaran IV.

[1]: The triped needs to be small in order to execute rapidly, due
to the limitation of light speed. This is also known as C in some
circles.
 
S

santosh

jacob said:
In the other thread, mr thompson and mr heathfield argue that
there could be implementations without stack/bss, and even that there
could be implementations without a machine at all since a human
could compile the stuff (as stated by one of their "supporters")

Don't take it too seriously, I clearly meant it as a joke.
 
S

santosh

jacob said:
OK. This is the best.

There is no linker, no debugger, and no machine.
From the P.O.V. of the standard, yes. From the P.O.V. of an
implementation, the first two assertions may or may not be true, the
third, for all practical purposes, false.
The C language
is a human language

Yes! It's an High Level Language.
designed for the people in comp.lang.c

No, designed for anyone who is willing and capable of using it.
where they discuss at leisure the whys and why nots of helping
anyone that poses a question.

That the stack and the .bss segment are niether specified nor required
by the standard is an important piece of information for the
questioner. It tells them:

a. It's not a feature of the C language per se.
b. It's instead dependant upon the hardware, operating system,
compiler, linker and possibly other programs/features, not defined by
the C standard.
c. That this group is not the very best place to ask such questions and
recieve peer-reviewed responses. Instead, groups like comp.arch,
comp.hardware, comp.compilers, comp.compilers.lcc etc. are better
groups to field this question to.

Basically our responses, though they may be irritating to you, lets the
OP sift the kernel of C from the husk of implementation/platform
specific details. This, IMHO, enables the learner, to concentrate on
pure C, until he's capable and ready to delve into the details of
implementations and hardwares. Mind you, I'm not saying the latter is
unimportant, just that it may not be the best place for a beginner to
venture, and that, this group may not be the best place to ask them.

Not that they answer a question but that they just are there to
bother the people that actually answer questions.

The question was answered as well as possible from within the context
of this group's topic.
OK. Be it.

When I say that all programs under windows use ExitProcess to finish
the clever heathfield answers

"I can always unplug the machine from the mains, then the
process finishes without calling ExitProcess"

No. What you claimed was that _all_ programs under Windows _must_ link
to atleast kernel32.dll or ntdll.dll. That was pointed out as false by
several posters. I gave you an example of using the INT 0x2e mechanism
to bypass these dlls.

Another possibility is to attempt to execute a privileged instruction
like mov cr0 xxx, which will cause Windows, (atleast NT family), to
terminate your application, without you having called ExitProcess.
Granted these methods aren't recommended or canonical, but they do
expose the falsity of your absolute assertion.
When I say that the uninitialized variables section is mapped
in most systems to the BSS section santosh says that there is no machine
CBFacloner says there is no linker and no debugger, and that is it.

No, we didn't say that. Just that C the langauge, as defined by the
standard, need not _necessarily_ have these features associated with
it. That doesn't mean that implementations of it don't.
C runs without a machine santosh. You are RIGHT!!!

You misinterpreted me. I said a program in C _could_ conceivably be
executed by a non-machine. The statement is meant to illustrate the
relative flexibility and non-specific nature of the standard with
respect to details of implementation, thus indicating to the OP, that
any answer he recieves to implementation related questions, in a group
not devoted, or connected, to the said features of implementation,
should be taken with a pinch of salt.
 
J

jacob navia

Richard Heathfield a écrit :
MQ said:




(a) even if it were true for all today's and yesterday's platforms, that is
no guarantee that it will be true on future platforms, so let's not lock
ourselves into the present, let alone the past;
(b) since it is not covered by the Standard, the C language doesn't address
the issue, and therefore the OP would be better off asking on a
platform-oriented group.




The answer is misleading, because by the very nature of things it gives the
impression that you are giving a "C answer", this being comp.lang.c,
whereas in fact you're guessing at the OP's implementation characteristics
and answering as if you had guessed correctly.

I am not speaking in the name of anyone but me.
And I can say whatever I find correct to say.
If you do not agree you have the right to disagree
and to say whatever you want. But I do not accept your
views (as should be obvious by now) so it is better
to leave at that.
 
T

Tom St Denis

jacob said:
As I have said many times you are entitled to your opinion but
we discuss what we want here, not what you (or heathfield) want.

The c language has more to it than the standard.

Aha, your problem. This isn't a programmers newsgroup. It's a
language group, and specifically the C language (and not its
non-standard extensions).

If you want to discuss programming issues take it up in another group.

Tom
 
R

Richard Bos

jacob navia said:
Well things have changed since those days probably...
Nowadays bss means the same thing BUT when the OS loads
the stuff, it clears the bss section to zero.

Nowadays, on the dinky toy systems that are everything jacob navia every
had experience on, that is. Of course, there are many more kinds of
systems not only still used but also considered quite modern, which do
things differently.

Richard
 
T

Tom St Denis

jacob said:
In the other thread, mr thompson and mr heathfield argue that
there could be implementations without stack/bss, and even that there
could be implementations without a machine at all since a human
could compile the stuff (as stated by one of their "supporters")

Why is it so hard to think the stack/bss could be the same region of
memory?

Imagine pushing (and zero'ing) bss data on the stack before calling
main(). It would, even in the x86_world be accessible to the entire
process (since the stack should never go up into the "bss region") but
there wouldn't be a distinct region for it.

Not all platforms are an x86 running Windows believe it or not.

While most do have distinct regions of memory for bss/stack they don't
have to, and I imagine in the history of the C language it has come up
before.

Tom
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top