C objects

[Keith Thompson]

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.

 

[Mabden]

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?

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, 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.

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 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]

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?

 

[junky_fellow]

(e-mail address removed) (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]

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.

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.

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.

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]

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.

 

[CBFalconer]

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]

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?


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

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.

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.

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.

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."

 

[E. Robert Tisdale]

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]

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.")

 

[Keith Thompson]

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.

 

[junky_fellow]

(e-mail address removed) (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]

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.

 

[E. Robert Tisdale]

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]

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'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]

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".

 

[Flash Gordon]

On Tue, 17 Aug 2004 10:20:02 GMT

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.

 

[Mabden]

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?

 

[Dan Pop]

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

 

[Keith Thompson]

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.)