C objects

[junky_fellow]

What is a C object ?

If i have some function "func()" in my C program, then
can i say that "func()" is a C object ?
or if i have some function pointer (ptr) which contains the address
of function "func()", can i say that ptr is pointing to some C object ?

Is a C object always associated with some "data" ?

thanx in advance for any help .....

[pete]

E. Robert Tisdale wrote:

struct X {
int* p;
};

struct X x;

Does the object referenced through x include
the region of data pointer to by p?

No.
x is an object of type struct X.
(sizeof x) is not affected by what x.p points to.
Objects are blocks of contiguous memory.
It's explicitly stated in the C89 object definition.

C89 Last public draft
1.6 DEFINITIONS OF TERMS
* Object --- a region of data storage in the execution environment,
the contents of which can represent values. Except for bit-fields,
objects are composed of contiguous sequences of one or more bytes,
the number, order, and encoding of which are either explicitly
specified or implementation-defined.

A list is not an object.

--
pete

[junky_fellow]

Keith Thompson <ks***@mib.org> wrote in message news:<ln************@nuthaus.mib.org>...

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Keith Thompson wrote:

E. Robert Tisdale writes:
> The type defines
> *all* of the values that an object of that type may have
> so an object *must* be initialized to one of those values
> if it is to be called an object of that type.

Perhaps, but it doesn't have to be initialized to be called an object.
An object is a "region of data storage in the execution environment,
the contents of which can represent values" (C99 3.14).

And, of course, the term "object" as used in C
has nothing at all to do with object-oriented programming.

[Humpty Dumpty quotation deleted'

What do you think the term 'object" means
in the phrase 'object-oriented programming'?

I don't have a good answer to that. All I can say (and all I care to
say) is that the usual meaning of "object" in the context of
object-oriented programming is different from the definition in the C
standard (C99 3.14):

region of data storage in the execution environment, the contents
of which can represent values

NOTE When referenced, an object may be interpreted as having a
particular type; see 6.3.2.1.

(The note is not part of the definition.)

The C90 definition is more verbose (C90 3.14), but it expresses the
same basic idea:

A region of data storage in the execution environment, the
contents of which can represent values. Except for
bit-fields, objects are composed of contiguous sequences of one or
more bytes, the number, order, and encoding of which are either
explicitly specified or implementation-defined. When referenced,
an object may be interpreted as having a particular type, see
6.2.2

(That may not be an exact quote; my copy of the C90 standard makes
cut-and-paste difficult.)

Are you saying that it is not possible
to write object-oriented programs in C?

No, I'm not saying that, nor have I ever said anything resembling it.
Why do you ask?

Why not say 'region of data storage' instead of object
if that is all that is meant by object?

What I am saying is that the English language is badly abused
in the standards documents.
It converts ordinary English words into meaningless jargon.
These redefinitions narrow the meaning of these words
to the point where it is impossible to make valid inferences
and require the redefinition of other common terms.

No, it converts ordinary English words into meaningful jargon. Any
field of discourse has its own jargon, consisting of ordinary words
with specific definitions, phrases, and, in some cases, invented
words. (The word "object" in everyday English has a meaning that's
not particularly useful in the context of programming languages, for
example.)

