C and ELF segment

[linq936]

Hi,
I hope this question belongs to this group.

I am studying book <<Expert C Programming>and in the chapter of
run time data structure, it mentions that BSS segment only stores the
size of the un-initialized data, it does not have the data images, so
it does not take up any actual space in the object file.

I tried out a simple code, but it is not as said.

Here is my first code:

#include <stdio.h>

int main(void){
printf("hello");
}

and I run size command:

size a.out
text data bss dec hex filename
874 256 4 1134 46e a.out

You see bss is of size 4.

Now the 2nd code:

#include <stdio.h>

int arr[1000];

int main(void){
printf("hello");
}

and size command output:
size a.out
text data bss dec hex filename
874 256 4032 5162 142a a.out

so bss size increases roughly the array size!

Is this because my GCC on Intel machine has different format than
before?

[Chris McDonald]

linq936 <li*****@hotmail.comwrites:

>Hi,
I hope this question belongs to this group.

You will probably receive many replies stating that it does not belong
here; comp.unix.programmer is a better choice.

I am studying book <<Expert C Programming>and in the chapter of
run time data structure, it mentions that BSS segment only stores the
size of the un-initialized data, it does not have the data images, so
it does not take up any actual space in the object file.

I tried out a simple code, but it is not as said.

From your logic, you appear to be confusing the values reported by
the 'size' command with the file's size (as reported by 'ls' on UNIX system).

--
Chris.

[Chad]

On Jul 31, 6:15 pm, linq936 <[e-mail]:

Hi,
I hope this question belongs to this group.

I am studying book <<Expert C Programming>and in the chapter of
run time data structure, it mentions that BSS segment only stores the
size of the un-initialized data, it does not have the data images, so
it does not take up any actual space in the object file.

What is a data image?

I tried out a simple code, but it is not as said.

Here is my first code:

#include <stdio.h>

int main(void){
printf("hello");

If I remember correctly, not having the '\n' causes undefined
behavior. Also, were is the 'return'?!

}

and I run size command:

My Operating system doesn't have the size command.

size a.out
text data bss dec hex filename
874 256 4 1134 46e a.out

You see bss is of size 4.

Now the 2nd code:

#include <stdio.h>

int arr[1000];

int main(void){
printf("hello");

}

and size command output:
size a.out
text data bss dec hex filename
874 256 4032 5162 142a a.out

so bss size increases roughly the array size!

Is this because my GCC on Intel machine has different format than
before?

And when I think of ELF, I think of men running around in green tights
at Christmas time.

[jacob navia]

linq936 wrote:

Hi,
I hope this question belongs to this group.

I am studying book <<Expert C Programming>and in the chapter of
run time data structure, it mentions that BSS segment only stores the
size of the un-initialized data, it does not have the data images, so
it does not take up any actual space in the object file.

I tried out a simple code, but it is not as said.

Here is my first code:

#include <stdio.h>

int main(void){
printf("hello");
}

and I run size command:

size a.out
text data bss dec hex filename
874 256 4 1134 46e a.out

You see bss is of size 4.

Now the 2nd code:

#include <stdio.h>

int arr[1000];

int main(void){
printf("hello");
}

and size command output:
size a.out
text data bss dec hex filename
874 256 4032 5162 142a a.out

so bss size increases roughly the array size!

Is this because my GCC on Intel machine has different format than
before?

Supposing sizeof(int) == 4, an array of 1000 ints is 4000 bytes,
the size of the bss segment has increased accordingly.

The other 32 are probably alignment, but I do not know
exactly.

[Jack Klein]

On Wed, 01 Aug 2007 01:15:45 -0000, linq936 <li*****@hotmail.com>
wrote in comp.lang.c:

Hi,
I hope this question belongs to this group.

Actually, it really does not.

I am studying book <<Expert C Programming>and in the chapter of
run time data structure, it mentions that BSS segment only stores the
size of the un-initialized data, it does not have the data images, so
it does not take up any actual space in the object file.

Assuming that you are talking about the book "Expert C Programming:
Deep C Secrets" by Peter van der Linden, it is indeed an excellent
book for intermediate to advanced C programmers.

One thing that you need to understand is that this book was written in
1994, 13 years ago, and things can change in that time. The C
language does not actually specify things like segments, a BSS
segment, Or ELF, COFF, a.out, OMF86, or any other file format. Peter
was talking about the behavior typical UNIX implementations that he
was familiar with at the time, not anything specified by C or UNIX or
guaranteed to remain unchanged forever.

I tried out a simple code, but it is not as said.

Here is my first code:

#include <stdio.h>

int main(void){
printf("hello");
}

and I run size command:

size a.out
text data bss dec hex filename
874 256 4 1134 46e a.out

You see bss is of size 4.

Now the 2nd code:

#include <stdio.h>

int arr[1000];

int main(void){
printf("hello");
}

and size command output:
size a.out
text data bss dec hex filename
874 256 4032 5162 142a a.out

so bss size increases roughly the array size!

Is this because my GCC on Intel machine has different format than
before?

Also, it is quite possible that what Peter said applies to your
compiler, but you are misunderstanding what he wrote. Since the
executable file must store the size, if not the contents, of the BSS
segment, what would you expect the "size" command to report?

What you really want to know is the difference in the file size of the
two a.out files themselves. If the second file is about 4,000 octets
larger than the first, the compiler and linker are storing 1,000 int
values of 0 in the file. If the second file is about the same size as
the first, perhaps just slightly larger, then it is obviously not
storing all those 0 valued ints in the file.

If you have further questions about object files, executable files,
segments, or other such thing are specific to your tool set, and not
defined by the language, you should ask in places like a gcc support
group (gnu.gcc.*), or perhaps news:comp.os.linux-development.apps or
news:comp.unix.programmer, if you develop on one of those platforms.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[santosh]

Jack Klein wrote:

On Wed, 01 Aug 2007 01:15:45 -0000, linq936 <li*****@hotmail.com>
wrote in comp.lang.c:

>Hi,
I hope this question belongs to this group.

Actually, it really does not.

<snip>

If you have further questions about object files, executable files,
segments, or other such thing are specific to your tool set, and not
defined by the language, you should ask in places like a gcc support
group (gnu.gcc.*), or perhaps news:comp.os.linux-development.apps or
news:comp.unix.programmer, if you develop on one of those platforms.

I'll also add <news:alt.lang.asmand <news:comp.lang.asm.x86to the list
of places where the OP can post his question. Executable file formats and
linkers are occasionally discussed there. A Google search of those groups
might turn up good threads.