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

[CBFalconer]

Ben Pfaff wrote:

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?

I _never_ write through a NULL pointer :-) It might be an
experiment to get Borlands TC from the museum and run it through
some experiments on pure MsDOS. I expect int0 will be affected.
A virtual MsDos on W98 won't do.

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

[Dan Pop]

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

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.

You don't have to, it's well documented in the gcc man page.
(Using "-W -Wall" as well is generally a good idea, but that's not
necessarily related to conformance.)

It is -Wall -O that is a good idea. -Wall fails to identify the usage
of uninitialised variables if optimisation is not turned on and -W
generates objectionable warnings (that's why its functionality was
not included into -Wall in the first place).

-W is fine for experienced people who understand the underlying issues
and agree with them. Its diagnostics, however, could be confusing
to newbies and lead them to break perfectly good code, in order to
shut them up.

I wouldn't recommend -W to newbies or to anyone else who doesn't have a
clear understanding of its effects (and those who do, don't need anyone
else's recommendations in order to decide whether to use it or not).

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

[Joe Wright]

CBFalconer wrote:

Ben Pfaff wrote:

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?

I _never_ write through a NULL pointer :-) It might be an
experiment to get Borlands TC from the museum and run it through
some experiments on pure MsDOS. I expect int0 will be affected.
A virtual MsDos on W98 won't do.

I have not snipped anything from Chuck's post. I fear we are
wandering off point if not off topic. In no particular order I offer
various considerations for the null pointer value being zero.

1. It is useful to have functions return an error indication if the
function fails. Consider malloc(). It returns the address of
allocated memory if it succeeds. What shall we have it do if there
is no memory available? Return a value which cannot be a valid address.

2. Given an address, perhaps stored in a pointer, how might we
examine it to determine its validity? Sadly, we can't. C programmers
see pointer values as unsigned integers with no upper bound.

So, if we need a single pointer value within the domains of unsigned
integers of various widths, we are limited to the lower bound, 0.

This is not a bad choice. Usually 0 is an important address to the
underlying OS and we shouldn't write to it in any case. Reserving
address 0 for our NULL pointer constant is perfect. We are warned
that writing or even reading address zero might cause your house to
burn down, and so we don't do it.

Tell me why any C implementation would have a null pointer other
than zero? So that writing through NULL might be safer? Nonsense.
Writing through NULL is the ultimate sin. So why?

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

Joe Wright <jo********@comcast.net> writes:
[...]

Tell me why any C implementation would have a null pointer other than
zero? So that writing through NULL might be safer? Nonsense. Writing
through NULL is the ultimate sin. So why?

In a typical system, there are huge numbers of invalid pointer values;
the null pointer is only of them. But since it's easy to generate a
null pointer in a C program, a given invalid pointer is more likely to
have the value null than any other value. Therefore, a buggy program
that writes through an invalid pointer is more likely to write through
a null pointer than through any other invalid pointer value. If the
system happens to have world-writable critical data at address
all-bits-zero, such that a buggy program can damage the system by
clobbering it, can be made somewhat more secure by using a value other
than all-bits-zero as a null pointer.

Of course, bug-free programs aren't affected by this -- which is fine
if you only run bug-free programs on your system. (The best way to do
that is to pull the power plug.)