If you're going to discuss C, as you insist on doing, you have to
understand the way the C standard defines certain terms. If you're
going to use terms defined in the C standard in ways inconsistent with
their definitions, you're going to have difficulties communicating in
this newsgroup (as you've already discovered).

For example, your redefinition of object appears to require
the redefinition of the term type
to include *all* of the values that could be represented
by the "region of storage" that you call a type.

It's not *my* redefinition, it's in the C standard. Apart from that,
I'm not sure what you mean.

This, in turn, seems to imply that the type depends
upon the representation that the programmer chooses
and that data abstraction is impossible in C.

Nonsense.

Take for example

struct X {
int* p;
};

struct X x;

Does the object referenced through x include
the region of data pointer to by p?

Given the C standard's definition of "object", the object named x
includes the storage for x.p, but it doesn't include the region of
data pointed to by x.p. If you want to refer to both x and the data
pointed to by x.p as a single entity, you should choose a name other
than "object"; I suggest "data structure".

So, can we say a function pointer to be an object ?

[Mabden]

"junky_fellow" <ju**********@yahoo.co.in> wrote in message
news:8c**************************@posting.google.c om...

So, can we say a function pointer to be an object ?

Not in English.

[Keith Thompson]

ju**********@yahoo.co.in (junky_fellow) writes:
[...]

So, can we say a function pointer to be an object ?

Yes. (BTW, please trim any quoted text that's not relevant to your
question.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[E. Robert Tisdale]

junky_fellow wrote:

So, can we say a function pointer to be an object?

A function is an object.
A pointer to that function is another object.

[Joe Wright]

E. Robert Tisdale wrote:

junky_fellow wrote:

So, can we say a function pointer to be an object?

A function is an object.
A pointer to that function is another object.

Pray tell where you find a function described as an object in C.
--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[E. Robert Tisdale]

Joe Wright wrote:

E. Robert Tisdale wrote:

A function is an object.
A pointer to that function is another object.

Pray tell where you find a function described as an object in C.

I used Google

http://www.google.com/

to search for

+"functions are objects" +"C programming"

[Arthur J. O'Dwyer]

On Sat, 14 Aug 2004, E. Robert Tisdale wrote:

E. Robert Tisdale wrote:

A function is an object.
A pointer to that function is another object.

For the record: Functions are /not/ objects in C. However,
pointers are objects, be they pointers to functions or pointers
to data.

(It's been a while since the last blatant troll of Tisdale's,
so I expect we have a crop of newbies who might assume Tisdale
wasn't being maliciously wrong in his statements. FYI, he's a
well-known regular in c.l.c---please just ignore his ravings.)

-Arthur

[Flash Gordon]

On Sat, 14 Aug 2004 13:48:19 -0700
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

junky_fellow wrote:

So, can we say a function pointer to be an object?
A function is an object.

Not according to the C standard according to what the more knowledgeable
people around here have said.
A pointer to that function is another object.

Yes, a pointer to a function is an object.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[E. Robert Tisdale]

Something that calls itself Flash Gordon wrote:

E. Robert Tisdale wrote:

A function is an object.

Not according to the C standard according to what the more knowledgeable
people around here have said.

You are confused.
The C standards documents are *not*
part of the C computer programming language.
There is no 'object' keyword os standard identifier
in the C computer programming language.
The C standards documents have *nothing* to do with programming in C.
They exist *only* to specify the C computer programming language.
Terms, like object, given special meaning in the standards documents
to help with these specifications,
have *no* meaning outside of the scope of the standards documents
other that those meanings commonly used
in the context of a computer programming language.

Questions (remarks) about the C standards are off-topic in comp.lang.c
There is a more appropriate form for that -- comp.std.c

Please direct all your questions (remarks)
about the C standards documents to the appropriate newsgroup.

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

junky_fellow wrote:

So, can we say a function pointer to be an object?
A function is an object.

No, a function is not an object.
A pointer to that function is another object.

Yes.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Joe Wright wrote:

E. Robert Tisdale wrote:

A function is an object.
A pointer to that function is another object.

Pray tell where you find a function described as an object in C.

I used Google

http://www.google.com/

to search for

+"functions are objects" +"C programming"

Did you actually look at the results, or did you just count the hits?
I just got 42 hits, and looked at most of the ones on the first page.
All the ones I checked are pages that state that functions are objects
in some language other than C, and also happen to have the phrase "C
programming".

There may well be some web page that claims that functions are objects
in C. If so, it proves nothing except that the author of the page is
mistaken.

Functions are not objects in C.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
[...]

You are confused.
The C standards documents are *not*
part of the C computer programming language.
The C standards documents define the C programming language.
There is no 'object' keyword os standard identifier
in the C computer programming language.
Nobody has claimed that there is. There is no "function", "array", or
"pointer" keyword or standard identifier in C; do you conclude from
that that C doesn't have functions, arrays, or pointers?
The C standards documents have *nothing* to do with programming in C.
Utter nonsense.
They exist *only* to specify the C computer programming language.
Yes, of course they specify the C programming language. That makes
them extremely relevant to programming in C (and, equally, to
implementing a C compiler and/or library).
Terms, like object, given special meaning in the standards documents
to help with these specifications,
have *no* meaning outside of the scope of the standards documents
other that those meanings commonly used
in the context of a computer programming language.
Utter nonsense.

Given a choice of using terms as defined by the C standard (as is the
nearly universal consensus of this newsgroup), or using terms as
defined by E. Robert Tisdale, it's not a difficult decision.
Questions (remarks) about the C standards are off-topic in comp.lang.c
There is a more appropriate form for that -- comp.std.c
comp.lang.c is for discussion of the C programming language, which is
defined by the C standards. comp.std.c is for discussion of the C
standards *as documents*. "What is an object?" would be an
appropriate question for comp.lang.c; the answer is found in the
standard. "The standard's definition of 'object' is ambiguous" would
be an appropriate topic for comp.std.c. (This is an example, and is
not meant to imply that I think the definition is actually ambiguous.)
Please direct all your questions (remarks)
about the C standards documents to the appropriate newsgroup.

Please stop lying to newbies. Those of us who have been here for a
while know enough not to take you seriously, but inexperienced
programmers might not.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

"E. Robert Tisdale" wrote:

Something that calls itself Flash Gordon wrote:>

E. Robert Tisdale wrote:

A function is an object.

Not according to the C standard according to what the more knowledgeable
people around here have said.

You are confused.
The C standards documents are *not*
part of the C computer programming language.

You are getting objectionable again. The C language is defined by
the C standards documents, at least the only form of C discussed
here.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Flash Gordon]

On Sun, 15 Aug 2004 04:15:33 GMT
Keith Thompson <ks***@mib.org> wrote:

<snip>

Please stop lying to newbies. Those of us who have been here for a
while know enough not to take you seriously, but inexperienced
programmers might not.

I'm not actually a newbie, I just don't have a copy of the standard
myself and don't post very often so I left in that I was relying on what
I had read by those I respect :-)

I slightly morphed the name a while back, but not enough to confuse
anyone who knows me (the domain name did not change). A few years
further back I changed domain but not the name I posted under.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[CBFalconer]

Flash Gordon wrote:

Keith Thompson <ks***@mib.org> wrote:

<snip>

Please stop lying to newbies. Those of us who have been here for
a while know enough not to take you seriously, but inexperienced
programmers might not.

I'm not actually a newbie, I just don't have a copy of the standard
myself and don't post very often so I left in that I was relying on
what I had read by those I respect :-)

He wasn't talking about you, but about ERT, whose foibles are well
known here.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Keith Thompson]

Flash Gordon <sp**@flash-gordon.me.uk> writes:

On Sun, 15 Aug 2004 04:15:33 GMT
Keith Thompson <ks***@mib.org> wrote:

<snip>

Please stop lying to newbies. Those of us who have been here for a
while know enough not to take you seriously, but inexperienced
programmers might not.

I'm not actually a newbie, I just don't have a copy of the standard
myself and don't post very often so I left in that I was relying on what
I had read by those I respect :-)

I slightly morphed the name a while back, but not enough to confuse
anyone who knows me (the domain name did not change). A few years
further back I changed domain but not the name I posted under.

No offense intended. I wasn't referring specifically to you; I hadn't
even noticed that you wrote the article to which ERT was responding.
In effect, everything posted to a newsgroup is addressed to everyone
reading it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

On Sun, 15 Aug 2004 13:35:57 GMT
CBFalconer <cb********@yahoo.com> wrote:

Flash Gordon wrote:

Keith Thompson <ks***@mib.org> wrote:

<snip>

Please stop lying to newbies. Those of us who have been here for
a while know enough not to take you seriously, but inexperienced
programmers might not.

I'm not actually a newbie, I just don't have a copy of the standard
myself and don't post very often so I left in that I was relying on
what I had read by those I respect :-)

