Hey guys, I'm new here, just a simple question.
I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.
I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.
thanks in advanced.
sincerely ... Andy
Nov 13 '05
388  21385 
Mark McIntyre <ma**********@spamcop.net> writes: On 5 Nov 2003 21:57:18 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.helsinki.fi> wrote:
Mark McIntyre <ma**********@spamcop.net> scribbled the following: On Wed, 05 Nov 2003 01:46:09 GMT, in comp.lang.c , pete
<pf*****@mindspring.com> wrote:
int a;
&a;
(&a) is a pointer, but not an object.
I disagree. (&a) in that context is an expression. To be a pointer, it
would have to be stored in something. .
This depends on the definition of a "pointer".
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 (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Mark McIntyre <ma**********@spamcop.net> writes: On Wed, 5 Nov 2003 01:46:39 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
int i = 6;
int * const p = &i; /* p is not a variable - or at least, to persuade
anyone that it is, you'd have to have kissed the Blarney. */
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.
--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
On Wed, 05 Nov 2003 21:57:18 +0000, Joona I Palaste wrote: Mark McIntyre <ma**********@spamcop.net> scribbled the following: On Wed, 05 Nov 2003 01:46:09 GMT, in comp.lang.c , pete
<pf*****@mindspring.com> wrote:int a;
&a;
(&a) is a pointer, but not an object.
I disagree. (&a) in that context is an expression. To be a pointer, it
would have to be stored in something. .
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.
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote: 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>
--
Irrwahn
(ir*******@freenet.de)
Keith Thompson wrote:
Mark McIntyre <ma**********@spamcop.net> writes: On 5 Nov 2003 21:57:18 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.helsinki.fi> wrote:
Mark McIntyre <ma**********@spamcop.net> scribbled the following:
> On Wed, 05 Nov 2003 01:46:09 GMT, in comp.lang.c , pete
> <pf*****@mindspring.com> wrote:
>>int a;
>>&a;
>>
>>(&a) is a pointer, but not an object.
> I disagree. (&a) in that context is an expression. To be a pointer, it
> would have to be stored in something. .
This depends on the definition of a "pointer".
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).
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)
--
pete
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi**********************************@unix44.a ndrew.cmu.edu...
On Wed, 5 Nov 2003, nobody wrote:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote...
To be really clear (which I suppose one must), one should really
speak of "objects of pointer type" and "expressions of pointer
type." I don't think the Standard assigns any meaning to the
noun "pointer" itself, except as a kind of shorthand for
"object of pointer type" or "expression of pointer type." Just
like it doesn't make sense to speak of "a short int;" you can
speak of "an object of type 'short int'" or "a value of type
'short int'," but they're two different things whose only
commonality is their type.
Above "pairing" fails for "strings", which I believe can attribute for
often mistakes of (mis)handling them (e.g. not allocating memory
for them, or calling strstr() on "binary" data returned from socket,
as can be often? witnessed in questions posted here).
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).
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.
(That's why I try to avoid to use term "string" when
dealing with C and beginners, unfortunately to the point when
I've recently misleadingly stated /but fortunately was corrected/
that strings don't exist 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.
On Thu, 6 Nov 2003, nobody wrote:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote... On Wed, 5 Nov 2003, nobody wrote: "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote...
>
> 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/gr*************************@sunnews.cern.ch
</pedantry>
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
"Chris Torek" <no****@elf.eng.bsdi.com> wrote in message
news:bo**********@elf.eng.bsdi.com... "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi**********************************@unix47. andrew.cmu.edu... To be really clear (which I suppose one must), one should really
speak of "objects of pointer type" and "expressions of pointer
type." ...
(Yes. Left in just to establish context.)
In article <dV*******************@twister01.bloor.is.net.cabl e.rogers.com>
nobody <no****@nowhere.non> writes:Above "pairing" fails for "strings", which I believe can attribute for
often mistakes of (mis)handling them (e.g. not allocating memory
for them, or calling strstr() on "binary" data returned from socket,
as can be often? witnessed in questions posted here).
There is only "a value of type 'string'", but no "object of type
'string'". Or am I wrong again?
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.
Is string value *and* object at the same time ... ?
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.
"Roose" <no****@nospam.nospam> wrote in message
news:2d*************@newssvr14.news.prodigy.com...
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:3f****************@news.nl.net... "Roose" <no****@nospam.nospam> wrote:
_That_ exact bug? No, obviously not, since Keith already said that that
scenario was a spur-of-the-moment invention. However, some bugs can be
pretty arcane, and only show up under unusual circumstances. For
example, search the Jargon File for "phase of the moon".
For an example where assuming that "integer" is equivalent to "pointer"
leads to a bug, assume that a pointer is six bytes and the best
available integer four.
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.
Suppose, also, that for normal users, including developers, their
address space is in the lower part of the spectrum, so that they'll
never encounter the situation where a pointer converted to an integer
overflows, which means that for them, converting a (small) pointer to an
integer and back again apparently works.
Now suppose that your manager, who never uses the program but wants to
demonstrate it to a customer, happens to have a wheel bit set, causing
his address space to be in the upper reaches of memory, which means that
in his case the higher-order bytes of his pointers are _not_ all zero,
unlike the usual case...
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.
Ben Pfaff wrote: Mark McIntyre <ma**********@spamcop.net> writes:
On 5 Nov 2003 21:57:18 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.helsinki.fi> wrote:
>This depends on the definition of a "pointer".
As far as I'm concerned, a pointer is an object that points to
something else, either another object, or a function, or nothing.
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).
Mornington Crescent.
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 : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Mark McIntyre wrote: 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." and yet, in the expression if(p != NULL) the NULL is not "stored
in anything" - that is, the RHS of the != is not the value of an object.
But thats fine - its not a pointer either... :-)
The Standard disagrees with you.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Lew Pitcher wrote: August Derleth wrote: Le*********@td.com (Lew Pitcher) wrote in message
news:<3f***************@news21.on.aibn.com>...
<snip> Those old machines were rather interesting, especially where the
designers kind of knew what they really wanted but had to work around
the hardware to get something close.
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.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Richard Heathfield <do******@address.co.uk.invalid> wrote in message news:<bo**********@sparta.btinternet.com>... goose wrote: Mark McIntyre <ma**********@spamcop.net> wrote in message
news:<hp********************************@4ax.com>. ..
And are functions objects?
iirc, yes.
YRI.
yup! corrected above as well. i was thinking "function pointers".
goose,
the *other* "ruse", but not the troll.
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bo**********@oravannahka.helsinki.fi>... Richard Heathfield <do******@address.co.uk.invalid> scribbled the following: goose wrote: Mark McIntyre <ma**********@spamcop.net> wrote in message
news:<hp********************************@4ax.com>. ..
And are functions objects?
iirc, yes.
YRI.
TIWITAW.
<all confused>
goose,
"cut that out!!!"
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi***********************************@unix44 .andrew.cmu.edu>... On Wed, 5 Nov 2003, Irrwahn Grausewitz wrote:
ru**@webmail.co.za (goose) wrote:
(btw: "roose" is an intentional troll, ever considered that
"roose" is just a mispelled "ruse"?)
Yes, I did indeed, but ruse's and Roose's postings are definitely of
I should certainly hope so :-)
my only vices are the occasional incorrect advice and
lazy punctuation.
different style. And I do not consider either one to be smart enough
to successfully pretend to be somebody else.
Remember ruse: "... again, spoke your nose!" makes me still ROFL. :D
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".
goose wrote: Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message
news:<bo**********@oravannahka.helsinki.fi>... Richard Heathfield <do******@address.co.uk.invalid> scribbled the
following: > goose wrote:
>> Mark McIntyre <ma**********@spamcop.net> wrote in message
>> news:<hp********************************@4ax.com>. ..
>>>
>>> And are functions objects?
>>
>> iirc, yes.
> YRI.
TIWITAW.
<all confused>
FWIW, IUWJM
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Richard Heathfield <do******@address.co.uk.invalid> wrote in news:bocra9
$n****@sparta.btinternet.com: 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
Richard Heathfield wrote: Mark McIntyre wrote: 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."
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.
On Thu, 06 Nov 2003 05:34:07 GMT, nobody <no****@nowhere.non> wrote:
Why do you talk to an obviously knowledgable man as if he was a member of
an inferior species who had never seen a computer before?
--
Alan C this post ends with w
q
Alan Connor wrote: On Thu, 06 Nov 2003 05:34:07 GMT, nobody <no****@nowhere.non> wrote:
Why do you talk to an obviously knowledgable man as if he was a member of
an inferior species who had never seen a computer before?
It is far from obvious that Roose is knowledgeable, at least in areas of
knowledge that this newsgroup recognises as relevant.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Richard Heathfield <do******@address.co.uk.invalid> scribbled the following: Alan Connor wrote: On Thu, 06 Nov 2003 05:34:07 GMT, nobody <no****@nowhere.non> wrote:
Why do you talk to an obviously knowledgable man as if he was a member of
an inferior species who had never seen a computer before?
It is far from obvious that Roose is knowledgeable, at least in areas of
knowledge that this newsgroup recognises as relevant.
That's a mighty big "at least", Richard. For all we know, Roose could be
the world's leading authority on car engine maintenance or something.
What he clearly is *not* knowledgeable about is C. He knows some C, but
not nearly enough to make the claims that he's making even as we speak.
OTOH, having or not having seen a computer isn't that relevant. It could
be argued that one could become an expert on ISO standard C really
without ever seeing a computer. *Only* in ISO standard C, though, mind
you - not any platform-specific extensions. Understandably, because
there would *be* no platform to speak of. But ISO standard C is all
this newsgroup cares about, and all it should care about.
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr
On Thu, 6 Nov 2003, Richard Heathfield wrote:
goose wrote: Joona I Palaste <pa*****@cc.helsinki.fi> wrote... Richard Heathfield scribbled:
> goose wrote:
>> Mark McIntyre wrote:
>>>
>>> And are functions objects?
>>
>> iirc, yes.
> YRI.
TIWITAW.
<all confused>
FWIW, IUWJM
Apparently, it was "That is what I thought as well."
But when I looked at it, I figured
RH: "You recall incorrectly."
JP: "Then I will [something] take a walk."
:-)
-Arthur
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> scribbled the following: On Thu, 6 Nov 2003, Richard Heathfield wrote: goose wrote: > Joona I Palaste <pa*****@cc.helsinki.fi> wrote...
>> Richard Heathfield scribbled:
>> > goose wrote:
>> >> Mark McIntyre wrote:
>> >>>
>> >>> And are functions objects?
>> >>
>> >> iirc, yes.
>>
>> > YRI.
>>
>> TIWITAW.
>
> <all confused>
FWIW, IUWJM
Apparently, it was "That is what I thought as well."
But when I looked at it, I figured
RH: "You recall incorrectly."
JP: "Then I will [something] take a walk."
:-)
Whoa! That's certainly possible (although in this case untrue), but it
just so nonsensical I can hardly stop laughing at it. goose recalling
incorrectly causes me to take a walk? Because of what? It's true that
taking a walk can refresh one's memory, but to refresh someone else's
memory...
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"This is a personnel commuter."
- Train driver in Scientific American
maniac wrote: Hey guys, I'm new here, just a simple question.
I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.
I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.
thanks in advanced.
sincerely ... Andy
man this thing's still around, holy crap.
oh, well good I guess.
On 05 Nov 2003 15:44:56 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.edu> wrote: Mark McIntyre <ma**********@spamcop.net> writes:
Mornington Crescent.
I have no idea what that means. Is it a breakfast food?
I'm sorry, I haven't a clue.
:-)
(well, ok then, 5th paragraph on this page.... http://news.bbc.co.uk/1/hi/uk/79273.stm
although a 30+ year steeping in British Comedy and a labyrinthine
knowledge of the london underground map is typically required to stand
a chance of winning, never mind understand Graeme's rules at the end
of the article)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
On 05 Nov 2003 15:44:56 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.edu> wrote: Mark McIntyre <ma**********@spamcop.net> writes:
As far as I'm concerned, a pointer is an object that points to
something else, either another object, or a function, or nothing.
See my post elsethread for why that's a bad definition.
I must have either completely missed that post, or misunderstood it.
Could you paraphrase?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
On Thu, 6 Nov 2003 06:49:58 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote: "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",
Its highly likely you'll now have to explain "The Goodies". Good
luck...
one of Barry {Humphries|Cryer},
Cryer
and some other bloke)
Willie Rushton (decd)
there are in fact no rules whatsoever.
Balderdash, you heretic !! Graeme provided the following rules for the
terminally confused ie those stuck at Aldwych, Barking or Edgware Road
(District Line).
-Boxing out the F, J, O and W placings draws the partner into an
elliptical progression north to south
-In weak positional play, it is vital to consolidate an already strong
outer square, eg Pentonville Road
-In a straight rules game, it's inadmissible to transfer inversely,
which is otherwise a powerful tactic
-Opening the triangle will block any of the three possible reverse
draws and is usually played early in the game (before the Central Line
has been quartered) so that the risk of a diagonal move is negligible,
as is the possibility of quartering
-The lateral shift decisively breaks opponents' horizontal and
vertical approaches.
-The A40 northbound used as a counter-play offers rear access to
suburban bidding
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.
Be afraid, be very afraid.....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
On Thu, 6 Nov 2003 06:51:41 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote: Mark McIntyre wrote:
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."
Well, no actually.
It says
"An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant. 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-1)
You will note the phrase "if .... converted to a pointer type". I
believe we agree that NULL is a macro with value either zero or
(void*)0. It is therefore a null pointer constant. And I read the
above as saying that its not a pointer until its converted to a
pointer type. My case rests. For now... But thats fine - its not a pointer either... :-)
The Standard disagrees with you.
I disagree that it disagrees. In order to compare p to NULL, you must
convert p to a pointer type (see quote above, plus 6.3.2.3-4). I'm
doubtful that you could convert a null pointer constant to a pointer
type without storing it somewhere....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
On Thu, 6 Nov 2003 07:59:34 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote: goose wrote:
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message
news:<bo**********@oravannahka.helsinki.fi>...
TIWITAW.
<all confused>
FWIW, IUWJM
BUAATOO, IR.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
>"Chris Torek" <no****@elf.eng.bsdi.com> wrote in message news:bo**********@elf.eng.bsdi.com...
[much snippage] len = c1 * 256 + c2; /* if big-endian */
len = c2 * 256 + c1; /* if little-endian */
In article <tA*******************@twister01.bloor.is.net.cabl e.rogers.com>,
nobody <no****@nowhere.non> wrote: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).*/
Assuming there is no overflow -- and if "len" is at least
unsigned int, and c1 and c2 are in the range [0..255], then
we can make sure that there is none by replacing "256" with
"256U" in each case -- then writing either of:
len = (c1 << 8) + c2;
or len = c1 * 256 + c2;
makes no difference, as a left-shift is equivalent to a multiply.
Of course these should be expressed as:
len = ((unsigned int)c1 << 8) + c2;
and len = c1 * 256U + c2;
respectively.
As for whether one form or the other is "better", it depends on
what you intend to convey to a (human) reader. Any compiler worth
what you paid for it will optimize "c1 * 256U" (or even c1*256,
without the U) into a left shift, and -- in the absence of overflow
-- left shifts are defined in terms of multiplication. (In the
presence of overflow, neither is strictly defined by the C standards,
and a compiler can use the shift anyway on any typical modern CPU.)
Thus, whether you write "what you mean" or "how to do it" is in a
sense irrelevant, as they are isomorphic.
Even the division-by-shifting optimization is easy for compilers
to implement, although here it is more likely to occur for unsigned
operands, because a compiler must typically include some "compensation"
code for signed divison. This is because:
y = x >> 2;
vs y = x / 4;
is typically not the same when x is negative. For instance, (-1)
/ 4 is usually 0 (and I think is *required* to be 0 in C99), while
(-1) >> 2 is usually -1, on today's machines. Note, however, that
while left shift is *defined* in terms of multiplication -- in both
C89 and C99 -- right shift is not defined in terms of division
except for non-negative "x". Thus, in this case, you really *must*
write "what you mean" instead of "how to do it", as the two are
not necessarily synonymous.
<begin OT>
For the curious, the "compensation" code for a negative dividend
(and positive divisor) -- remember in x / y, x is the dividend and
y is the divisor -- works out to the following, all assuming 2s
complement and an arithmetic right-shift:
/* divide signed input "x" by divisor, whose log2 is d2 */
int divide_by_power_of_two(int x, int divisor, int d2) {
int adj;
/* required: (1 << d2) == divisor */
adj = (x & SIGNBIT) ? divisor - 1 : 0;
return (ux + adj) >> d2;
}
The idea here is that, e.g., when dividing by 4 (d2 == 2), we want
-1 to give 0, -2 to give 0, -3 to give 0, but -4 to give -1; -5
through -7 should also be -1, while -8 should be -2; and so on.
If x is nonnegative, x >> d2 gives the right answer, but if x is
negative, it gives the wrong answer unless x is an even multiple
of the divisor, otherwise it gives a value one too small (-1 instead
of 0, -2 instead of -1, and so on). Adding (positive) 3 gives the
right answer for -1 through -3 and leaves -4 at -1, which shifts
to -1; and so on. An equivalent trick is to add 1 to the result
if any "1" bits are shifted out during the right-shift operation,
but this is harder to test on typical machines -- the FPU has
hardware to collect such bits (in the "sticky bit" part of IEEE FP
processing), but the integer unit lacks it. The calculation of
the (x&SIGNBIT) adjustment value can, however, be done branchlessly
by shifting x the appropriate number of bits right, e.g., 31 for
32-bit x, to produce an all-ones mask for negative values and
all-zeros for nonnegative, then ANDing this mask with (divisor-1).
On a typical RISC we get something like:
mov x, reg # assuming x is already in a register
asr reg, 31, reg # where asr is arithmetic shift right
and reg, 3, reg # for divisor == 4
add reg, x, reg
asr reg, 2, reg # again for divisor == 4
# final result is now in "reg"
The constants (31, 3, and 2 here) are "number of bits in x that
are not the sign bit", "divisor - 1", and "log2 divisor". For
small divisors these usually fit in the instruction format -- most
RISCs have constant fields that go to at least 255, if not higher;
4095 is not unusual. All of this is only a win if the divide takes
more cycles than the four instructions above. Assuming a single
barrel or funnel shifter and two ALUs, the four instructions take
two cycles, while a typical integer divide is at least four cycles
and as long as 31 or 100 or so cycles, depending on the CPU, so
this is indeed a win, and the compiler should use it.
Of course, if the CPU has a single-cycle divide, or if the dividE
is "parallelizable" and there is other work to do before referring
to the result-value register, it is better just to do "idiv x, 4,
reg". On the (old-only?) MIPS, where you move the values into the
mul/div unit, it is something of a toss-up -- the divide runs in
parallel to any remaining work, but the extra moves consume extra
cycles.
<end OT>
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Mark McIntyre <ma**********@spamcop.net> writes: On 05 Nov 2003 15:44:56 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.edu> wrote:
Mark McIntyre <ma**********@spamcop.net> writes:
As far as I'm concerned, a pointer is an object that points to
something else, either another object, or a function, or nothing.
See my post elsethread for why that's a bad definition.
I must have either completely missed that post, or misunderstood it.
Could you paraphrase?
I quoted a paragraph from the standard that used the word
"pointer" several times to mean "value of pointer type". If the
standard doesn't always use "pointer" as meaning "object of
pointer type", then I don't think it's reasonable to define it
that way.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
On Thu, 6 Nov 2003 06:56:10 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote: Surely you mean "cranking /in/ the data"?
Data is (or are!) what you put into a computer. What it cranks out is
information.
Ah, so whats the difference between the stuff that comes out of a 1401
and goes into a 7094? Does it magically get transmogrified during the
technician's walk down the hall with the tape?*
Well, that's the general idea, anyway.
Hmmmm. I find this distinction highly artificial.
* for anyone under about 60, a 1401 is an IBM computer which was
typically used to read punched cards and transfer the results to
tape, which was then fed into a larger IBM, such as a 7094.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
On Thu, 06 Nov 2003 16:38:57 -0700, Chris Torek wrote: "Chris Torek" <no****@elf.eng.bsdi.com> wrote in message
news:bo**********@elf.eng.bsdi.com...
For the curious, the "compensation" code for a negative dividend
(and positive divisor) -- remember in x / y, x is the dividend and
y is the divisor -- works out to the following, all assuming 2s
complement and an arithmetic right-shift:
/* divide signed input "x" by divisor, whose log2 is d2 */
int divide_by_power_of_two(int x, int divisor, int d2) {
int adj;
/* required: (1 << d2) == divisor */
adj = (x & SIGNBIT) ? divisor - 1 : 0;
return (ux + adj) >> d2;
}
There was actually a really good example of this a few days ago
here in the thread about computing integer powers. The following
function was presented:
static int pow_a(int x, int y)
{
int t=1;
if (y < 0) return 0;
for(;;)
{
if (y%2) t*=x; /* if y is odd... */
if (!(y/=2))break; /* halve y and if result is zero... */
x*=x; /* square x */
}
return t;
}
While testing this and the other functions, I was read the output
of GCC for all of the functions because I was curious why some
functions seemed to run faster even though the C code was
apparently equivalent. The y/=2 in the second if conditional
is turned into the following x86 code by GCC 3.3.1:
movl %edx, %eax ; temp = y
shrl $31, %eax ; temp >>= 31
leal (%eax,%edx), %eax ; temp = temp + y
sarl %eax ; temp >>= 1;
movl %eax, %edx ; y = temp
-Sheldon
>On Thu, 06 Nov 2003 16:38:57 -0700, Chris Torek wrote: For the curious, the "compensation" code for a negative dividend ...
[with "int x, adj, divisor", and assuming two's complement] adj = (x & SIGNBIT) ? divisor - 1 : 0;
In article <pa***************************@yahoo.com>,
Sheldon Simms <sh**********@yahoo.com> wrote:... I was read the output of GCC for [various] functions [and found]
y/=2 in the second if conditional is turned into the following x86
code by GCC 3.3.1:
movl %edx, %eax ; temp = y
shrl $31, %eax ; temp >>= 31
leal (%eax,%edx), %eax ; temp = temp + y
sarl %eax ; temp >>= 1;
movl %eax, %edx ; y = temp
Yes, this is a special case of the code I suggested. We want
"adj = (x & SIGNBIT) ? (2 - 1) : 0", and of course 2 - 1 is 1. I
had suggested the general case would use (for x86) "sarl $31, %eax"
and then "and $1, %eax", but note that if we use a logical shift
instead of an arithmetic shift, the values we get for "is signed"
and "is not signed" are 1 and 0 respectively, instead of -1 and 0.
In (nonportable) C this would be:
/* adj = (x >> 31) & (divisor - 1); -- general case */
adj = (unsigned)x >> 31; /* specific case when divisor==2 */
This allows the compiler to omit the "and" instruction. (The
nonportable parts are twofold: this assumes x is a 32 bit two's
complement value; and it assumes that signed ">>" sign-extends.
The first part is easy to parameterize, but the second is not.)
(The "leal" instead of "add" is another fairly disgusting trick that
avoids pipeline constraints in some cases, I believe.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Mark McIntyre <ma**********@spamcop.net> wrote in message news:<j9********************************@4ax.com>. .. On Thu, 6 Nov 2003 07:59:34 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
goose wrote:
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message
news:<bo**********@oravannahka.helsinki.fi>...
TIWITAW.
<all confused>
FWIW, IUWJM
"for what its worth", and then ?
BUAATOO, IR.
??
goose,
tia :-)
Mark McIntyre wrote: But thats fine - its not a pointer either... :-)
The Standard disagrees with you.
I disagree that it disagrees. In order to compare p to NULL, you must
convert p to a pointer type (see quote above, plus 6.3.2.3-4). I'm
doubtful that you could convert a null pointer constant to a pointer
type without storing it somewhere....
You make a better case than I thought existed. Lacking the time right now to
make a detailed study of the matter, so I hope someone else picks it up.
I'm not quite so doubtful as you are about the conversion. After all, on
some implementations it's a no-op. Would you suggest that, say, 0 is an
object?
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Mark McIntyre wrote: On Thu, 6 Nov 2003 06:56:10 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Surely you mean "cranking /in/ the data"?
Data is (or are!) what you put into a computer. What it cranks out is
information.
Ah, so whats the difference between the stuff that comes out of a 1401
and goes into a 7094? Does it magically get transmogrified during the
technician's walk down the hall with the tape?*
Think of them as being part of the same computer system, with the technician
being a rather slow, but high-capacity, data bus. Well, that's the general idea, anyway.
Hmmmm. I find this distinction highly artificial.
Data are the raw materials of information.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
In article <bo**********@elf.eng.bsdi.com>,
Chris Torek <no****@elf.eng.bsdi.com> wrote: On a typical RISC we get something like:
mov x, reg # assuming x is already in a register
asr reg, 31, reg # where asr is arithmetic shift right
and reg, 3, reg # for divisor == 4
add reg, x, reg
asr reg, 2, reg # again for divisor == 4
# final result is now in "reg"
On a PowerPC, you get:
int test (int x) { return x / 4; }
00000000: 7C601670 srawi r0,r3,2 // r0 = r3 >> 2
00000004: 7C600194 addze r3,r0 // r3 = r0 + 0 + carry
00000008: 4E800020 blr // Return
goose wrote: Mark McIntyre <ma**********@spamcop.net> wrote in message
news:<j9********************************@4ax.com>. .. On Thu, 6 Nov 2003 07:59:34 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
>goose wrote:
>
>> Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message
>> news:<bo**********@oravannahka.helsinki.fi>...
>>>
>>> TIWITAW.
>>
>> <all confused>
>
>FWIW, IUWJM
"for what its worth", and then ?
"I Understood What Joona Meant."
The J was the clue.
BUAATOO, IR.
??
Yeah, that's got me stumped as well.
goose,
tia :-)
In my country, that's the name of a drink. :-)
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Greetings.
In article <qm*************@newssvr14.news.prodigy.com>, Roose wrote: 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?
--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you
Greetings.
In article <d3********************************@4ax.com>, Mark McIntyre
wrote: On Mon, 03 Nov 2003 20:39:39 GMT, in comp.lang.c , Alan Connor
<zz****@xxx.yyy> wrote:
Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.
Killfiled for N days.
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
--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you
Richard Heathfield <do******@address.co.uk.invalid> scribbled the following: goose wrote: Mark McIntyre <ma**********@spamcop.net> wrote in message
news:<j9********************************@4ax.com>. .. BUAATOO, IR.
??
Yeah, that's got me stumped as well.
But Understanding Ain't Always That Object-Oriented, I Remember.
What do I win? =)
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"We sorcerers don't like to eat our words, so to say."
- Sparrowhawk
On 2003-11-07, Christian Bau <ch***********@cbau.freeserve.co.uk> wrote: In article <bo**********@elf.eng.bsdi.com>,
Chris Torek <no****@elf.eng.bsdi.com> wrote:
On a typical RISC we get something like:
mov x, reg # assuming x is already in a register
asr reg, 31, reg # where asr is arithmetic shift right
and reg, 3, reg # for divisor == 4
add reg, x, reg
asr reg, 2, reg # again for divisor == 4
# final result is now in "reg"
On a PowerPC, you get:
int test (int x) { return x / 4; }
00000000: 7C601670 srawi r0,r3,2 // r0 = r3 >> 2
00000004: 7C600194 addze r3,r0 // r3 = r0 + 0 + carry
00000008: 4E800020 blr // Return
Can someone remind me what the on-topic lesson was? Here's my stab:
* For unsigned integral types, shift vs. multiply/divide by powers
of 2 are equivalent in C.
* For signed integral types, shift vs. multiply/divide by powers
of 2 in C depends on the implementation. If you want strictly
conforming code, you must use divide.
Did I get that right?
-- James
"Roose" <no****@nospam.nospam> wrote: "Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:3f****************@news.nl.net...
For an example where assuming that "integer" is equivalent to "pointer"
leads to a bug, assume that a pointer is six bytes and the best
available integer four.
I'm aware of the pitfalls of assuming pointers are integers.
Then you also know how unwise it is to teach beginners to assume that
they are equivalent. They might get bitten by this unportable
assumption, and (justly!) blame you for leading them astray.
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.
When you already _have_ non-ISO code which buggers about with pointers
and integers, it is indeed often more efficient to solve only those
cases which cause problems, if only because maintenance programmers are
mortal, too, and can unwittingly introduce new bugs.
However, when you write new code, it is both simpler and more robust to
create code which doesn't make unportable assumptions like that. Needing
to keep track of which integer is supposed to represent which pointer,
and vice versa, is often a source of bugs.
Now suppose that your manager, who never uses the program but wants to
demonstrate it to a customer, happens to have a wheel bit set, causing
his address space to be in the upper reaches of memory, which means that
in his case the higher-order bytes of his pointers are _not_ all zero,
unlike the usual case...
I'm not too familiar with wheel bits, but I would suggest that this bug
could quickly found out by any rudimentary testing.
<sound of hilarity from the galeries>
Like the manager doing a dry run before presenting to customers.
We're talking about a _manager_ here, remember. He _will_ test exactly
those parts of the program which don't expose the bugs.
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.
I think it is entirely likely that bugs which are caused by mixing up
pointers and integers in a non-ISO-compatible way will be avoided by
coding in an ISO-compatible way.
As I said, I would prefer to incur the cost of portability when the feature
is needed.
Ah, and there's the crux. I don't think you'll be able to show many
examples of when it is necessary to assume that "a pointer is a kind of
integer" in the first place. In fact, I think you'll be hard pushed to
come up with any at all where that assumption even makes the code more
legible or easier to write, let alone where it's a necessity. If you
think you can, feel free.
Richard
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:bo**********@oravannahka.helsinki.fi: Richard Heathfield <do******@address.co.uk.invalid> scribbled the
following: goose wrote: Mark McIntyre <ma**********@spamcop.net> wrote in message
news:<j9********************************@4ax.com>. ..
BUAATOO, IR.
??
Yeah, that's got me stumped as well.
But Understanding Ain't Always That Object-Oriented, I Remember.
What do I win? =)
Could someone give the FARG a call (if they're still around), we have a new
cognitive-science challenge for them!
Ian Woods
James Hu wrote:
On 2003-11-07, Christian Bau <ch***********@cbau.freeserve.co.uk> wrote: In article <bo**********@elf.eng.bsdi.com>,
Chris Torek <no****@elf.eng.bsdi.com> wrote:
On a typical RISC we get something like:
mov x, reg # assuming x is already in a register
asr reg, 31, reg # where asr is arithmetic shift right
and reg, 3, reg # for divisor == 4
add reg, x, reg
asr reg, 2, reg # again for divisor == 4
# final result is now in "reg"
On a PowerPC, you get:
int test (int x) { return x / 4; }
00000000: 7C601670 srawi r0,r3,2 // r0 = r3 >> 2
00000004: 7C600194 addze r3,r0 // r3 = r0 + 0 + carry
00000008: 4E800020 blr // Return
Can someone remind me what the on-topic lesson was? Here's my stab:
* For unsigned integral types, shift vs. multiply/divide by powers
of 2 are equivalent in C.
* For signed integral types, shift vs. multiply/divide by powers
of 2 in C depends on the implementation. If you want strictly
conforming code, you must use divide.
You can shift right,
if you have a signed type which only receives non negative
values during the program.
I have heapsort function which does that with a ptrdiff_t type.
unsigned char *cbase, *left, *right, *parent, *child;
ptrdiff_t offset;
size_t odd_mask, bytes;
while (compar(child, parent) > 0) {
BYTE_SWAP(parent, child);
offset = parent - cbase + size;
child = parent;
parent -= (offset & odd_mask ? size + offset : offset) >> 1;
}
--
pete
Richard Heathfield wrote:
Mark McIntyre wrote:
But thats fine - its not a pointer either... :-)
The Standard disagrees with you.
I disagree that it disagrees.
In order to compare p to NULL, you must
convert p to a pointer type (see quote above, plus 6.3.2.3-4).
I'm doubtful that you could convert a null pointer constant
to a pointer type without storing it somewhere....
You make a better case than I thought existed.
Lacking the time right now to
make a detailed study of the matter,
so I hope someone else picks it up.
I'm not quite so doubtful as you are about the conversion.
After all, on some implementations it's a no-op.
Would you suggest that, say, 0 is an object?
The regular conversion rules don't apply to (pointer = 0).
If they did, then (integer = 0, pointer = 0)
would be the same as (pointer = integer = 0).
--
pete
Ian Woods <ne******@wuggynocaps.org> scribbled the following: Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:bo**********@oravannahka.helsinki.fi: Richard Heathfield <do******@address.co.uk.invalid> scribbled the
following: goose wrote:
Mark McIntyre <ma**********@spamcop.net> wrote in message
news:<j9********************************@4ax.com>. ..
> BUAATOO, IR.
?? Yeah, that's got me stumped as well.
But Understanding Ain't Always That Object-Oriented, I Remember.
What do I win? =)
Could someone give the FARG a call (if they're still around), we have a new
cognitive-science challenge for them!
Sorry, I don't understand. What's the FARG?
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Bad things only happen to scoundrels."
- Moominmamma
Richard Bos <rl*@hoekstra-uitgeverij.nl> scribbled the following: "Roose" <no****@nospam.nospam> wrote: "Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:3f****************@news.nl.net... > For an example where assuming that "integer" is equivalent to "pointer"
> leads to a bug, assume that a pointer is six bytes and the best
> available integer four.
I'm aware of the pitfalls of assuming pointers are integers.
Then you also know how unwise it is to teach beginners to assume that
they are equivalent. They might get bitten by this unportable
assumption, and (justly!) blame you for leading them astray.
Roose must be one of those who believe it is right to teach people to
do things the wrong way first, and then later tell them out of the
blue: "Everything I previously taught you is wrong! Forget all about
it! Do things this way instead!". I can never understand how such
teaching could possibly be more favourable than teaching how to do
things right from the start.
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr
Joona I Palaste <pa*****@cc.helsinki.fi> wrote: Ian Woods <ne******@wuggynocaps.org> scribbled the following: Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:bo**********@oravannahka.helsinki.fi: Richard Heathfield <do******@address.co.uk.invalid> scribbled the
following:
goose wrote:
> Mark McIntyre <ma**********@spamcop.net> wrote in message
> news:<j9********************************@4ax.com>. ..
>> BUAATOO, IR.
>
> ??
Yeah, that's got me stumped as well.
But Understanding Ain't Always That Object-Oriented, I Remember.
What do I win? =)
Could someone give the FARG a call (if they're still around), we have a new
cognitive-science challenge for them!
Sorry, I don't understand. What's the FARG?
Fluid Analogies Research Group
--
Irrwahn
(ir*******@freenet.de) This thread has been closed and replies have been disabled. Please start a new discussion. |
