Re: C programming on ARM

Wilco Dijkstra wrote:
"CBFalconer" <cbfalconer@xxxxxxxxx> wrote in message news:47A11649.3D617492@xxxxxxxxxxxx
Wilco Dijkstra wrote:
... snip ...
My point was that the bitpatterns of all pointer types are the
same for all addresses in the address space.
Not necessarily so. void* carries all the information, apart from
the object type. void* bitpattern is identical with the char*
bitpattern, but after that there are no limits.

You're talking about what the C language standards guarantee.
I'm talking about how compilers implement the language. On a
byte addressable architecture you can rely on the one I mentioned
above. The fact is most programs rely on this whether the standard
permits it or not...


It's a fair point that there is a difference what you can rely on for real, practical C and what the standards say. You can happily rely on things like 2's complement arithmetic, and data sizes being 8, 16, 32, 64 bits - if you are programming a dinosaur mainframe, you are probably aware of the fact!

And often when programming, you know exactly what compiler and target you are using, and can program accordingly rather than writing generic code.

However, you *can't* rely on pointers working like you describe in general - not in embedded programming. Aside from alignment problems (which may mean that using the pointer does not "just work", even if conversions back and forth do), there are many architectures with different pointer types and different memory spaces. These don't fit well with C (which expects a single memory space), but they are the reality we live with. On an AVR Mega256, a general flash pointer will 24 bits, while a ram pointer will be 16 bits. On some architectures you get "far" and "near" pointers. There are some that have a section of bit-addressable memory, with a different pointer type. You can't rely on these things having a consistent pointer size - you should not even rely on the C requirement of a "void *" supporting them all (embedded compilers don't always follow the standards if they conflict with generating good object code for real-world source code).

.

Relevant Pages

  • Re: Cannot understand the following codes
    ... is a the type of a pointer to a function that takes and int and a pointer to a t_go_measurements as arguments, and returns void. ... Starting with something x that is of FuncPointerType, you first apply dereferencing, *x, which gives you something that you can add an argument list with an int and a t_go_measurementsin, which produces void; from that you can infer the type of x, what FuncPointerType is. ... want to get some links for this type of programming. ...
    (comp.programming)
  • Re: [announcement] SYSAPI and SYSSVC for Windows
    ... That's not a bad design to create a pointer to a instance of an object. ... It's a perfectly normal C++ way of programming. ... The compiler would simply take those parameters as a string literal, ... which string literals are not. ...
    (comp.lang.ada)
  • Pointers and Teaching C++ [was Re: A little disappointed]
    ... like Java where *many* facilities such as raw pointer access / manipulation ... are removed in order to create a 'safer' language and stop programmers ... then it is probably wiser to teach programming using ... pointer access / manipulation is not a 'high level language'. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: thread specific information
    ... Some of these bugs are directly related to the aforementioned "programming techniques", so such things should always be viewed with caution. ... Heap is at best "casually" thread-specific. ... If it keeps that pointer to itself there's no reason for another thread to access it, ... Again, this effectively allocates GLOBALLY visible memory to which only one thread is granted a pointer; but there's nothing to prevent that thread from making a pointer visible to other threads, or to keep other threads from accidentally "scribbling" over the data via a random uninitialized pointer. ...
    (comp.programming.threads)
  • Re: Can I send char as array argument?
    ... Everything about programming I have learned ... > void main ... to it with a pointer. ... Your solution was to declare a 1-element array of char ...
    (comp.lang.c)