He wasn't talking about you, but about ERT, whose foibles are well
known here.

I realised he was talking about ERT lying. My point was that in this
case ERTs drivel was not in response to a newbie but in response to
someone who ahs been around the block a couple of times.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Flash Gordon]

On Sun, 15 Aug 2004 14:20:29 GMT
Keith Thompson <ks***@mib.org> wrote:

Flash Gordon <sp**@flash-gordon.me.uk> writes:
<snip>
No offense intended. I wasn't referring specifically to you; I hadn't
No offence was taken.
even noticed that you wrote the article to which ERT was responding.
In effect, everything posted to a newsgroup is addressed to everyone
reading it.

True.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Default User]

CBFalconer wrote:

You are getting objectionable again. The C language is defined by
the C standards documents, at least the only form of C discussed
here.

What is it about Trollsdale? It seems he can go only so long before
exploding into a bullshit spew all over the newsgroup.


Brian Rodenborn

[junky_fellow]

Keith Thompson <ks***@mib.org> wrote in message news:<ln************@nuthaus.mib.org>...

ju**********@yahoo.co.in (junky_fellow) writes:
[...]

So, can we say a function pointer to be an object ?

Yes. (BTW, please trim any quoted text that's not relevant to your
question.)

Actually, i have some confusion related to null pointer and function
pointer
and C objects.
suppose, i have a function pointer "fptr" , which is pointing to some
funtion that lie at address 0x0.

i have one more pointer "nptr" which is a null pointer.
(NOTE: Assume that machine that i am using use all-bits-zero as null
pointer)
Also, 0x0 is a valid logical address in the address space of my
application.

+-------+
| fptr |------------------+-> +-------------+ 0x00 ( start address of
function)
+-------+ | | |
function pointer | | |
| | |
| . .
| . .
+-------+ | . .
| nptr |------------------+ . .
+-------+ | |
+-------------+
RAM

1) Now, can i say that my function pointer "fptr" is pointing to some
valid C object ?

2) if i compare my null pointer "nptr" with function pointer "fptr"
(for equality ) will they compare equal ?

3) If they compare equal, and fptr is pointing to some valid object,
that means a null pointer may compare equal to some valid object in C.
But, i had in my
mind that null pointer shouldn't compare equal to any valid C object.

i would be highly grateful, if you all expert don't use highly
technical
terms to explain the doubts. otherwise a newbie get entangled in those
terms
and gets more confused.

[Keith Thompson]

ju**********@yahoo.co.in (junky_fellow) writes:

Keith Thompson <ks***@mib.org> wrote in message
news:<ln************@nuthaus.mib.org>...

ju**********@yahoo.co.in (junky_fellow) writes:
[...]

So, can we say a function pointer to be an object ?
Yes. (BTW, please trim any quoted text that's not relevant to your
question.)

Actually, i have some confusion related to null pointer and function
pointer and C objects. suppose, i have a function pointer "fptr" ,
which is pointing to some funtion that lie at address 0x0.

I'll assume that by "0x0" you mean "all-bits-zero". (Keep in mind
that a literal 0x0 in a source program is interpreted as a null
pointer, which may or may not be all-bits-zero. But it's the same
thing on the hypothetical machine you're using, which uses
all-bits-zero as the null pointer.)
i have one more pointer "nptr" which is a null pointer. (NOTE:
Assume that machine that i am using use all-bits-zero as null
pointer) Also, 0x0 is a valid logical address in the address space
of my application.
Function pointers and object pointers are different things; in
particular, you can't legally convert one to the other. In some
implementations, object pointers and function pointers aren't even the
same size. (An implementation could legally implement an object
pointer as a raw machine address, and a function pointer as an integer
index into a table of functions; I don't know of any that actually do
this.)

If there's a function at address all-bits-zero, then the
implementation isn't going to use all-bits-zero as the representation
for a null function pointer. Conversely, if the implementation uses
all-bits-zero as the null pointer representation, it's not going to
allocate a function at that address.
+-------+
| fptr |------------------+-> +-------------+ 0x00 ( start address of
function)
+-------+ | | |
function pointer | | |
| | |
| . .
| . .
+-------+ | . .
| nptr |------------------+ . .
+-------+ | |
+-------------+
RAM

1) Now, can i say that my function pointer "fptr" is pointing to some
valid C object ?
No function pointer points to a valid C object. (A function isn't an
object, remember?)

You've asserted (if I understand you correctly) that fptr points to a
function, that the function is at address all-bits-zero, and that
all-bits-zero is a null pointer. These can't all be true.
2) if i compare my null pointer "nptr" with function pointer "fptr"
(for equality ) will they compare equal ?

3) If they compare equal, and fptr is pointing to some valid object,
that means a null pointer may compare equal to some valid object in
C. But, i had in my mind that null pointer shouldn't compare equal
to any valid C object.

A null pointer is guaranteed to compare unequal to a pointer to any
object or function.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mabden]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
[...]

You are confused.
The C standards documents are *not*
part of the C computer programming language.
The C standards documents define the C programming language.

Yet, my compiler was written in 1994. And my Bible is K&R2.
What part of that involves C99? How can your standards define C programming
for my environment?
Does the American Heritage Dictionary define English for the United Kingdom?

The C standards documents have *nothing* to do with programming in C.

Utter nonsense.

Not really. Don't be a standards snob. Not everyone has access to modren
technology. As you have said in the past, C must encompass many kinds of
hardware, and many years of development.

They exist *only* to specify the C computer programming language.

Yes, of course they specify the C programming language. That makes
them extremely relevant to programming in C (and, equally, to
implementing a C compiler and/or library).

But not EVERY C compiler and / or library.

Terms, like object, given special meaning in the standards documents
to help with these specifications,
have *no* meaning outside of the scope of the standards documents
other that those meanings commonly used
in the context of a computer programming language.

Utter nonsense.

K&R doesn't discuss onjects, that I recall. Please let me know if I missed a
page.
Given a choice of using terms as defined by the C standard (as is the
nearly universal consensus of this newsgroup)

