variable allocated from stack/bss ??

[Old Wolf]

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.

This is implementation-dependent. On the implementation I
am currently working on, the "bss" section does not get zeroed.
Zero-initialized vars go in the section C$$zidata.

 

[Old Wolf]

Yes we can. The original poster wrote:
Given the following code & variable i .

int main(int argc,char **argv){
int i;
printf("%d\n",i);
return 0;
}

here i is allocated from bss or stack ?

I think it is stack,because it prints garbage value; If it were
allocated from bss the default value would be 0
please tell me if I am right or wrong ??

NOTE:
"... it prints a garbage value. If it were allocated from the
bss the default value would be 0"

He said it was NOT ZERO.

The program causes undefind behaviour by calling printf without
a prototype in scope. So the variable could have a zero value,
but it is getting printed wrongly because printf was not prototyped
properly.

 

[J. J. Farrell]

Since bss variables are initialized to zero (the standard does not
name them "bss" of course but it requires that uninitialized
variables be initilaized to zero), that variable CAN'T be an
uninitialized variable in that sense.

Why not? We have no idea what the value of the variable is in the above
program, or even in a modified version with printf() correctly
declared. What printf() chooses to print (if anything) is not
necessarily related to the current contents of the variable since the
variable is uninitialized.

 

[Peter Nilsson]

Yes, you are right

To the OP,

Jacob's answer means you get to compete in Sale of the Century and
Who Wants to be a Millionaire. Unfortunately, the knowledge doesn't
mean that you are in any way more empowered with regards to
becoming a better C programmer.

Indeed, 'information', like answers to the question you asked, are
generally more likely to make you a worse programmer. You might
now know slightly more about given implementations, but if you take
it for granted, you'll actually know slightly less about C.

C has always defined storage more in terms of _when_ rather than
_where_. Once you realise that fact and program accordingly you'll
face fewer problems in the future.

 

[Keith Thompson]

Irrelevant heathfield, completely irrelevant. Non
prototyped functions are assumed returning an int.
So what?

printf is a variadic function. Calling a variadic function with no
prototype in scope invokes undefined behavior. Without a prototype, a
function is assumed, in C90, to be a function returning int and taking
a fixed but unspecified number and type of arguments; printf does not
qualify. An implementation could use a completely different calling
convention for variadic functions than for non-variadic functions. If
you call a variadic function using a non-variadic calling convention,
it could easily fetch an argument value from the wrong location. One
possible result: printf prints 42 even though i==0.

It will happen to "work" on many implementations, but it is not
required to.

Yes, and so what?


Nowhere is specified that the behavior is
undefined. It has an UNDEFINED VALUE heathfield but the
program is not "undefined" nor it invokes "undefined behavior"

Talking nonsense again.

Take a look at the standard. It talks about "undefined behavior"; the
phrase "undefined value" appears nowhere in the standard. See also
"implementation-defined value", "indeterminate value", "unspecified
value", and "trap representation".

Suppose type int has one or more trap representations. Suppose an
uninitialized int object happens to have a trap representation. (An
implementation could do this deliberately, for the purpose of catching
errors as early as possible.) The result of reading a variable with a
trap representation is undefined behavior. The standard says so quite
clearly.

[snip]

 

[Keith Thompson]

Zero is a valid uninitialised value (as it were). Heck, ANY
bitpattern is a valid value.


Your logic is similar to "all men are humans, therefore all humans are
men".

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.

 

[Gordon Burditt]

Since bss variables are initialized to zero (the standard does not

name them "bss" of course but it requires that uninitialized
variables be initilaized to zero), that variable CAN'T be an
uninitialized variable in that sense. That mens is an automatic
variable allocated in temporary storage. This storage is normally
the stack in most implementations