If reading or writing through address all-bits-zero is guaranteed to
cause a trap that affects the offending program, then all-bits-zero is
probably an excellent value for the null pointer. But if the
all-bits-zero address doesn't trap (say, because there's real memory
there), and some other address does (say, because it points to memory
that doesn't exist), then the trapping value is probably a better choice.

Many years ago, I worked on a 68K-based system programmed in Pascal
(no C compiler). It used the value 1 for the nil pointer because an
attempt to deference an odd address would cause a trap. (Of course,
Pascal doesn't have all the confusion caused by C's use of a literal 0
to represent a null pointer; it just uses the "nil" keyword.)

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

Joe Wright wrote:

.... snip ...
So, if we need a single pointer value within the domains of unsigned
integers of various widths, we are limited to the lower bound, 0.
not so, see below.
This is not a bad choice. Usually 0 is an important address to the
underlying OS and we shouldn't write to it in any case. Reserving
address 0 for our NULL pointer constant is perfect. We are warned
that writing or even reading address zero might cause your house to
burn down, and so we don't do it.

Tell me why any C implementation would have a null pointer other
than zero? So that writing through NULL might be safer? Nonsense.
Writing through NULL is the ultimate sin. So why?

I remember one system that used the value 1 for the NULL pointer.
Conceded, it was not a C system, however the same reasons apply.
I forget the details, but it was essential in the architecture.

Using any such value is perfectly possible, it is only necessary
that the system never assign that space to anything, including
statics, automatics, malloced, and even code (which may be needed
for constants and/or immediate addressing instructions).

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

[CBFalconer]

Keith Thompson wrote:

.... snip ...
Of course, bug-free programs aren't affected by this -- which is fine
if you only run bug-free programs on your system. (The best way to do
that is to pull the power plug.)
Doesn't work on most laptops. .... snip ...
Many years ago, I worked on a 68K-based system programmed in Pascal
(no C compiler). It used the value 1 for the nil pointer because an
attempt to deference an odd address would cause a trap. (Of course,
Pascal doesn't have all the confusion caused by C's use of a literal 0
to represent a null pointer; it just uses the "nil" keyword.)

That was UCSD Pascal, which is not representative.

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

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

Keith Thompson wrote:

[...]

Many years ago, I worked on a 68K-based system programmed in Pascal
(no C compiler). It used the value 1 for the nil pointer because an
attempt to deference an odd address would cause a trap. (Of course,
Pascal doesn't have all the confusion caused by C's use of a literal 0
to represent a null pointer; it just uses the "nil" keyword.)

That was UCSD Pascal, which is not representative.

(Actually it was a derivative of UCSD Pascal.)

Not representative of what?

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

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

Keith Thompson wrote:

... snip ...

Of course, bug-free programs aren't affected by this -- which is fine
if you only run bug-free programs on your system. (The best way to do
that is to pull the power plug.)

Doesn't work on most laptops.

... snip ...

Many years ago, I worked on a 68K-based system programmed in Pascal
(no C compiler). It used the value 1 for the nil pointer because an
attempt to deference an odd address would cause a trap. (Of course,
Pascal doesn't have all the confusion caused by C's use of a literal 0
to represent a null pointer; it just uses the "nil" keyword.)

That was UCSD Pascal, which is not representative.

on 68k processor, i think at location all-bits-zero there lies
"initial stack pointer" which is used only at boot time.
Similarly, on PowerPC 8260, there lie HRCW (Hard Reset Configuration
Word) at location all-bits-zero which is only used at boot time.

So, writing at null-pointer won't harm the running system , i suppose.
i am a newbie so i maybe wrong as well.

My doubt is that, since we have placed something valid "HRCW in case
of PowerPC" (take the example of an embedded system, where application
has been linked with kernel ) at location all-bits-zero, so isn't it
possible that null pointer may compare equal (because we have some
valid object
at location all-bits-zero).
This may sound very illogical or absurd to the experts, but
this is the picture that i have in my mind.

[Flash Gordon]

On 19 Aug 2004 04:08:07 -0700
ju**********@yahoo.co.in (junky_fellow) wrote:

<snip>

My doubt is that, since we have placed something valid "HRCW in case
of PowerPC" (take the example of an embedded system, where application
has been linked with kernel ) at location all-bits-zero, so isn't it
possible that null pointer may compare equal (because we have some
valid object
at location all-bits-zero).
This may sound very illogical or absurd to the experts, but
this is the picture that i have in my mind.

I'm not completely sure of your meaning, so I'll go through all the
interpretations I can think of.

1) If the implementation might place an object (i.e. a variable or
malloced region) at location all bits 0 then it has to use something
other than all bits zero as the NULL pointer. It also has to do compile
time magic so that things like "ptr == 0" work as you would expect
"ptr == NULL" to work. I.e. if ptr is all bits zero the result is false.

2) If the implementation might place the start of a function at all bits
0 then I believe 1 above applies again because a pointer to a function
has has to be distinct from the null pointer.

3) If there is some resource stored at all bits 0 that you have to be
able to access then the compiler has to (as a Quality of Implementation
issue, not a standards conformance issue) provide some non-standard
method of accessing it. This could be allowing you to dereference the
null pointer to get at it (although I would not like that) or some other
mechanism such as letting you use *__HRCW to access it (using compiler
magic) and having the null pointer be something other than all bits 0.
My preferred method would be for the compiler to provide symbols like
__HRCW (which is in the implementation name space so providing it does
not break standards conformance), but that does not mean they do it this
way.
--
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.