Perhaps, the minority is afeared of the hail storm of hate, were they to
speak up.

Please direct all your questions (remarks)
about the C standards documents to the appropriate newsgroup.

Please stop lying to newbies. Those of us who have been here for a
while know enough not to take you seriously, but inexperienced
programmers might not.

I hope not to be lumped into a similar group. I try to understand the
technical boundaries of C, but I have never read a Standards document. I
have many years of C programming under my belt and feel quite savvy with the
language. But I have had issues with fine technical points. As you may
remember, I have no problem admitting to error if you can convince me you
are correct.
I am not familiar with the general distaste for Mr. E. Robert Tisdale, so I
realize I could be making a mistake by agreeing with some of his points, but
if that is all it takes to be dismissed on this newsgroup then you should
all be ashamed of yourselves.
Also, I don't prefer the term "lying" when one is stating an opinion. Surely
an opinion is just that, and not a lie. I found you, Keith, to be quite
tolerant in our other discussion, and would prefer to see you keep the same
detachment regardless of the poster.

--
Mabden

[Mabden]

"CBFalconer" <cb********@yahoo.com> wrote in message
news:41**************@yahoo.com...

You are getting objectionable again. The C language is defined by
the C standards documents, at least the only form of C discussed
here.

I hope not!
I have no such document and I wish to post here. I have written C code for
over 15 years. Are you excluding me?

--
Mabden

[junky_fellow]

Keith Thompson <ks***@mib.org> wrote in message news:<ln************@nuthaus.mib.org>...

ju**********@yahoo.co.in (junky_fellow) writes:

Keith Thompson <ks***@mib.org> wrote in message
news:<ln************@nuthaus.mib.org>...

ju**********@yahoo.co.in (junky_fellow) writes:
[...]
> So, can we say a function pointer to be an object ?

thanx a lot. you were indeed very precise and helpful.

[Flash Gordon]

On Mon, 16 Aug 2004 10:29:29 GMT
"Mabden" <mabden@sbc_global.net> wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
[...]

You are confused.
The C standards documents are *not*
part of the C computer programming language.
The C standards documents define the C programming language.

Yet, my compiler was written in 1994. And my Bible is K&R2.
What part of that involves C99? How can your standards define C
programming for my environment?

It is defined by the old C89 standard which it almost certainly
references somewhere in the documentation.
Does the American Heritage Dictionary define English for the United
Kingdom?

Completely irrelevant. There is no English Standard, although there is
standard English and standard American.

The C standards documents have *nothing* to do with programming in
C.

Utter nonsense.

Not really. Don't be a standards snob. Not everyone has access to
modren technology. As you have said in the past, C must encompass many
kinds of hardware, and many years of development.

As a programmer on multiple different systems, and one with significant
embedded experience, I find the C standard to be extremely relevant. It
saves me from having to learn a new language for every architecture.

They exist *only* to specify the C computer programming language.

Yes, of course they specify the C programming language. That makes
them extremely relevant to programming in C (and, equally, to
implementing a C compiler and/or library).

But not EVERY C compiler and / or library.

Yes, every C compiler, every implementation of the standard C library,
and every implementation of a library written in C.

Terms, like object, given special meaning in the standards
documents to help with these specifications,
have *no* meaning outside of the scope of the standards documents
other that those meanings commonly used
in the context of a computer programming language.

Utter nonsense.

K&R doesn't discuss onjects, that I recall. Please let me know if I
missed a page.

Try looking up object in the index. It has two entries the second of
which is P196, section A5 Objects and Lvalues.

<snip>

For technical discussions it is useful to have rigid definitions of the
terms so that people know exactly what they are talking about. C is
defined by a standard and therefor it makes sense to use the technical
terms as defined in the standard. To facilitate discussions those
regulars with copies of the standard have shown themselves to be willing
to provide appropriate quotes from it so that the rest of us can see
what these definitions are, something which I appreciate. I especially
appreciate it when they point out mistakes in my posts as this makes me
a better developer.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Flash Gordon]

On Mon, 16 Aug 2004 10:31:52 GMT
"Mabden" <mabden@sbc_global.net> wrote:

"CBFalconer" <cb********@yahoo.com> wrote in message
news:41**************@yahoo.com...

You are getting objectionable again. The C language is defined by
the C standards documents, at least the only form of C discussed
here.

I hope not!
I have no such document and I wish to post here. I have written C code
for over 15 years. Are you excluding me?

Not having the C standard does not exclude you. After all, how many
comments have you seen telling me to stop posting? It is refusing to
accept that C is as defined by the standards and that it is C rather
than extensions that we discuss here.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[CBFalconer]

Mabden wrote:

"CBFalconer" <cb********@yahoo.com> wrote in message

You are getting objectionable again. The C language is defined by
the C standards documents, at least the only form of C discussed
here.

I hope not!
I have no such document and I wish to post here. I have written C
code for over 15 years. Are you excluding me?

You have no reason not to have the document. A suitable version
is available free (see sig). This group, by mutual consent,
loosely limits its discussions to things that can be traced to the
standard and its predecessors. This tends to ensure that advice
etc. is universally applicable.

--
Some useful references:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> C-library

[Keith Thompson]

"Mabden" <mabden@sbc_global.net> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
[...]

You are confused.
The C standards documents are *not*
part of the C computer programming language.
The C standards documents define the C programming language.

Yet, my compiler was written in 1994. And my Bible is K&R2.
What part of that involves C99? How can your standards define C
programming for my environment? Does the American Heritage
Dictionary define English for the United Kingdom?

The C standards documents have *nothing* to do with programming in C.

Utter nonsense.

Not really. Don't be a standards snob. Not everyone has access to modren
technology. As you have said in the past, C must encompass many kinds of
hardware, and many years of development.

Yes, really.

Note that I wrote "C standards", plural. The latest standard is ISO
C99, but the ISO C90 standard (or, equivalently, the ANSI C89
standard) is still widely used.

If your compiler was written in 1994, its authors almost certainly
spent a great deal of time making sure it conforms to the C89 or C90
standard as closely as possible. If they didn't, they certainly
should have.

