"Mastering C Pointers"....

[Keith Thompson]

As far as I'm concerned, a pointer is an object that points to
something else, either another object, or a function, or nothing.

Not everyone uses the word that way. By analogy, the phrase "an int"
or "an integer" can refer either to an object of type int or to a
value of type int.

We're not going to settle the question of what "a pointer" is, so
whenever there's any ambiguity I suggest referring to "a pointer
object" or "a pointer value".

Hmm. I just noticed that the standard's definition of "value" is
"precise meaning of the contents of an object when interpreted as
having a specific type" (3.17). On the other hand, a constant (such
as 42) is said to have a value: "The value of a constant shall be in
the range of representable values for its type." (6.4.4 p2), even
though there's no object associated with it. This looks like an
inconsistency. If so, I'll take it up in comp.std.c.

 

[Keith Thompson]

Actually p is a variable. It merely happens to have an immutable
value.

Since the standard doesn't define the word "variable", I would
hesitate to use it to refer to something that isn't able to vary.

 

[Sheldon Simms]

This depends on the definition of a "pointer". Is it a value or a
variable?

Maybe it's necessary to differentiate between what a pointer is in
source code and what a pointer is in an executable or running
program.

For example, Richard says "NULL is most definitely a pointer" but
the standard says in 6.3.2.3#3:

"An _integer_ constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant."

and then

"If a null pointer constant is converted to a pointer type, the
resulting pointer, called a null pointer, is ..."

Which strongly implies that a null pointer constant is not a pointer,
but a null pointer is. Of course, as Keith pointed out, a null pointer
constant is a syntactic construct that doesn't exist in an executable
program.

Similarly, (&a) is an expression with type "pointer to type of a", but
in an executable program, won't necessarily exists as either an object
or an explicit value.

 

[Irrwahn Grausewitz]

On Wed, 5 Nov 2003, Irrwahn Grausewitz wrote nonsense.

No, that one was ROSY. Google "spoke ur nose"...

Indeed. Somehow goose's email address sneaked into me mind.
My only excuse being somewhat confused at the moment.

-Arthur,
maybe it *is* best not 2 spoke my nose on this matter

<g>

 

[pete]

Not everyone uses the word that way. By analogy, the phrase "an int"
or "an integer" can refer either to an object of type int or to a
value of type int.

We're not going to settle the question of what "a pointer" is, so
whenever there's any ambiguity I suggest referring to "a pointer
object" or "a pointer value".

Hmm. I just noticed that the standard's definition of "value" is
"precise meaning of the contents of an object when interpreted as
having a specific type" (3.17).

I've been wondering about the meaning of the word "value"
and the meaning of the phrase "meaning of a value".

N869
6.2.5 Types
[#1] The meaning of a value stored in an object or returned
by a function is determined by the type of the expression
used to access it."

In the above description of types,
it seems to me that "value" is being used to mean bit pattern.

The meaning of "rvalue", in the language called "B",
was "a binary bit pattern of a fixed length".
http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html

When I use the word "value", I'm usually thinking of
the interpretation of the bit pattern according to type,
as in (3.17), quoted above.
I was thinking that the same object can have different values
depending on how the object is accessed.
But the description of types, says that the same value can have
different meanings depending on how it's accessed,
which is a different meaning for "value" than the one given in (3.17)

 

[nobody]

I would say, "yes, you're wrong." There is no such thing as
a "value of type 'string'," for the simple reason that C doesn't
*have* a type 'string'. What C has is a type 'array of char',
which may under some circumstances *hold* a string.

Thanks for an answer. I did it again. I know exactly what you mean,
I just never can word it correctly. That is probably why everyone
who is more knowledgeable, simply uses term "string", as you above,
without any attributes (like 'type', 'value', 'object' and what-not).
I would be interested under which circumstances 'array of char'
*can't* hold a string (I mean, in principle, not if length exceeds size).

That is, the "string" is a kind of "meta-value" affected by all
the values of the elements of the char array. If the array
contains a null character, then it contains a "string." But
to avoid confusion [;-)] I do not consider arrays to have "values"
by themselves. The individual *elements* of an array can have
values, and the name of the array certainly has a value when
used in a value context, but the "array" itself... no. Not by
my way of categorizing things.

Is string value *and* object
at the same time and they are just identical, without "dichotomy"
of other types?

char *foo = "hello";
char bar[6] = "world";

