"Mastering C Pointers"....

[Keith Thompson]

OK, suppose you want to serialize a group of structs, which contain pointersn
to each other (a graph). In game programming, for getting data into the
game, it's a common idiom to subtract the base address in the PC tools,
store it on disk, and rebind the pointers at runtime in the game engine by
adding back a new base address. You can't do that without understanding the
equivalence, since of course you only read ints from binary files at first.

Of course this is not portable, but it works on 3 game consoles, and I would
contend that there is way to the exact same thing on ANY platform (with the
bit masking/arithmetic being slightly different, etc.)

If all the structs are part of a single object (e.g., a single chunk
of memory allocated by malloc()), the kind of thing you describe can
be done portably. For each pointer, cast it to char* and subtract the
base address of the enclosing object to get the byte offset of the
object referenced by the pointer.

On the other hand, if it's not practical for all your structs to be
part of the same object (e.g., you want to malloc() them individually)
the kind of mapping and serialization you describe would depend on the
details of how malloc() allocates memory. I don't know enough about
the inner workings of typical heap implementations to know whether
this would be practical, but I suspect there's enough variation to
make it difficult.

You mention subtracting the base address; where does this base address
come from?

If non-portable code really is the best solution for your application,
by all means write non-portable code. Wherever possible, keep it
isolated in a small number of modules, and write the majority of your
application as portably as you can. This will make your job easier
when you need to port it to another platform; the code you have to
modify will be small and contained.

I don't think anybody here has claimed that all C code must be
strictly conforming, or that non-portable code is evil. Non-portable
code is sometimes necessary. But I've found that clean code tends to
be portable, and vice versa. If you develop the right habits, writing
portable code really isn't all that difficult. But when you write
code that depends on the characteristics of a particular system,
you've left the scope of this newsgroup, and if you have any questions
about it, you're more likely to get correct answers in a newsgroup
devoted to that system.

[...]

Can you explain how an error in not writing standard C might result in such
a bug?

Not specifically, but imagine a program that operates on a pointer in
a manner that only works if pointers are just integers. When the
program is ported to a system where that's not the case, it generates
pointer values that point to random locations in memory. If it writes
a value through such a pointer, it can clobber some arbitrary
variable. Sometimes this may be harmless, but sometimes, depending on
the circumstances, the result can be drastic.

Failure to check against buffer overflow is actually a much more
common way for this kind of thing to happen, but anything that might
generate an invalid pointer value can cause problems like this.

 

[Irrwahn Grausewitz]

[top-posting fixed][Please snip signatures when replying. Do it manually if your
news-reader is defective.]

Again, this is completely transparent.

It was meant to be transparent. I'm not into playing hide and seek,
neither here nor anywhere else. If you can't deal with this - well,
follow your own advice and killfile me.

 

[Irrwahn Grausewitz]

[top-posting fixed]
[Please snip signatures when relying.]

It's completely transparent. If I were a troll, then you just let common
sense run its course. It's because you think I actually something valuable
to say, that competes with your jack-off C standard knowledge, that you must
repeatedly, vehemently insist that I'm a troll.

No, it's simply because you keep dispensing (at least partly) incorrect
information.

And, to which I would respond, as in the previous thread -- if I'm a troll,
then follow your own netiquette and killfile me. I don't care to be
responded to by people who don't think that I have something valuable to
say.

If you really don't care, as you say, then why not plonk me in the first
place?

Note that you can killfile me, safe with the knowledge that there will be
plenty of others to nitpick. Really.

Not so: if everybody would do so, there would be nobody left to correct
your errors. Ever heard of Kant?

I'm not just addressing Grausewitz here, but everyone who is flaming Alan
for killfiling one of your Gods.

You're most certainly referring to Alan killfiling Richard Heathfield
here? Well, AFAICT Heathfield is neither a god, nor even god-like.
*But* he has an impressive knowlegde of C and I like his style of
explaining difficult matters to others.

And I'm not going to mention all the other regular and/or knowledgeable
contributors to this group, but only for the sake of brevity...

A big thank-you to all of you for providing help and information, and
for patiently pointing out errors and correcting misconceptions. In the
last twelve weeks I learned more about ISO C than in the ten years
before.

P.S. by jack-off, I don't mean technically wrong or even uninteresting, just
that it's obviously not helping the bigger picture. It just serves to show
off to everyone how much you know.