If you'll look at the front cover of your "Bible", K&R2, you'll
probably find a statement that it's based on the ANSI standard.

Most programmers probably don't need a copy of the standard (though in
my opinion they'd benefit from it). You can certainly learn C from a
decent textbook. But every decent textbook out there was written by
someone who *has* read the standard, and in many cases, actually
helped write it.

If a statement in a textbook disagrees with the standard, the
textbook, not the standard, is in error (except in cases where the
standard is internally inconsistent or doesn't correctly express the
intent). That even applies to K&R2. See
<http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>.

They exist *only* to specify the C computer programming language.

Yes, of course they specify the C programming language. That makes
them extremely relevant to programming in C (and, equally, to
implementing a C compiler and/or library).

But not EVERY C compiler and / or library.

Yes, EVERY C compiler and/or library. Any C compiler or library that
violates the standard (whichever version of the standard it claims to
conform to) is broken. I doubt that you'll find an implementer of a C
compiler or library who disagrees with this.

Many implementations, of course, provide extensions not defined by the
standard. Most such implementations provide a mode in which they
conform as closely as possible to the standard without extensions,
such as gcc's "-ansi -pedantic -W -Wall" or "-std=c99 -pedantic -W -Wall"
mode.

By "library", I mean an implementation of the C standard library.
There are plenty of libraries that implement extensions (POSIX is one
example); this is permitted by the standard itself, as long as the
extensions don't violate the standard.

Terms, like object, given special meaning in the standards documents
to help with these specifications,
have *no* meaning outside of the scope of the standards documents
other that those meanings commonly used
in the context of a computer programming language.

Utter nonsense.

K&R doesn't discuss onjects, that I recall. Please let me know if I missed a
page.

I don't have my copy handy, but I believe you did.

Given a choice of using terms as defined by the C standard (as is the
nearly universal consensus of this newsgroup)

Perhaps, the minority is afeared of the hail storm of hate, were they to
speak up.

Speak up about what?

The narrow issue that led to this discussion was the meaning of the
word "object". In plain English, it refers to a number of things that
are clearly outside the scope of this newsgroup, such as the coffee
mug sitting to my right. If we're going to use the term "object" in
this newsgroup, I suggest that we should use it in the sense defined
by the C standard. Someone who insists on using some other esoteric
definition of "object" (such as one that includes functions) is not
taking a brave stand against the tyranny of the majority; he's merely
sowing confusion.

Misusing a term out of temporary ignorance is a very different thing.
Everyone makes mistakes, and most of us here are willing to just point
out an error and move on. What annoys us is someone who persistently
misuses a term in the face of clear evidence that he's wrong.

Please direct all your questions (remarks)
about the C standards documents to the appropriate newsgroup.

Please stop lying to newbies. Those of us who have been here for a
while know enough not to take you seriously, but inexperienced
programmers might not.

I hope not to be lumped into a similar group. I try to understand the
technical boundaries of C, but I have never read a Standards document. I
have many years of C programming under my belt and feel quite savvy with the
language. But I have had issues with fine technical points. As you may
remember, I have no problem admitting to error if you can convince me you
are correct.
I am not familiar with the general distaste for Mr. E. Robert Tisdale, so I
realize I could be making a mistake by agreeing with some of his points, but
if that is all it takes to be dismissed on this newsgroup then you should
all be ashamed of yourselves.

ERT does make correct statements at times, and I for one have
sometimes gone out of my way to acknowledge that fact. (I admit I've
done so with a sense if irony, implying that a correct statement from
ERT is an unusual occurrence.) But he has frequently, loudly, and
persistently maintained that *his* views of what the C programming
language is all about are correct and the standard is irrelevant. We
probably overreact to him at times (which I suspect is exactly what he
wants), but it's important to refute his nonsense.
Also, I don't prefer the term "lying" when one is stating an
opinion. Surely an opinion is just that, and not a lie. I found you,
Keith, to be quite tolerant in our other discussion, and would
prefer to see you keep the same detachment regardless of the poster.

That's not a bad point. ERT is so persistently wrong, so impervious
to reason, and so skilled at starting and continuing tedious
arguments, that it's difficult to believe that all his mistakes are
honest ones, but I admit it's possible.

I'll amend my previous request; rather than "Please stop lying to
newbies.", I probably should have written "Please stop misleading
newbies."

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[E. Robert Tisdale]

Keith Thompson wrote:

I probably should have written "Please stop misleading newbies."

Aren't you being just a little disingenuous?
I don't recall that you have ever cited the standards documents
to help new subscribers answer their questions about programming in C.
You use it as a weapon to cut off legitimate discussion
as you did in this case.
I don't think that the original poster, "junky_fellow",
had the slightest interest in how the term 'object'
was used in the C standards documents.

Your remarks seem to imply that the C standards documents
are the *only* legitimate source of information about C programming,
that every other source of information about C programming is irrelevant
and that the standards documents are unimpeachable.

I don't share your fanaticism.
The C programming language encompasses a wider world
than your copy of the C standards documents.

[Alan Balmer]

On Mon, 16 Aug 2004 10:29:29 GMT, "Mabden" <mabden@sbc_global.net>
wrote:

K&R doesn't discuss onjects, that I recall. Please let me know if I missed a
page.

You missed two. Pages 195 and 197.

(Assuming you really meant "object.")

--
Al Balmer
Balmer Consulting
re************************@att.net

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Keith Thompson wrote:

I probably should have written "Please stop misleading newbies."
Aren't you being just a little disingenuous?

Nope.
I don't recall that you have ever cited the standards documents
to help new subscribers answer their questions about programming in C.
I've cited the standards documents here numerous times. I'm not sure
whether I've ever done so "to help new subscribers".

What I don't do is post information that's blatantly inconsistent with
the standard, or make up confusing definitions of words.

Several articles upthread, you specifically said that "A function is
an object." It isn't, for reasons we've already discussed. I cited
the standard to refute your false statement.

