variable allocated from stack/bss ??

[Richard Heathfield]

Tak-Shing Chan said:

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.

Yes. *Now* you have the makings of a point.

Just one nit: s/ arguably//

Four or five years ago, arguably, the "arguably" might have been justified.
But not now.

 

[Tak-Shing Chan]

Tak-Shing Chan said:


Yes. *Now* you have the makings of a point.

Just one nit: s/ arguably//

Four or five years ago, arguably, the "arguably" might have been justified.
But not now.

Are you referring to Dan Pop?

Tak-Shing

 

[Kenneth Brody]

Keith Thompson wrote:
[...]

As far as I know (and I could very easily be mistaken), the bss
section, on systems that have such a thing, is initialized to
all-bits-zero. This implies that the bss section cannot be used for
pointers *unless* all-bits-zero happens to be a null pointer, or
unless any pointers are initialized by explicit code during program
startup.

My suspicion is that all system that use "bss" have all-bits-zero null
pointers. Since it's been quite thoroughly established that null
pointers *don't* have to be all-bits-zero, this is yet another reason
not to assume that "bss" is either universal or directly relevant to
the C language.

I know there have been systems with null pointers not represented as
all-bits-zero (though I don't know if any such systems are recent
enough to conform to C90, much less C99). Did this affect program
startup and the use of bss or something similar?

All this also applies to floating-point types.

Well, such an implementation could have multiple bss-like segments.
One for all-bit-zero, one for NULL pointers (or more, should a NULL
char* be represented differently than, say, a void(*)()), one for
floats, and so on.

Long ago, I used a C compiler on MS-DOS which stored the all-bits-
zero image in the executable itself, rather than zeroing out a
block of memory on startup.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Richard Heathfield]

Tak-Shing Chan said:

Are you referring to Dan Pop?

I was actually thinking of Lawrence.

 

[Random832]

Tak-Shing Chan said:


Yes. *Now* you have the makings of a point.

Just one nit: s/ arguably//

Four or five years ago, arguably, the "arguably" might have been justified.
But not now.

I'd like to remind people of the definition I gave in another thread for
the word "arguable" [of which "arguably" is a form]. After all, if
whatever's being qualified with it is actually true, one wouldn't need
to say "arguably".

It's kind of like truthiness that way, except more explicitly
disingenuous.

 

[Al Balmer]

What is "closely related" for you might not be "closely
related" for others. Problem: who decides what is related and
how close is close enough?

Moot point. The writer under discussion has already stipulated that
his reply was off topic. His position is that he doesn't care.

 

[Random832]

Keith Thompson wrote:
[...]

As far as I know (and I could very easily be mistaken), the bss
section, on systems that have such a thing, is initialized to
all-bits-zero. This implies that the bss section cannot be used for
pointers *unless* all-bits-zero happens to be a null pointer, or
unless any pointers are initialized by explicit code during program
startup.

My suspicion is that all system that use "bss" have all-bits-zero null
pointers. Since it's been quite thoroughly established that null
pointers *don't* have to be all-bits-zero, this is yet another reason
not to assume that "bss" is either universal or directly relevant to
the C language.

I know there have been systems with null pointers not represented as
all-bits-zero (though I don't know if any such systems are recent
enough to conform to C90, much less C99). Did this affect program
startup and the use of bss or something similar?

All this also applies to floating-point types.

Well, such an implementation could have multiple bss-like segments.
One for all-bit-zero, one for NULL pointers (or more, should a NULL
char* be represented differently than, say, a void(*)()), one for
floats, and so on.

Long ago, I used a C compiler on MS-DOS which stored the all-bits-
zero image in the executable itself, rather than zeroing out a
block of memory on startup.

Linux a.out did that.

What I think is amazing, is that some people think that a.out is better
for rescue disks because executables contain long sections of zeroes
that can be compressed or sparse-filed out, and therefore use it in
preference to ELF which omits the zeroes.

http://www.nic.com/~cheah/hole.html
} Typically, one would start with a light version of the shared library,
} such as libc-lite.so.4.6.27, and then shrink it a further 260K or so
} by making it sparse. Unfortunately, such a technique is no longer
} possible with the new ELF format binaries since the new format does
} not have many long strings of nulls. So, rescue disks are sometimes
} still created in the old a.out format.

Right. Because it's better to have the long strings of nulls and
sparse-file them away, than to simply omit them from the file in the
first place.

 

[Richard Heathfield]

Random832 said:

I'd like to remind people of the definition I gave in another thread for
the word "arguable" [of which "arguably" is a form]. After all, if
whatever's being qualified with it is actually true, one wouldn't need
to say "arguably".

That was precisely my point.

 

[Tak-Shing Chan]

Moot point. The writer under discussion has already stipulated that
his reply was off topic. His position is that he doesn't care.

I believe that MQ was trying to make a distinction between
``somewhat off-topic'' and ``clearly off-topic'', which I think
is very different from ``doesn't care''.