There is nothing prohibiting an implementation from allocating space
for a hardware stack out of the so-called "bss" section. However,
just because the storage for the stack was initialized to zero
before the program started doesn't mean that auto variables will
be zero (especially on the second call and later). The storage
immediately below the memory pointed at by the stack pointer (assuming
there is one) is subject to getting scribbled on at any time (due
to interrupts, etc.). The definition of "below" here is determined
by the stack operation "push down, pop up" regardless of stack
growth direction. Implicit library calls may also use (and scribble
on) the hardware stack (again, if there is one).

 

[Jack Klein]

Translation:

In some weird implementation that could exist somewhere there is no
stack and no bss. Since I want to be pedantic I will generalize then
to say that "The C language dfoesn't require a stack" even if I know
that 99% of all the implementations in work stations today use
exactly those.

Translation:

Since I think only workstations are important, I am ignoring 98% of
all the processors produced in the world each year.

 

[Jack Klein]

Since bss variables are initialized to zero (the standard does not
name them "bss" of course but it requires that uninitialized
variables be initilaized to zero), that variable CAN'T be an
uninitialized variable in that sense. That mens is an automatic
variable allocated in temporary storage. This storage is normally
the stack in most implementations

No, actually for this program most compilers for most ***SANE***
processor architectures (which the x86 is NOT) would put this object
in a register and it would never exist in memory at all.

I wouldn't be surprised to find it in AR4, for example.

 

[MQ]

C&V please.

Please expand, I'm not familiar with these abbreviations

 

[Keith Thompson]

Please expand, I'm not familiar with these abbreviations

Chapter and Verse. He's asking for a citation from the C standard.
Since the standard doesn't refer to "stack" or "bss", we can assume
that no such citation will be forthcoming.

(The terms "chapter" and "verse" usually refer to Biblical citations;
their use in this context is somewhat jocular.)

 

[MQ]

Chapter and Verse. He's asking for a citation from the C standard.
Since the standard doesn't refer to "stack" or "bss", we can assume
that no such citation will be forthcoming.

(The terms "chapter" and "verse" usually refer to Biblical citations;
their use in this context is somewhat jocular.)

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

 

[MQ]

Given the following code & variable i .

int main(int argc,char **argv){
int i;
printf("%d\n",i);
return 0;
}

here i is allocated from bss or stack ?

I think it is stack,because it prints garbage value; If it were
allocated from bss the default value would be 0
please tell me if I am right or wrong ??

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

 

[Keith Thompson]

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

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.

 

[Ian Collins]

No, actually for this program most compilers for most ***SANE***
processor architectures (which the x86 is NOT) would put this object
in a register and it would never exist in memory at all.

I wouldn't be surprised to find it in AR4, for example.

Seeing as the variable is uninitialised, is there any reason for it to
be there at all? The compiler could simply pass a constant to printf.

 

[MQ]

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.

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.

 

[CBFalconer]

Zero is a valid uninitialised value (as it were). Heck, ANY
bitpattern is a valid value.

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

 

[CBFalconer]

.... snip ...

There is more to C than what the standard text says. Mostly it is
silent in many important questions. The linker is not mentioned,
neither is the debugger, the executable format, and many other
questions that are central to building a functioning program.
Since I have implemented those under several OSes for lcc-win32 I
am aware of those maybe more than you that seem to dwell in the
standard text as it was the holy bible "Chapter and verse" is a
dogmatic answer heathfield.

What linker? What debugger? What executable format? None of
these are required in a C system. For example, did you ever hear
of interpreters?

 

[santosh]

What linker? What debugger? What executable format? None of
these are required in a C system. For example, did you ever hear
of interpreters?

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.

 

[Martin Ambuhl]

Translation:

In some weird implementation that could exist somewhere there is no
stack and no bss. Since I want to be pedantic I will generalize then
to say that "The C language dfoesn't require a stack" even if I know
that 99% of all the implementations in work stations today use
exactly those.

Having proved repeatedly that he is completely incapable what the C
language is and is unable to read, Jacob Navia is without doubt
completely unqualified to provide translations of others' writing.
Jacob writes off the overwhelming majority of processors on which C is
used, simply because his Microsoft-enslaved implementation does not run
on them.