[...]
You use it as a weapon to cut off legitimate discussion
as you did in this case.
I use it to correct errors.
I don't think that the original poster, "junky_fellow",
had the slightest interest in how the term 'object'
was used in the C standards documents.
Maybe he does, maybe he doesn't. In my opinion, he should.
Your remarks seem to imply that the C standards documents
are the *only* legitimate source of information about C programming,
that every other source of information about C programming is irrelevant
and that the standards documents are unimpeachable.
Not at all. The C standards define the language. Other documents
describe the language defined by the standard. There are numerous
legitimate sources of information about C programming; the standard is
the most definitive source. There are errors in the standards, but
I'm not aware of any related to the meaning of the word "object".
I don't share your fanaticism.
The C programming language encompasses a wider world
than your copy of the C standards documents.

I've just looked up the word "object" in the indexes of K&R2 and H&S5
(that's Harbison & Steele, 5th edition). Both define the term in a
manner consistent with the definition in the standard; both make it
clear that a function is not an object. The only support I've seen
for your assertion that a function is an object was a Google search
that, as it turned out, didn't support your point.

I chose to use the standard to disprove your statement that a function
is an object, but I could have used any of a number of other sources.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[junky_fellow]

ju**********@yahoo.co.in (junky_fellow) wrote in message news:<8c**************************@posting.google. com>...

Keith Thompson <ks***@mib.org> wrote in message news:<ln************@nuthaus.mib.org>...

ju**********@yahoo.co.in (junky_fellow) writes:

Keith Thompson <ks***@mib.org> wrote in message
news:<ln************@nuthaus.mib.org>...
> ju**********@yahoo.co.in (junky_fellow) writes:
> [...]
> > So, can we say a function pointer to be an object ?

thanx a lot. you were indeed very precise and helpful.

One more question, if in the linker command i ask the linker to put
a particular function at address all-bits-zero, then the null pointer
and function pointer may compare equal.

[Keith Thompson]

ju**********@yahoo.co.in (junky_fellow) writes:
[...]

One more question, if in the linker command i ask the linker to put
a particular function at address all-bits-zero, then the null pointer
and function pointer may compare equal.

<ANNOYINGLY_PEDANTIC>
Sounds more like a statement than a question.
</ANNOYINGLY_PEDANTIC>

I'm not very familiar with linker options (which are system-specific
in any case). I suppose a linker might allow you to specify the
address of a function. If you specify address zero, I suppose the
function's address could be equal to the null pointer.

But I'd say that's outside the scope of the standard. If you can
interfere with the implementation like that, it's quite possible you
can force the implementation to violate the standard.

Many C implementations are non-conforming by default, providing a
standard-conforming mode only if you specify certain options.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[E. Robert Tisdale]

junky_fellow wrote:

If in the linker command,
I ask the linker to put a particular function at address all-bits-zero,
then the null pointer and function pointer may compare equal.

If your link editor allowed you to put a function (or data) at address

0x0000000000000000

Your implementation (your C compiler) would probably be obliged to use
something besides all-bits-zero for the null pointer.

I believe that, currently, *all* viable C compilers
use all-bits-zero for NULL
so this is something that you don't need to worry about.

[Mabden]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes: [snip] Not at all. The C standards define the language. Other documents
describe the language defined by the standard. There are numerous
legitimate sources of information about C programming; the standard is
the most definitive source. There are errors in the standards, but
I'm not aware of any related to the meaning of the word "object".

I don't share your fanaticism.
The C programming language encompasses a wider world
than your copy of the C standards documents.

I've just looked up the word "object" in the indexes of K&R2 and H&S5
(that's Harbison & Steele, 5th edition). Both define the term in a
manner consistent with the definition in the standard; both make it
clear that a function is not an object. The only support I've seen
for your assertion that a function is an object was a Google search
that, as it turned out, didn't support your point.

I chose to use the standard to disprove your statement that a function
is an object, but I could have used any of a number of other sources.

I think the term "object" has changed meanings since C++ came about. In K&R,
it seems to me that almost any memory location can be called an "object". In
such a case, a pointer is an object and a function name, like an array name,
can be distilled down to be called an object.

Does Appendix K&R2 A7.1 not hint at this?

Just asking...
--
Mabden

[Mabden]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cf**********@nntp1.jpl.nasa.gov...

junky_fellow wrote:

If in the linker command,
I ask the linker to put a particular function at address all-bits-zero,
then the null pointer and function pointer may compare equal.

If your link editor allowed you to put a function (or data) at address

0x0000000000000000

Your implementation (your C compiler) would probably be obliged to use
something besides all-bits-zero for the null pointer.

I believe that, currently, *all* viable C compilers
use all-bits-zero for NULL
so this is something that you don't need to worry about.

Hehe, I said it first!

But I am assured this is not the case! You may NOT use the word "ALL".

--
Mabden

[Flash Gordon]

On Tue, 17 Aug 2004 10:20:02 GMT
"Mabden" <mabden@sbc_global.net> wrote:

<snip>

I think the term "object" has changed meanings since C++ came about.
Not for C it hasn't, since C is defined by the C standards and C++ is
defined by the C++ standards.
In K&R, it seems to me that almost any memory location can be called
an "object".
No, K&R in section A.5 (which I am sure I've mentioned elsewhere in this
thread) says "An /object/ is a named region of storage;". Since a
function is not a region of storage it cannot be an object. Others have
quoted the relevant parts of the standard which define an object (and
which take precedence of K&R) which say similar things.
In such a case, a pointer is an object
The region of storage in which the pointer is stored is an object.
and a function
name, like an array name, can be distilled down to be called an
object.
No.
Does Appendix K&R2 A7.1 not hint at this?
No, since it does not say the function is a region of storage.
Just asking...

It's been answered already several times. A function is NOT an object
in C.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Mabden]

"Mabden" <mabden@sbc_global.net> wrote in message
news:mZ*****************@newssvr27.news.prodigy.co m...

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes: [snip]

Not at all. The C standards define the language. Other documents
describe the language defined by the standard. There are numerous
legitimate sources of information about C programming; the standard is
the most definitive source. There are errors in the standards, but
I'm not aware of any related to the meaning of the word "object".