After all, the father of C himself used this term in 1988
(look up on comp.lang.c).

Tak-Shing

 

[Keith Thompson]

Keith Thompson wrote: [...]

I know there have been systems with null pointers not represented as
all-bits-zero (though I don't know if any such systems are recent
enough to conform to C90, much less C99). Did this affect program
startup and the use of bss or something similar?

All this also applies to floating-point types.

Well, such an implementation could have multiple bss-like segments.
One for all-bit-zero, one for NULL pointers (or more, should a NULL
char* be represented differently than, say, a void(*)()), one for
floats, and so on.

[...]

struct {
void *x;
char *y;
double z;
} that_would_not_actually_work;

 

[Al Balmer]

I believe that MQ was trying to make a distinction between
``somewhat off-topic'' and ``clearly off-topic'', which I think
is very different from ``doesn't care''.

The sentence "I know that the topic is not standard C, but I don't
care." seemed quite clear to me. Of course, that need not prevent you
from believing whatever you choose, but it does raise some questions.

 

[Kenneth Brody]

Keith Thompson wrote: [...]

I know there have been systems with null pointers not represented as
all-bits-zero (though I don't know if any such systems are recent
enough to conform to C90, much less C99). Did this affect program
startup and the use of bss or something similar?

All this also applies to floating-point types.

Well, such an implementation could have multiple bss-like segments.
One for all-bit-zero, one for NULL pointers (or more, should a NULL
char* be represented differently than, say, a void(*)()), one for
floats, and so on.

[...]

struct {
void *x;
char *y;
double z;
} that_would_not_actually_work;

Obviously, the "bss" situation doesn't work for all things. In a
case where all-bits-zero is not a valid pointer or a valid double,
then the compiler would probably put such a variable in the same
memory area as explicitly-initialized variables.

Of course, how it handles this is implememtation-specific, just
like the concept of "bss" and "stack" from the OP.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Tak-Shing Chan]

The sentence "I know that the topic is not standard C, but I don't
care." seemed quite clear to me. Of course, that need not prevent you
from believing whatever you choose, but it does raise some questions.

You are citing MQ out of context. The full context follows:

MQ> There are some topics that are clearly off-topic, and some that are
MQ> marginal. It is up to each individual to decide this, not the group
MQ> "moderators". When someone answers a question that's off-topic, we
MQ> always see the bureaucracy chime in with "chapter and verse" bollocks.
MQ> I know that the topic is not standard C, but I don't care. That is
MQ> what I mean by intolerance.

We can see that MQ was making a distinction between ``clearly
off-topic'' and ``marginal'' posts. The thing that MQ ``doesn't
care'' about is the ``bureaucracy chime in'' whenever it is not
standard C, even when the level of off-topicness is ``marginal''.

Tak-Shing

 

[Al Balmer]

You are citing MQ out of context. The full context follows:

MQ> There are some topics that are clearly off-topic, and some that are
MQ> marginal. It is up to each individual to decide this, not the group
MQ> "moderators". When someone answers a question that's off-topic, we
MQ> always see the bureaucracy chime in with "chapter and verse" bollocks.
MQ> I know that the topic is not standard C, but I don't care. That is
MQ> what I mean by intolerance.

We can see that MQ was making a distinction between ``clearly
off-topic'' and ``marginal'' posts. The thing that MQ ``doesn't
care'' about is the ``bureaucracy chime in'' whenever it is not
standard C, even when the level of off-topicness is ``marginal''.

Then either your reading ability or his writing is off base. That's
not at all what he said.

 

[Tak-Shing Chan]

Then either your reading ability or his writing is off base. That's
not at all what he said.

Read between the lines. MQ's ``not standard C, but I don't
care'' means that standard C is irrelevant to the point under
discussion (``marginal'' topicality). It does not mean that he
``doesn't care'' about standard C in general.

Tak-Shing

 

[Al Balmer]

Read between the lines. MQ's ``not standard C, but I don't
care'' means that standard C is irrelevant to the point under
discussion (``marginal'' topicality). It does not mean that he
``doesn't care'' about standard C in general.

With sufficient "reading between the lines", one can infer anything. I
prefer to believe that MQ is capable of writing what he means.

 

[Frederick Gotham]

Tak-Shing Chan:

Are you referring to Dan Pop?

Out of curiosity, who is this Dan Pop character that gets mentioned so much
on this newsgroup?

 

[Ian Collins]

Tak-Shing Chan:





Out of curiosity, who is this Dan Pop character that gets mentioned so much
on this newsgroup?

Have a search back through the archives and enjoy!

 

[Keith Thompson]

Have a search back through the archives and enjoy!

And while you're at it, *engage your brain*! (You'll get the joke
soon enough.)

 

[Joe Wright]

Tak-Shing Chan said:


I was actually thinking of Lawrence.

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