'foo' is an object of type 'pointer to char'. Its value is the
address of the first element of the anonymous object "hello", which
itself is of type 'array[6] of char'. 'foo' points to a string.
'bar' is an object of type 'array[6] of char', and its elements
have the values 'w', 'o', [...], '\0' respectively. 'bar' holds
a string.

See, I never once referred to any "object of type string" or

That is true, but in paragraph above you wrote 'object "hello"'.
I know all this about arrays and pointers (in this specific case, my
problem is terminological), but "hello" from above is obviously
a string. Is string an object? [] Do you see my difficulties
with proper terminology? Maybe you wanted to write something
different, maybe not. I'm always looking for some 'qualifier' when
talking about strings. It appears none of them are 'valid' (in terms
of standardese). Except maybe 'string literal'. *Than* I know
what I'm talking about. Maybe I'm looking for something what
doesn't exist. String is a string and that's it.

"value of type string," because such things don't exist. There
is no *type* "string" in C.


I think (and hope) if you'd said that C doesn't have a string
*type*, you would have been correct.

No. I meant 'string *type*', but actually said "doesn't have a string".
(I know, I know, I should think before posting.)

Kind of like C doesn't
have language support for many OOP concepts, but anyone who
flatly claims that you can't do OOP in C will get death-by-
sample-code.

<ot> Is there any fitting idiom in English
for that? Something like "falling into one's own trap" ? </ot>).

"Hoist by [one's] own petard." Etymology something involving
dynamite, so I've heard.

Thanks.

 