I don't share your fanaticism.
The C programming language encompasses a wider world
than your copy of the C standards documents.

I've just looked up the word "object" in the indexes of K&R2 and H&S5
(that's Harbison & Steele, 5th edition). Both define the term in a
manner consistent with the definition in the standard; both make it
clear that a function is not an object. The only support I've seen
for your assertion that a function is an object was a Google search
that, as it turned out, didn't support your point.

I chose to use the standard to disprove your statement that a function
is an object, but I could have used any of a number of other sources.

I think the term "object" has changed meanings since C++ came about. In

K&R, it seems to me that almost any memory location can be called an "object". In such a case, a pointer is an object and a function name, like an array name, can be distilled down to be called an object.

Does Appendix K&R2 A7.1 not hint at this?

More clarification:
A4. "An object... its interpretation depends on two main attributes: its
storage class and its type."
A4.3 "Besides the basic types, there is a conceptually infinite class of
derived types constructed from the fundamental types in the following ways:"
"functions returning objects of a given type".
"In general these methods of constructing objects can be applied
recursively."

I do admit that the text tends to talk about "objects and functions", so the
authors do seem to lump them together, yet keep them distinct.

So [OT] what is a function in today's OOP world? Is it an object or just a
thing called a function? Any C++ gurus know the answer to that?

--
Mabden

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

Note that I wrote "C standards", plural. The latest standard is ISO
C99, but the ISO C90 standard (or, equivalently, the ANSI C89
standard) is still widely used.
Actually, C89/C90 is the only standard widely used. Conforming C99
implementations are few and far between.
Many implementations, of course, provide extensions not defined by the
standard.
Or, as is the case with gcc, deliberate deviations from the standard.
Most such implementations provide a mode in which they
conform as closely as possible to the standard without extensions,
such as gcc's "-ansi -pedantic -W -Wall" or "-std=c99 -pedantic -W -Wall"
mode.
You're confused/confusing here. First, the -W and -Wall options have
absolutely nothing to do with standard conformance: they enable *only*
diagnostics that are NOT required by any C standard. gcc has only one
standard conforming mode and this is enabled using -ansi -pedantic, or,
equivalently, -std=c89 -pedantic (I'm deliberately ignoring the option
for C94 conformance, to keep things as simple as possible). -ansi
disables gcc's deviations from the standard and -pedantic enables some
required diagnostics that gcc doesn't generate by default.

gcc doesn't have a C99 conforming mode, so all you can get from -std=c99
is a compiler that doesn't conform to any known C standard. You may know
this, but other people may not, so any reference to gcc's -std=c99 option
should be properly qualified.
By "library", I mean an implementation of the C standard library.
There are plenty of libraries that implement extensions (POSIX is one
example); this is permitted by the standard itself, as long as the
extensions don't violate the standard.

Which, basically, means that, when invoked in standard conforming mode,
the preprocessor must somehow exclude all the extensions from the standard
headers, unless their associated identifiers are in the implementation
name space. So, if you need such extensions, e.g. fileno() from <stdio.h>
don't invoke the compiler in standard conforming mode.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

[...]

Most such implementations provide a mode in which they
conform as closely as possible to the standard without extensions,
such as gcc's "-ansi -pedantic -W -Wall" or "-std=c99 -pedantic -W -Wall"
mode.

You're confused/confusing here. First, the -W and -Wall options have
absolutely nothing to do with standard conformance: they enable *only*
diagnostics that are NOT required by any C standard. gcc has only one
standard conforming mode and this is enabled using -ansi -pedantic, or,
equivalently, -std=c89 -pedantic (I'm deliberately ignoring the option
for C94 conformance, to keep things as simple as possible). -ansi
disables gcc's deviations from the standard and -pedantic enables some
required diagnostics that gcc doesn't generate by default.

I had assumed that "-W -Wall" enabled some required diagnostics, but
if you say "-ansi -pedantic" suffices, I'll take your word for it.

(Using "-W -Wall" as well is generally a good idea, but that's not
necessarily related to conformance.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[E. Robert Tisdale]

Mabden wrote:

E. Robert Tisdale wrote:

I believe that, currently, *all* viable C compilers
use all-bits-zero for NULL
so this is something that you don't need to worry about.

But I am assured this is not the case! You may NOT use the word "ALL".

Please cite an example of a standard conforming C compiler
that does *not* use all-bits-zero for NULL.

[CBFalconer]

"E. Robert Tisdale" wrote:

Mabden wrote:

E. Robert Tisdale wrote:

I believe that, currently, *all* viable C compilers
use all-bits-zero for NULL
so this is something that you don't need to worry about.

But I am assured this is not the case! You may NOT use the
word "ALL".

Please cite an example of a standard conforming C compiler
that does *not* use all-bits-zero for NULL.

Any one for the 8086/8 in normal segmented mode. Writing to the
interrupt vector table is considered poor technique.

Now please cease the trolling.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

"E. Robert Tisdale" wrote:

Mabden wrote:

E. Robert Tisdale wrote:

I believe that, currently, *all* viable C compilers
use all-bits-zero for NULL
so this is something that you don't need to worry about.

But I am assured this is not the case! You may NOT use the
word "ALL".

Please cite an example of a standard conforming C compiler
that does *not* use all-bits-zero for NULL.

Any one for the 8086/8 in normal segmented mode. Writing to the
interrupt vector table is considered poor technique.

How would using all-bits-zero for null pointers result in writing to
the interrupt vector table? Are you saying that code that
*accidentally* attempts to write through a null pointer will clobber
the interrupt vector table, thus messing up the system rather than
just crashing the offending program? (I'm not familiar with the
systems in question.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ben Pfaff]

CBFalconer <cb********@yahoo.com> writes:

"E. Robert Tisdale" wrote:

Please cite an example of a standard conforming C compiler
that does *not* use all-bits-zero for NULL.

Any one for the 8086/8 in normal segmented mode. Writing to the
interrupt vector table is considered poor technique.

Every MS-DOS compiler I used had null pointers as all-bits-zero.
What did yours use, and which compiler was it?
--
Here's a tip: null pointers don't have to be *dull* pointers!

[RCollins]

CBFalconer wrote:

"E. Robert Tisdale" wrote:

Mabden wrote:

E. Robert Tisdale wrote:
I believe that, currently, *all* viable C compilers
use all-bits-zero for NULL
so this is something that you don't need to worry about.

But I am assured this is not the case! You may NOT use the
word "ALL".

Please cite an example of a standard conforming C compiler
that does *not* use all-bits-zero for NULL.

Any one for the 8086/8 in normal segmented mode. Writing to the
interrupt vector table is considered poor technique.

Now please cease the trolling.

Trolling or not, it's a good question. Just because 0:0 was an
interrupt table, doesn't mean the common C compilers of the day
used a different NULL constant.

So, just off hand, does anyone remember what NULL was defined to
be on any of those compilers: Turbo C, Power C, etc?

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[Ben Pfaff]

Keith Thompson <ks***@mib.org> writes:

CBFalconer <cb********@yahoo.com> writes:

"E. Robert Tisdale" wrote:

> Please cite an example of a standard conforming C compiler
> that does *not* use all-bits-zero for NULL.
Any one for the 8086/8 in normal segmented mode. Writing to the
interrupt vector table is considered poor technique.

How would using all-bits-zero for null pointers result in writing to
the interrupt vector table?

In real mode on an x86, the interrupt table is at the bottom of
physical memory. Real mode has a 1:1 mapping from virtual to
physical addresses, so writing through a null pointer will indeed
modify the interrupt vector table.
Are you saying that code that *accidentally* attempts to write
through a null pointer will clobber the interrupt vector table,
thus messing up the system rather than just crashing the
offending program? (I'm not familiar with the systems in
question.)

It's actually worse than that. The first few interrupts in the
table aren't all that important (e.g. the first one is the
"divide by zero" exception vector), so it's possible that writing
to a null pointer won't even mess up the system *quickly*.
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.edu> writes:

Keith Thompson <ks***@mib.org> writes:

CBFalconer <cb********@yahoo.com> writes:

"E. Robert Tisdale" wrote:
> Please cite an example of a standard conforming C compiler
> that does *not* use all-bits-zero for NULL.

Any one for the 8086/8 in normal segmented mode. Writing to the
interrupt vector table is considered poor technique.

How would using all-bits-zero for null pointers result in writing to
the interrupt vector table?

In real mode on an x86, the interrupt table is at the bottom of
physical memory. Real mode has a 1:1 mapping from virtual to
physical addresses, so writing through a null pointer will indeed
modify the interrupt vector table.

Are you saying that code that *accidentally* attempts to write
through a null pointer will clobber the interrupt vector table,
thus messing up the system rather than just crashing the
offending program? (I'm not familiar with the systems in
question.)

It's actually worse than that. The first few interrupts in the
table aren't all that important (e.g. the first one is the
"divide by zero" exception vector), so it's possible that writing
to a null pointer won't even mess up the system *quickly*.

