variable allocated from stack/bss ??

[Richard Heathfield]

Joe Wright said:

He was back a few months ago and now gone again. Are you in touch with
Lawrence Kirby? Is he alright?

I presume he's fine. I suppose in theory I could contact him, yes, but no,
I'm not going to. He's entitled to his privacy.

 

[Kenny McCormack]

Only for amateur programmers. If the OP wants to become a professional,
he would be advised not to assume that all the world's a Windows
machine.

Umm... Words fail me. Suffice to say that if they want to be a
professional, they're not going to find it here.

I think the above, at the amateur level as you say, is about right for a
Usenet newsgroup.

 

[Kenny McCormack]

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?

And it was BS the first time you explained it, the second time, and
every time subsequent to that. Explaining it over & over does not have
any effect on its underlying status as BS.

(You'd think anyone with an IQ above room temperature would understand this)

 

[goose]

I'm a little late to this thread, but anyway ...

MQ wrote:

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

That's probably true for most definitions of 'most'.

Given that the poster
obviously is working on a platform that uses stack/BSS,

How do you know this? From the code that was posted, I cannot
tell that the poster is working on a platform that uses stack/BSS.

For all you know, the poster is trying to port his existing
knowledge of stack/BSS platforms to a different platform
on which the above code *works*. This different platform
may not necessarily have a stack/BSS but you happily
inform him that the code he posted *must* have a stack/BSS.

Hopefully (most probably?), the poster is not working on
a life-critical system and your information does not kill
anyone.

the answer is
clear,

The "answer" is, at best incomplete, at worst incorrect. Clarity
is not an issue here. It's perfectly possible to be clear as well
as incorrect.

even though the question is somewhat off-topic

No need to bring topicality into it; if you had ended of your
answer with "some systems have it, some don't" I doubt
many here would have found fault with it. However your
response would have only reinforced the posters misinformed
view of stack/BSS WRT the C language.

hth, hand
goose,

 

[goose]

Welcome to comp.lang.c, onkar. Perhaps one of the most painful
experiences known to man

I wouldn't worry too much about it; onkar has now had his question
sufficiently answered, had he bothered to read the entire thread. The
answers given here (WRT his question) have no doubt cleared up
all questions he had about the stack, BSS, static, auto, etc in C.

Summary:
1. C has no concept of stack or BSS.
2. C has no concept of /where/ storage occurs, only concerned with
/when/ storage
occurrs.
3. Some implementations choose to use a stack and/or BSS.
4. Not all implementations will use a stack or BSS.

Purely by numbers, I suspect that implementations *without*
a stack and/or BSS outnumber implementations with it. There
are many more microcontrollers in the world than desktop PeeCees
after all.

Although, this begin CLC, someone is bound to post googled numbers
to assert otherwise.

goose,

 

[Chris Dollin]

[staying out of this for the most part, but just one point begs to be made]

Tak-Shing Chan said:

On the contrary, I believe that there exist a large spectrum
of positions. For example, I would classify Jacob Navia as a
liberal, Steve Summit as a moderate, and Keith Thompson as a
conservative. I do not believe that these three regulars take
``compatible positions on what's topical''.

Chris specifically mentioned "(a) make valuable contributions". Do you have
a better example for "liberal"? If so, then maybe you have the makings of a
point.

With regards Jacob, I think we can agree to disagree.
OK.

How about Chris Torek? He is arguably the most valuable
contributor to this group, and is also liberal enough to have
posted UNIX and assembly language stuffs here.

Chris Torek is an excellent contributor. I will immediately say that
independant of his (high) technical worth, he always seems to manage
being polite and keep to the issues (not personalities) involved.
When I fail in that regard, it is he I think of as one of the best
of us.

Without going and searching his posts I can one rely on my memory
about "liberal enough to have posted UNIX and assembly language
stuffs here" - my /recollection/ (which may be incorrect) is that
when his posts contain such material, it is marked as off-topic,
ie not a Standard C issue, and is in /support/ of Standard C issues.
For instance, I recall discussions of whether the null pointer
has to be all-bits-zero where he has not only explained why it is
that an implementation doesn't /need/ to have null being all bits zero,
but also given as an example the Prime machines where null was /in fact/
not all-bits-zero. Similarly pieces of assembly language can be used
to show why some assumption (of the form "all the world's a
Vax/x86/Deathstation") about generated code is wrong.

I leave it to him, if he thinks it worthwhile, to position himself
on your axis of liberality.

The off-topic posts with which this conversation started were not,
I think, of a kind that he would produce.

 

[trm]

Not really. jacob's logic is reasonably sound in this instance,
though it's based on some shaky premises.

Given: The observed value of i is non-zero. If i were static, its
observed value would be zero. Therefore, i is not static.

(Of course, we can infer that i is not static much more easily by
observing that it's declared inside a function with no "static"
keyword.)

The argument falls down because the program invokes undefined
behavior, so the fact that the *observed* value of i is non-zero
does not guarantee that its *actual* value is non-zero.

The premise is even shakier than that, since it was never actually
stated that the observed value was non-zero. (It's probably not an
unreasonable assumption, provided that we additionally assume
that the OP was not intentionally trolling.)

 

[Spiros Bousbouras]

Aside: Does the (adjectives suppressed) google interface heed
follow-ups? cross-posts?

It does.

 

[Dave Thompson]

<OT>

I'm only seeing one side of this discussion, but now I'm curious. Has
Jacob invented a new type of variable called "bss"? In my assembler
coding days, "bss" meant "block storage symbol" and was implemented by
simply incrementing the program counter by the requested amount, which
of course had no effect on memory thus skipped.

Traditionally it meant 'Block Starting with Symbol', in contrast to
'Block Ending with Symbol' which was used on IIRC IBM 709x because it
had backwards(!) indexing of (machineword=36bits) arrays.
Both BSS and BES were (again traditionally) not explicitly
initialized, and so could be optimized in some (most?) object and/or
executable formats. Especially those which collect them into a
contiguous section or sections (or equivalent), which is sometimes
(but not always) called simply the/a BSS section.

With the advent of multiuser/multitasking and especially timesharing
it became important memory newly assigned to a process be initialized
(somehow) rather than retain data from (possibly) another user, and
conventional to zero-initialize memory not explicitlly initialized.

As long as I'm posting to this greatly overblown thread, I'll add that
I commonly use an implementation whose object and executable format
does not have any separate section with BSS characteristics, but does
support unstored demandzero _pages_ within the data section, which
depending on how the linker places your data, only partly under your
control, may or may not result in approximately the same effect. (And
it does have all-bits-zero null pointers and floating-point zero, so
those can be included in such demandzero areas. Although it does _not_
have the same representation for all data pointers.)

- David.Thompson1 at worldnet.att.net