[Keith Thompson]

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

My doubt is that, since we have placed something valid "HRCW in case
of PowerPC" (take the example of an embedded system, where application
has been linked with kernel ) at location all-bits-zero, so isn't it
possible that null pointer may compare equal (because we have some
valid object
at location all-bits-zero).
This may sound very illogical or absurd to the experts, but
this is the picture that i have in my mind.

If there is a valid C object at location all-bits-zero, the C
implementation should not use all-bits-zero as a null pointer. Any C
object declaration, or any call to malloc() and friends, should
*never* allocate an object at whatever address the implementation has
chosen for the null pointer; if it does, it indicates a bug in the
compiler or in the malloc() implementation.

If there's some system object (outside the scope of the C language,
but potentially accessible from a C program) at location
all-bits-zero, or at whatever location the implementation has chosen
for null pointers, there is no portable way to access that object. In
fact, there's no portable way to access any object at a specified
address. (You can convert an integer to a pointer, but the result is
implementation-defined.)

An implementation may permit access to a system object at location
all-bits-zero, even if the null pointer is all-bits-zero. Such access
is likely to involve derferencing a null pointer, which of course
invokes undefined behavior -- but an implementation is free to
document the effects of instances of undefined behavior.

For example:

#include <stdio.h>
int main(void)
{
unsigned char *ptr = NULL;
printf("The value stored at address %p is %d\n",
(void*)ptr, (int)*ptr);
return 0;
}

This program invokes undefined behavior, but the effect of that
undefined behavior might be to print the value of whatever is stored
at address all-bits-zero. If the implementation documents this, the
above is a valid program *for that implementation*. Port it to
another implementation and it will likely blow up in your face.

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

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

2) If the implementation might place the start of a function at all bits
0 then I believe 1 above applies again because a pointer to a function
has has to be distinct from the null pointer.

[...]

A small quibble:

A function pointer doesn't necessarily contain the address of the
start of the function. It could be, for example, an index into a
table. Also, a null function pointer doesn't have to have the same
representation as a null object pointer. You could have null object
pointers represented as all-bits-zero, null function pointers
represented as all-bits-one, and a valid function (main?) starting at
address all-bits-zero. (And of course code and data could be in
separate address spaces.)

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

Keith Thompson wrote:

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

[...]

That was UCSD Pascal, which is not representative.

(Actually it was a derivative of UCSD Pascal.)

Not representative of what?

Proper ISO (or even J & W) compliant Pascal. Influential, though.

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

[Kelsey Bjarnason]

On Tue, 17 Aug 2004 14:17:49 -0700, 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.

http://www.eskimo.com/~scs/C-faq/q5.17.html

Amazing what you can find by reading the FAQ.

[E. Robert Tisdale]

Kelsey Bjarnason 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.

http://www.eskimo.com/~scs/C-faq/q5.17.html

Amazing what you can find by reading the FAQ.

I don't believe that any of these platforms ever supported
a "standard conforming C compiler".

[Dave Thompson]

In Mon, 16 Aug 2004 06:48:19 GMT, Keith Thompson <ks***@mib.org>
wrote:
<snip>

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

I can give you one, though obscure and arguably obsolete: classic but
still used in emulation Tandem^WCompaq^WHP NonStop aka TNS.

The (1970s proprietary) ISA defined originally two code segments --
one "user" (application) per process, one "system" (OS) shared -- each
with an entry point aka PEP table at the beginning containing 2
overhead (16-bit) words followed by up to 510 procedure addresses
(16-bit within segment). The (app) call instruction PCAL contained a
9-bit index, as did system call SCAL. BTW their OS was effectively a
nanokernel design, long before that term existed, so most of the OS
functionality was and still is actually in the "user code" segments of
various system processes, not in the "system code" segment.

Over time they added a second shared/OS "library" segment with a third
instruction LCAL, then an additional per-process "user library"
segment at which point they changed the PCAL instruction to index into
a second per-segment *exit* table at the end somewhat confusingly
called external entry point aka XEP, each entry a 16-bit word itself
containing 2 bits selecting the target segment plus 9 bits indexing
into the PEP table thereof. Then finally they used 4 of the remaining
bits of the XEP word to allow multiples of each segment type (user,
user library, system, system library).