So using a non-all-bits-zero value for the null pointer (on the system
in question) is a mechanism for defending the system against buggy
code. Cool.

(Of course, if somebody uses memset() to set a pointer to
all-bits-zero, assuming that it's a null pointer, and then
accidentally writes through it, it's going to clobber the system
anyway. Presumably anyone who would do such a thing won't be allowed
anywhere near the system.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[RCollins]

Keith Thompson wrote:

Ben Pfaff <bl*@cs.stanford.edu> writes:

Keith Thompson <ks***@mib.org> writes:

CBFalconer <cb********@yahoo.com> writes:

"E. Robert Tisdale" wrote:

>Please cite an example of a standard conforming C compiler
>that does *not* use all-bits-zero for NULL.

Any one for the 8086/8 in normal segmented mode. Writing to the
interrupt vector table is considered poor technique.

How would using all-bits-zero for null pointers result in writing to
the interrupt vector table?

In real mode on an x86, the interrupt table is at the bottom of
physical memory. Real mode has a 1:1 mapping from virtual to
physical addresses, so writing through a null pointer will indeed
modify the interrupt vector table.

Are you saying that code that *accidentally* attempts to write
through a null pointer will clobber the interrupt vector table,
thus messing up the system rather than just crashing the
offending program? (I'm not familiar with the systems in
question.)

It's actually worse than that. The first few interrupts in the
table aren't all that important (e.g. the first one is the
"divide by zero" exception vector), so it's possible that writing
to a null pointer won't even mess up the system *quickly*.

So using a non-all-bits-zero value for the null pointer (on the system
in question) is a mechanism for defending the system against buggy
code. Cool.

(Of course, if somebody uses memset() to set a pointer to
all-bits-zero, assuming that it's a null pointer, and then
accidentally writes through it, it's going to clobber the system
anyway. Presumably anyone who would do such a thing won't be allowed
anywhere near the system.)

There are millions of ways to clobber a system ... writing to an
invalid memory address is just one of them.

Who would do such a thing? Well, (need I say it?), none of us are
perfect, I'm sure we've all made our share of bone-headed errors.
(That weekend in Tiajuana ... well, never mind).

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.com> writes:

"E. Robert Tisdale" wrote:
.... snip ...

Please cite an example of a standard conforming C compiler
that does *not* use all-bits-zero for NULL.

Any one for the 8086/8 in normal segmented mode. Writing to the
interrupt vector table is considered poor technique.

How would using all-bits-zero for null pointers result in writing to
the interrupt vector table? Are you saying that code that
*accidentally* attempts to write through a null pointer will clobber
the interrupt vector table, thus messing up the system rather than
just crashing the offending program? (I'm not familiar with the
systems in question.)

The pointers consist of seg:offset, combined as 16*seg+offset =
address in the 0 to 1 meg range. If those are all 0's the result
is absolute address 0, which is where the int 0 interrupt vector
resides. There is no memory protection whatsoever in '86 or '186,
nor, I believe, in the x86 at boot time, when they come up in real
mode.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?