[Arthur J. O'Dwyer]

To be really clear (which I suppose one must), one should really
speak of "objects of pointer type" and "expressions of pointer
type."
Above "pairing" fails for "strings", [...]
There is only "a value of type 'string'", but no "object of type
'string'". Or am I wrong again?

I would say, "yes, you're wrong." There is no such thing as
a "value of type 'string'," for the simple reason that C doesn't
*have* a type 'string'. What C has is a type 'array of char',
which may under some circumstances *hold* a string.

Thanks for an answer. I did it again. I know exactly what you mean,
I just never can word it correctly. That is probably why everyone
who is more knowledgeable, simply uses term "string", as you above,
without any attributes (like 'type', 'value', 'object' and what-not).
I would be interested under which circumstances 'array of char'
*can't* hold a string (I mean, in principle, not if length exceeds size).

Well, okay, I suppose I could have said, "which *does* under some
circumstances hold a string." The word 'may' in English has two
meanings: sometimes it means 'can' and sometimes it means 'might':

Mother said that I may go to the candy shop today. [or "can"]
^^^
Mother said that she may go to the candy shop today. [or "might"]
^^^

I intended to mean "might." Under some circumstances which *might*
arise, an array can hold a string. Under *other* circumstances, an
array might *not* hold a string -- namely, if the array doesn't
contain a terminating null character.
<pedantry>
But see this interesting point by Dan Pop in another recent
thread for one reason why what I just wrote is wrong:
http://groups.google.com/[email protected]

char *foo = "hello";
char bar[6] = "world";

'foo' is an object of type 'pointer to char'. Its value is the
address of the first element of the anonymous object "hello", which
itself is of type 'array[6] of char'. 'foo' points to a string.
'bar' is an object of type 'array[6] of char', and its elements
have the values 'w', 'o', [...], '\0' respectively. 'bar' holds
a string.

See, I never once referred to any "object of type string" or

That is true, but in paragraph above you wrote 'object "hello"'.
I know all this about arrays and pointers (in this specific case, my
problem is terminological), but "hello" from above is obviously
a string.

Yup. "hello" is the string stored in the anonymous array pointed
to by 'foo'.

Is string an object?

Nope. A string is not an object.

"hello" in the above code is also a string literal. 'String
literal' is a compile-time, source-level concept. The Standard
defines exactly what a 'string literal' is, and you can look it
up yourself. Basically, it's a bunch of junk in between
double quotes.

<pedantry>
As the Standard points out, not all string literals are
strings. For example, "abc\0def" is a string literal, but not
a string. But then again, in a value context that string
literal decays into a pointer that *does* point to a string --
the string "abc"!
</pedantry>

HTH,
-Arthur

 

[nobody]

(Yes. Left in just to establish context.)



In C, the term "string" really refers to a data *format*, rather
than anything in the type, value, object, etc., sense.

Thank you. This was the wording I couldn't quite put my finger on.
"data format".

Suppose I were to tell you that I have a set of (binary) files
in which each "record" is a variable-length region prefixed by
two eight-bit bytes giving the length of the record in big- or
little-endian format (i.e., I tell you which byte to multiply
by 256 before adding the other, to get the length). You then
find the record length by doing:

c1 = getc(fp);
c2 = getc(fp);
if (c1 == EOF || c2 == EOF) ... handle trouble and/or EOF ...
len = c1 * 256 + c2; /* if big-endian */
len = c2 * 256 + c1; /* if little-endian */

Wouldn't left shift be better? Or are today's compilers "smart" enough
to do this kind of stuff themselves? /*Someone had mentioned this
possibility earlier (particular case was multiplication by 2).*/

Having done this, you can now read the record -- which is "len"
bytes long -- or skip over it using fseek(), for instance.

What I have done is describe a data format for the file. As long
as you have a valid starting point from which to read the file's
records, you can read through all the records in the file, and
detect a "short read" if the file ends too soon (in the middle of
a record, or with c2==EOF but c1!=EOF in the above code).

A C string is just a data format in memory -- simpler than the
record format in this file, because there is no leading count to
interpret, but a data format nonetheless. You could write a sequence
of strings to a binary file and then read them back by reading
bytes until you find each '\0' -- each such set of bytes is a
"string" in the file.


Since a string is a data format, you must store it in some other
data object. A sequence of bytes ending with a '\0' will fit in
*any* C object of sufficient size (due to C's requirement that all
objects break down into a sequence of "unsigned char" bytes), but
the most suitable is a sufficiently large array of char (or unsigned
char, in some special circumstances).

Among other things, this means that you can -- nonportably, but
perhaps tested at compile time -- store 7-or-fewer-character C
strings in "double"s, as long as sizeof(double) >= 8 (as is fairly
typical). But you must then use considerable care never to access
those "double"s as lvalues of type "double", since the bit patterns
created by strings might be reserved when treated as ordinary
"double", and cause a runtime trap. (Modern IEEE-fp machines in
particular will trap "signalling NaNs" if the NaN trap is enabled.)
This is thus the kind of code one should only use in an "obfuscated
C" contest.

Thanks.

 

[nobody]

I'm aware of the pitfalls of assuming pointers are integers. However, I'd
say that when porting non-ANSI code from a platform to where they are
"equivalent" to one where they are not, that you'd simply do well to know
your hardware, and thus this fact would stick out like a sore thumb.

Point of writing conforming code is that you *don't* have "well to know
your hardware". Sane people prefer freedom from such details given to
them by standartized abstraction. That is not to say that they don't know
those details. Sane people prefer not to have sore thumbs sticked in
their eyes.

I'm not too familiar with wheel bits,

Thanks to God Almighty. Otherwise there would be another endless
"discussion" why it's good to use them, so later on "this fact would stick
out like a sore thumb", but that would be OK, because "then you will
incur the cost, and not a particularly great one". BTW, I've got no idea
what they (wheel bits) are, but AFAIK they are not mentioned in the
standard, and I'm not going to pretend that I'm "not *too* familiar" with
them, just in case it's made-up term.

but I would suggest that this bug
could quickly found out by any rudimentary testing. Like the manager doing
a dry run before presenting to customers. It depends on the specifics of
course, but I think it is a stretch to think that such errors are likely to
produce rare bugs that could have only been avoided if the code were ANSI C
in the first place.

It's not a stretch This kind of bugs (as described above and creation of
whose you are advocating /*assume equivalence of pointer and integer*/)
*would* have been avoided by adherence to the standard. *That's* why
it is good thing to write ANSI C code (among other things).

As I said, I would prefer to incur the cost of portability when the feature
is needed.

No one is preventing you from doing it. However, you shouldn't try that
hard to convince newbies that the opposite "simply isn't necessary
engineering practice" and to change focus of this NG.

Not when writing the program for the first device. When porting

