Re: "Mastering C Pointers"....

From: Roose (nospam_at_nospam.nospam)
Date: 11/05/03 

Date: Wed, 05 Nov 2003 07:10:34 GMT

"Keith Thompson" <kst@cts.com> wrote in message
news:lzu15k8jsh.fsf@cts.com...
> "Roose" <nospam@nospam.nospam> writes:
> 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.

Good point.

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

Suppose they are all structs of the same type that are stored in an array.
Then the base address would be the address of the first object. The whole
collection would be allocated by a single call to malloc.

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

I can agree with that, but my impression is that this reasonable stance is
not the one that the majority of those in this newsgroup take.

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

I undestand this, but again my contention is that such bugs would be quite
obvious. Code that depends on this simply would not work when ported and
tested for this first time. But as a practical matter, there is a large
percentage of systems (if anyone would like to offer a guess, I would be
interested), where you can assume this.

But my larger point stands, that for pedagogical purposes, it is a useful,
concrete statement to say that a pointer is not unlike an array index. An
integer. Yes there can be other bits set, and so forth. But if you were a
C programmer who was NOT aware of this fact, I would seriously question you.

Roose

Relevant Pages

  • Re: Explications for malloc ang some questions about pointers
    ... A pointer is a thing that contains the address of some ... block of memory somewhere. ... "malloc" allocates a number of bytes and returns a pointer to ... You have to go through the lists a_tmp and b_tmp, ...
    (comp.lang.c)
  • Re: compile
    ... which allocates memory on a garbage-collected heap. ... which identifies some pointer or GCMalloc'd structure as ... in compilation with dummy arguments so as to fake a call to a routine ...
    (comp.lang.lisp)
  • Re: segfault w/ block, but not file scope
    ... >> int main ... When you define this pointer a file scope, ... allocates the necessary memory. ...
    (comp.lang.c)
  • Re: allocating memory for array of pointers to char
    ... char **), note that callocallocates all-bits-zero memory, and all- ... bits-zero is not guaranteed to be a null pointer. ... that which actually declares the pointers and allocates ... the length of a char pointer is sizeof. ...
    (comp.lang.c)
  • Re: Is this math test too easy?
    ... > communications glitch; one of the more laughable cartoons ... it was loaded into physical memory and, ... > Or one can interpret the character string as one of the values ... A pointer to an integer? ...
    (sci.math)
Loading