And there was a separate indirect call instruction DPCL which now
takes that XEP word format; I forget if it originally took a "system"
bit (plus index) or was limited to user code. So to make a long story
not short enough, that XEP word format is the function pointer for C.

The data segments are also separate, again originally one "user" per
process and one "system" shared but accessible only by privileged
(normally system) code. The original 16-bit (TNS1) memory model is
still available as an option, restricted to less than 64KB*; in the
32-bit (TNS2) memory models, data pointers are 32-bit (mostly, with
some further hacks, and can access some code sometimes for readonly
but not for execution) and function pointers are 32-bits with the
upper 16 as above and the lower 16 not used (zero). While the C
standard allows function and data pointers to be different sizes as
well as different representations, Tandem did only the latter; I'm not
sure why. Perhaps just convenience. As long as you don't have huge
numbers (perhaps arrays) of function pointers, which I've never seen
anyone do, the space wastage is minor.

So using a converted or punned function pointer for a data access may
get you data completely unrelated to the function but more likely a
fault; while similarly using a data pointer for a function call will
get you either a valid function, having nothing to do with the data,
or a fault (segment or index out of range). PEP index zero is never
used, so a zero XEP word can be the null function pointer.

* As I've previously posted, TNS1 actually has two data pointer forms
-- one for byte/char=8-bit, and one for everything else, which must be
word=2-byte aligned, so in that environment you can't just treat all
data pointers as void*. The *ISA* supports 64KW = 128KB. But the HLL
runtime reserves the upper 32KW, hence *in C* only 32KW = 64KB of data
less some overhead, including as I've recently posted RTL-sacred data
always at data address 0 allowing that to be the null data pointer.

And in another oddity, the TNS stack grows upward, so the
"local" stack smashes too common in C on most other machines are
harmless -- they just run off into unused memory. It is still possible
to clobber the stack if you overrun a buffer in the (or a) *caller*'s
frame, or in some cases a "global" aka static-duration one, but this
is usually harder to provoke or control. And even if you do, you flat
cannot execute code from data space; the most you can do is redirect
to existing code somewhere. Or crash the process; or if you could
manage it in system code in the days of real hardware TNS, less likely
as the system code then wasn't in C and never used null-terminated
strings, maybe crash the CPU. (Current "TNS/R" systems emulate classic
TNS only in userspace, optionally, not system.)

Multics also had a code segment format that restricted in-calls to
(via) entries in a small, checked table, but I don't recall exactly
how the pointers worked, and in any case it no longer exists. I don't
believe it ever had a C, especially in view of C's historically strong
and originally exclusive connection with Unix.

- David.Thompson1 at worldnet.att.net

[Dave Thompson]

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

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

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

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?

My K&R2 went missing some time ago, but the C standard specifically
says "region of _data_ storage" (emphasis added). Note it doesn't
require addressibility; this includes variables (aka named objects)
put in machine registers, possibly but not necessarily by declaring
them with storage class 'register'.

On (essentially?) all computers today compiled code for functions is
in fact stored in memory; and on most of them at least some of the
time that memory is addressible in the same way as data. *In those
environments* a C compiler usually(?) allows you to interchange
function and data pointers, and there can sometimes be good reason to
do so, although it's not portable and often virtual memory is set up
so that you cannot *write* to function addresses.

But C intentionally does not require this. In fact one of the quite
early "ports"* of C -- long before C89 and K&R2 -- was to models of
the PDP-11 with separate "instruction" (code) and data space, called
"split I&D" and more generally known as "Harvard architecture". On
those machines the code to dereference a data pointer simply cannot
access code, and that to dereference (call) a function pointer (or
call an actual function, the more common case) simply cannot access
data; in assembler you can access code as data with special
instructions, MFPI/MTPI, subject IIRC to privilege, but the compiler
doesn't know to generate them. * "Port" in quotes because the compiler
can generate the same instructions and data as for nonsplit -11s; the
only difference is a tweak in the linker, and of course some changes
in the VM in the underlying OS, which isn't normally considered part
of the C implementation although in a formal sense it is.

<OT> And it hasn't changed officially even *in* C++ -- which still
uses 'object' in the C meaning, and for the things that OO people call
'object' it consistently uses (often clumsier) forms like 'object of
class type', 'class object', or more specific things like 'object of
non-POD class type having a nontrivial constructor'. </>

- David.Thompson1 at worldnet.att.net