Not so. Looking at my (short) posting history it seems to me I showed
how much I still have to learn about writing correct C. (This is not
meant to be understatement, it's merely my impression.) Alas, I'm eager
to learn, and being corrected is part of the learning process. Sadly
(for you), it appears that you are neither able to deal with being
corrected by others nor able to accept the simple conventions that help
making c.l.c a very useful institution. You just don't know what you
are missing, honestly. The same applies for poor Alan Connor as well.

Finally, this is going to be my last post in this unholy thread.
Back to C now?!?

Regards

 

[pete]

Alan Connor wrote:

What's a "register (qualified) object"?

"register" is a keyword.
Do you know what "keyword" means ?

 

[Nick Keighley]

I've changed the title because I think Roose may have raised an
interesting subject. And we might get away from the "Did"-"Didn't"
style of discussion.

Roose, could you try and adhere to some usenet conventions?
1. don't top-post
2. leave in the attributions

Before responding, I'd appreciate it if you answer the questions you ignored
from my posts... otherwise I'm not going to bother responding to your post,
either.



What percent of the total number of C programs in the world do you think are
correct in this sense?

I don't think anyone can hazard a guess at this. The percentage is
high in
clc. Probably wildly variable in the rest of the world.

Was your first C program correct in this sense?

if you mean a "hello world". Probably. A substantial (non-toy)
program? No.

Would it have taken more
time and effort to make it correct, knowing what you knew then?

yup, lots more. The main problem was not knowing what I didn't know. I
mean
I didn't even realise which areas I was ignorant in.

- void main()
- reliance on byte ordering
- a ptr *will* go in an int
- cast malloc()

etc.

[...] What do you
think the OP is interested in doing, _at this stage in the game_?

writing programs that work, and writing better programs in the future.
(you seem to be of the (common) school of thought that omits step 2).

[...] Do think
he is interested in reading the C standard, before having written anything
substantial or understanding pointers at a practical level?

No sarcasm there, just answer honestly.

why not try both? Why not write the program as best you can then
accept the constructive criticism of more experienced C programmers?
Hell this applies
to *everything* from programming to cooking to riding a bike. It's the
people who think they know it all that are the hardest to teach.

Maybe I got off to a bad start. The first programming language I
learnt was
Algol-60. I read the Revised Report. Maybe that spoilt me. I've always
tried to read the appropriate standard since (I couldn't manage the
Algol-68 Standard for some reason...).

<rest of post snipped off>


--
Nick Keighley

"ALGOL 60 was a language so far ahead of its time that it
was not only an improvement on its predecessors but also
on nearly all its successors".
--C.A.R. Hoare

 

[Mark Gordon]

On Mon, 03 Nov 2003 00:29:05 GMT, in comp.lang.c , Alan Connor


I have no control over what alibis.com stick on after my sig, which is
three lines long.


Its that or ntl's servers. Believe me, you don't want to use ntl's
news servers for more than about ten seconds.

You could use news.individual.net (formerly news.cis.dfn.de) for text
groups. They are free and provide a decent news feed. I used them as my
main news server for a while when I was connecting though NTL.

 

[Nick Keighley]

Let me preface this with some meta-comments. If your goal is to learn C, by
all means go ahead and dive right into the C language. You only learn by
making mistakes

never get a job in bomb disposal

<snip>

 

[Lew Pitcher]

Alan Connor wrote:
[snip]

Thanks. Dont' get it.

Please fix your sig, Lew. It's over 4 lines and I'll have to killfile you
for 30 days if I see it again.

Imagine how heartbroken I feel.

It's your loss, Alan, not mine.


--

Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

 

[Lew Pitcher]

... snip ...



Which doesn't answer his question. The above is a penalty for
using register qualification, which actually means "I think this
variable would be better handled in a register". It is only a
suggestion, and the compiler need not pay any attention to it,
other than to enforce the above penalty. With modern optimizers
it is usually better not used.

Rather than confuse Alan with extraneous information (Alan can get confused
at times), I attempted to answer his literal question. I decided that the
explanation that 'register' was a hint to the compiler that may have a
vestigal machine-language impact (and thus the language restrictions) was
perhaps going a bit too far.

Given that the 'register' keyword has a limited number of features wrt the C
language (as opposed to it's implementation on any given platform), and that
the most significant of these features is the restriction that the code
cannot take the address of a register variable, I thought that a simple
illustration would be in order.

Alan isn't known for reading complex explanations; he's likely to "killfile"
any respondant that attempts to answer in that manner.


--

Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

 

[Ed Morton]

Mark McIntyre wrote:

By the way, are you also known as roose? I'm suspicious of your sudden
appearance in this thread, and your evident agreement with a troll.
Apologies if I'm maligining you but you see my point?

Alan has been posting to the comp.unix.questions and comp.unix.shell
newsgroups for a while now, and I've never seen Roose in either. A
couple of months back Alan mentioned in one that he was interested in
learning C so I suggested he lurk in comp.lang.c for a few weeks to get
a feel for the group and its participants before posting anything. I've
never seen Roose in either of those UNIX NGs, and I'm certain Alan
doesn't know enough C to post the responses we see from Roose. The
postings from Alan here wrt interacting with the experts have been
precisely in-line with his interactions in those other NGs (frequent
flame-wars and threats of killfiling) whereas the postings from Roose
have not had the same tone.

So, I'm 99% sure they are different people. Alan - I hope you don't
tajke this the wrong way as I have nothing against you personally and I
don't think I'm saying anything you wouldn't agree with, I just wanted
to clear up the identify confusion.

Ed.

 

[Morris Dovey]

Roose wrote:
Sheldon Simms wrote (attribution restored):

This is a straw man. Any program, of critical nature or not,
is tested, and these types of errors don't even take testers
to figure out.

It's not a "straw man" to those who actually develop such
systems, however. Sticking to Sheldon's examples: I've written
code that flies in the McDonnell Douglas MD11, code that
controlled communications for NASA's TIROS-N boost (launch) and
orbital modes, code that performs fast and precise chemical
analysis of any human body fluid for medical diagnosis, code that
determines whether a merchant should accept your check in payment
for goods/services, and code that performs equity and option
trades on a major stock exchange. I can assure you from first
hand experience that my entire perspective was considerably
changed by accepting responsibility for the lives and well-being
of more people than I will ever even /meet/ in my lifetime.

The code simply won't work when you try it for the first time.
If you want to make an error-free program for one device, it
is probably safer to find out the specifics of your hardware,
and program to that. Rather than coding in 100% "standard
ANSI C" and hoping the compiler does the right thing. If not,
then it will at least save you a lot of time.

It's a good thought - but Murphy says otherwise. I'll be happy to
provide you with specific examples if you really need them.

The language standard isn't there to be opressively restrictive
(my own initial impression!) but to provide a base level
commonality of understanding between compiler writers and
compiler users. It's not sufficient to merely hope that the
compiler does the right thing - it's an /absolute requirement/.
While it may not be apparent from a games perspective, lives and
fortunes depend on that requirement being met.

But if one ventures outside that realm of understanding codified
by the standard, then the amount of risk introduced becomes huge.
Undefined behavior, even when it produces hoped-for results in
the specific conditions tested, may produce totally unacceptable
results if even a single new condition is introduced.
Implementation defined behavior is subject to change with a new
compiler version or a change in compiler vendor. Any such change
introduces the risk of an unacceptable result. The only way a
programmer can influence that risk is to avoid implementation
defined behavior altogether.

The responsible programmer must be aware of the risks and to do
that must know what's nailed down by the standard, what's
implementation defined, and what constitutes undefined behavior.

Again, this pretty much has nothing to do with the C language,
and is more of a QA question.

I sincerely hope you take time to pause and reconsider this
assertion. It /is/ a QA question; but it also has a /lot/ to do
with detailed knowledge of the language used (C or otherwise).

 

[BruceS]

I'm sure Richard has been a second year. At most secondary schools,
thats called "being a second year". At twelve, fancy names tend to be
avoided. Admittedly at my school it was called "being in Shell" but
thats another story.
At college its called "being a second year". First years are freshers,
third years are finalists unless they're doing mod lang, in which case
they're abroad, groping foreign 6th formers, or Divvers, in which case
they're drunk.

(IOW Sophomore is an americanism not in use over here...)

I'd hoped that was the case. Thanks for the clarification.

 

[Alan Balmer]

Fine. If you launch a smear campaign against anyone here, I will be
happy to killfile your ass.

Because of the last couple of messages, I've just reviewed your
postings to the group. It seems that you've insulted the regulars,
including a few world-class experts, encouraged the current resident
troll, threatened to killfile anyone who doesn't quite meet your
expectations (do you really imagine they care?) and claimed you
couldn't understand explanations which were precise and on-topic.
Perhaps you would be better served in alt.com.lang.learn.c-c++.

As for this group, I suggest you just killfile everyone except Roose.
Bye.

 

[Guest]

Let me just dispatch all of these flames toward Alan about me being a troll,
and his judgement and whatnot, with one comment...

Just wanted to mention that while these people are willing to restrict
their assault on you to this newsgroup, they can be extremely vindictive
and are willing to take this assault beyond the confines of USENET
should you persist.

Whether you like it or not Richard H, et. al. are well respected and
influential C programmers and are willing to use this respect and
influence to smack other people down when they see fit.

You cannot win. You will only harm yourself. They will not stop.


--

 

[Joona I Palaste]

(e-mail address removed) scribbled the following:

Just wanted to mention that while these people are willing to restrict
their assault on you to this newsgroup, they can be extremely vindictive
and are willing to take this assault beyond the confines of USENET
should you persist.

Whether you like it or not Richard H, et. al. are well respected and
influential C programmers and are willing to use this respect and
influence to smack other people down when they see fit.

You cannot win. You will only harm yourself. They will not stop.

What in the bloody blazes are you babbling about? You make it sound like
we have some sort personal vendetta against Roose, and would assault him
*in real life* if we ever met him. You must have us confused with the
mafia.

 

[CBFalconer]

Uh, I'm not exactly sure what a symlink is, but if it is anything
like a Windows shortcut, there is definitely an analogy there.

The windows shortcut just stores the location of a file. A
"pointer" to it. An address. The address is the _path name_. In
C, the "address" is basically an integer, indicating where in a
huge array of memory the variable is.

Wrong again, or at least over simplified. Apart from the fact
that you can express any collection of bits as an integer of some
size or other, nothing specifies the makeup of a pointer. It can
be a scrap of paper that says "look in Annies right hand", for all
you know. However, it must have certain properties, and those are
spelled out in the C standard.

On the other hand, if the machine has a linear address space, a
pointer might very well be implemented FOR THAT MACHINE as an
integer in the range of that address space.

There are many properties of integers that pointers do not have.
For an elementary example, you cannot add two pointers. However,
under certain restrictions, you can subtract one pointer from
another and get an integer. But it probably won't be the integer
you expect, unless you understand the rules in the first place.
So for an initial look, assume that "Here there be dragons", and
that they consider you a crunchy tasty morsel.

So my advice to the OP (whom you quoted, but rudely snipped any
attribution for) is to learn the first few rules for working with
pointers and don't try to stretch them without a fuller
understanding. Pointers can be created in various ways,
incremented and decremented, and sometimes compared for equality.
If they are valid they can be dereferenced.

 

[CBFalconer]

.... snip ...

OK, suppose you want to serialize a group of structs, which
contain pointers to each other (a graph). In game programming,
for getting data into the game, it's a common idiom to subtract
the base address in the PC tools, store it on disk, and rebind
the pointers at runtime in the game engine by adding back a new
base address. You can't do that without understanding the
equivalence, since of course you only read ints from binary
files at first.

Of course this is not portable, but it works on 3 game consoles,
and I would contend that there is way to the exact same thing on
ANY platform (with the bit masking/arithmetic being slightly
different, etc.)

Yet, by knowing the true properties of pointers, it is quite
possible to serialize that entire graph, store it, and later
restore it in a completely portable manner. It may take a little
longer, but that is the nature of avoiding dangerous shortcuts.

Just consider a system where multiple processes are occurring, so
that the pointers returned by malloc are not self-consistent
within any single process. This will violently point out that
pointers are not integers.

 

[Default User]

Oh, how threatening. Nobody here cares about trolls plonking
respectable and responsible posters in favour of other trolls.
Honestly.

Alan is actually correct about that. As the .sig has a couple blank
lines in it, it could be brought up to code with no loss of content.




Brian Rodenborn

 

[James Hu]

Can you explain how an error in not writing standard C might result in such
a bug?

If the non-standard C code exists in a code path that was only triggered
under that scenario.

-- James

 

[Lew Pitcher]

Alan is actually correct about that. As the .sig has a couple blank
lines in it, it could be brought up to code with no loss of content.

Point taken.

As you can see, I've reduced my signature to exactly four lines in
conformance with Netiquette standards.