And I thought you are writing (C-like) programs *for* customers,
to make money for your company ("Thus, in the business world, it is
not considered good practice, since time = money", "ones that actually
generate money", "Do we have standard C code now that we ported it?
No.Do we need to? Not really, the products sold more than 1.5 million
copies and generated millions of dollars in profits").

to the second device, you will have specific hardware differences to
examine. And then you will incur the cost, and not a particularly great one
in my experience.

Would you incur such cost out of your pocket? Why not to avoid
associated cost (when possible)? Just because *company* will pay for
it? Ultimately, it's customers who are paying it.

 

[Richard Heathfield]

See my post elsethread for why that's a bad definition.

And mine (although I admit I'll have to go another round with Mark, since he
seems to think that a null pointer isn't a pointer).

I have no idea what that means. Is it a breakfast food?

Ah, welcome to British culture.

"Mornington Crescent" is a joke on "I'm Sorry I Haven't A Clue", a Radio 4
'comedy' quiz program. The contestants (always the same four, I think, so
really they're members of the cast - Tim Brooke-Taylor and Graeme Garden of
"The Goodies", one of Barry {Humphries|Cryer}, and some other bloke)
pretend to follow a set of complicated rules whilst taking turns to name
London Underground (subway) stations. The joke, which has worn rather thin
over the hundred years or so that the show has been running (and it's still
starring the original cast), is that there are in fact no rules whatsoever.

I understand I may have broken some kind of cabalistic law by revealing this
fact, so if I don't post any more after today, you'll know why.

 

[Richard Heathfield]

Well..... NULL is a macro, which is converted by the preprocessor to a
constant inserted literally into the processed code, whose value is
selected to be the one the implementation uses to mean "I point
nowhere". So its not actually a pointer at this point. If you see my
point.

The Standard says: "Such a pointer, called a null pointer, is guaranteed to
compare unequal to a pointer to any object or function."

But thats fine - its not a pointer either...

The Standard disagrees with you.

 

[Richard Heathfield]

Funny thing is, those "old" machines are still cranking out the data.

Surely you mean "cranking /in/ the data"?

Data is (or are!) what you put into a computer. What it cranks out is
information. Well, that's the general idea, anyway.

 

[goose]

YRI.

yup! corrected above as well. i was thinking "function pointers".


goose,
the *other* "ruse", but not the troll.

 

[goose]

TIWITAW.

<all confused>

goose,
"cut that out!!!"

 

[goose]

I should certainly hope so
my only vices are the occasional incorrect advice and
lazy punctuation.

No, that one was ROSY. Google "spoke ur nose"...
I don't think we've ever had a troll named "ruse."
http://dictionary.reference.com/search?q=ruse

-Arthur,
maybe it *is* best not 2 spoke my nose on this matter

maybe its *never* a good idea to spoke your nose, it
sounds quite painfull

goose,
*still* the other "ruse".

 

[Richard Heathfield]

<all confused>

FWIW, IUWJM

 

[Ian Woods]

Data is (or are!) what you put into a computer. What it cranks out is
information. Well, that's the general idea, anyway.

Computers aren't bright enough to deal with information, merely data. Data
in, data out. What determines whether it's garbage or not is the
information those data represent.

Ian Woods

 

[Jeremy Yallop]

The Standard says: "Such a pointer, called a null pointer, is guaranteed to
compare unequal to a pointer to any object or function."

That sentence applies to the result of converting a null pointer
constant to a pointer type, not to a null pointer constant as such.

"If a null pointer constant is assigned to or compared for equality
to a pointer, the constant is converted to a pointer of that type.
Such a pointer, called a null pointer, is guaranteed to compare
unequal to a pointer to any object or function." (C89: 3.2.2.3)

The corresponding passage in C99 is even clearer:

"If a null pointer constant is converted to a pointer type, the
resulting pointer, called a null pointer, is guaranteed to compare
unequal to a pointer to any object or function." (6.3.2.3)

That is, a null pointer constant (e.g. `0') is not a pointer, but an
expression that is converted to a pointer in certain contexts.

Jeremy.

 

[Tristan Miller]

Greetings.

I'm sorry, did you just killfile RJH?

Don't be surprised. Alan Connor, while only a recent appearance here, is a
well-established troll from other newsgroups in the comp.* hierarchy. His
preferred tactic is to loudly denounce some well-established standard or
technique based on his largely incorrect understanding of it, and then
conspicuously fire off plonks to anyone who dares criticize his reasoning.
Often this will be accompanied by fervent promotion of some program he
personally cobbled together to fix the mythical problem. Anyone who points
out the shortcomings or uselessness of this software is accused of
membership in a vast conspiracy for its suppression. I am not making this
up. See, for example, his rants on spam filtering and on PGP signatures in
comp.os.linux.misc and other groups.

Roose would be better not to make too much of Alan's admiration of him.
(Actually, I'm surprised Alan hasn't already plonked Roose for his repeated
top-posting; he's known to killfile people simply because he thinks their
modest signatures are too long.)

Regards,
Tristan

 

[Tristan Miller]

Greetings.

My assertion is that I have posted
here before, but not under the handle Roose.

Let me guess: your previous handles on this group were Karl Malbrain,
Ioannis Vranos, and Scott Nudds. What do I win?