is possible to build some pointer array?

[yezi]

Hi, all:

I want to record some memory pointer returned from malloc, is possible
the code like below?

int memo_index[10];
int i,j;
char *tmp;

for (i=0;i<10;i++){
tmp = malloc(10);
memo_index[i] = tmp;
}

what I want to realize is "use the memo_index [10] to record each
usable memory pointer, then I just use
memo_index[i] to refer to each stuff installed in the allocated memory
/

Is it possible or some else way?

Thanks for any comments.

bin

[rupesh_533]

yezi wrote:

I want to record some memory pointer returned from malloc, is possible
the code like below?

int memo_index[10];
you want to record the address of a variable in memo_index so declare
it as a pointer.
int *memo_index[10].
int i,j;
char *tmp;

for (i=0;i<10;i++){
tmp = malloc(10);
memo_index[i] = tmp;
}

malloc will return a void pointer so type cast it and assign it to
memo_index.
for (i=0;i<10;i++)
memo_index[i]=(int *)malloc(10);
type casting depends on the way you want to use pointer.

[Keith Thompson]

ru********@rediffmail.com writes:
[...]

malloc will return a void pointer so type cast it and assign it to
memo_index.
for (i=0;i<10;i++)
memo_index[i]=(int *)malloc(10);
type casting depends on the way you want to use pointer.

No, no, no.

malloc() returns a result of type void*, which will be implicitly
converted to any pointer-to-object type. Casting the result is
unnecessary, and can mask certain errors such as forgetting to
"#include <stdlib.h>" or using a C++ compiler.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[slebetman]

ru********@rediffmail.com wrote:

yezi wrote:

I want to record some memory pointer returned from malloc, is possible
the code like below?

int memo_index[10];

you want to record the address of a variable in memo_index so declare
it as a pointer.
int *memo_index[10].

int i,j;
char *tmp;

for (i=0;i<10;i++){
tmp = malloc(10);
memo_index[i] = tmp;
}

malloc will return a void pointer so type cast it and assign it to
memo_index.
for (i=0;i<10;i++)
memo_index[i]=(int *)malloc(10);
type casting depends on the way you want to use pointer.

since tmp is a char, it should really be:

char *memo_index[10];

That is, an array of 10 char pointers. Although pointers are all the
same size, don't point to different typed data from different typed
pointers unless you really need to.

[Jack Klein]

On 8 Nov 2005 21:11:41 -0800, "sl*******@yahoo.com"
<sl*******@gmail.com> wrote in comp.lang.c:

ru********@rediffmail.com wrote:

yezi wrote:

I want to record some memory pointer returned from malloc, is possible
the code like below?

int memo_index[10];

you want to record the address of a variable in memo_index so declare
it as a pointer.
int *memo_index[10].

int i,j;
char *tmp;

for (i=0;i<10;i++){
tmp = malloc(10);
memo_index[i] = tmp;
}

malloc will return a void pointer so type cast it and assign it to
memo_index.
for (i=0;i<10;i++)
memo_index[i]=(int *)malloc(10);
type casting depends on the way you want to use pointer.

since tmp is a char, it should really be:

char *memo_index[10];

That is, an array of 10 char pointers. Although pointers are all the
same size, don't point to different typed data from different typed
pointers unless you really need to.

There is no guarantee or requirement at all in C that all pointers are
the same size. The only guarantees are:

1. Pointer to void and pointer to any of the character types have the
same size and representation. These pointers can store the full
representation of a pointer to any other object type.

2. All pointers to structures and unions have the same size
representation.

3. All pointers to functions, regardless of the return type or
argument list, have the same size.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Keith Thompson]

"sl*******@yahoo.com" <sl*******@gmail.com> writes:

ru********@rediffmail.com wrote: [...]

malloc will return a void pointer so type cast it and assign it to
memo_index.
for (i=0;i<10;i++)
memo_index[i]=(int *)malloc(10);
type casting depends on the way you want to use pointer.

(I've already commented on this.)
since tmp is a char, it should really be:

char *memo_index[10];

That is, an array of 10 char pointers. Although pointers are all the
same size, don't point to different typed data from different typed
pointers unless you really need to.

You can't assume that all pointers are the same size; there are
systems on which they aren't.

If you want a generic pointer, use void*. (char* is guaranteed to
have the same representation and alignment requirements, but that's
for historical reasons.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[slebetman]

Jack Klein wrote:

There is no guarantee or requirement at all in C that all pointers are
the same size. The only guarantees are:

1. Pointer to void and pointer to any of the character types have the
same size and representation. These pointers can store the full
representation of a pointer to any other object type.

2. All pointers to structures and unions have the same size
representation.

3. All pointers to functions, regardless of the return type or
argument list, have the same size.

Hmm, a lot of code I've seen make the assumption that 1==2. Especially
TCP/IP libraries in Linux, Windows, BSD etc. that casts a char* into
structs to extract data from a packet.

If 1!=2, then you're saying that a void pointer should not ever point
to a struct. But this is how polymorphism is usually emulated in C.
Why, even malloc( ) returns a void pointer which can be used to point
to an area of memory to store a struct.

Besides, aren't pointers just addresses into memory? Why would a CPU
differentiate between structured and unstructured bytes? I can
understand the difference of function pointers since it points to an
area of executing code, not data memory, and in some systems these are
different address spaces.

[rupesh_533]

Keith Thompson wrote:

malloc will return a void pointer so type cast it and assign it to
memo_index.
for (i=0;i<10;i++)
memo_index[i]=(int *)malloc(10);
type casting depends on the way you want to use pointer.

No, no, no.

malloc() returns a result of type void*, which will be implicitly
converted to any pointer-to-object type. Casting the result is
unnecessary, and can mask certain errors such as forgetting to
"#include <stdlib.h>" or using a C++ compiler.

Then how we should assign the memo_index[i] .
Is it like
memo_index[i]=malloc(10);
then i am getting this warning
warning: assignment makes pointer from integer without a cast

[Keith Thompson]

ru********@rediffmail.com writes:

Keith Thompson wrote:

> malloc will return a void pointer so type cast it and assign it to
> memo_index.
> for (i=0;i<10;i++)
> memo_index[i]=(int *)malloc(10);
> type casting depends on the way you want to use pointer.

No, no, no.

malloc() returns a result of type void*, which will be implicitly
converted to any pointer-to-object type. Casting the result is
unnecessary, and can mask certain errors such as forgetting to
"#include <stdlib.h>" or using a C++ compiler.

Then how we should assign the memo_index[i] .
Is it like
memo_index[i]=malloc(10);
then i am getting this warning
warning: assignment makes pointer from integer without a cast

See above. You need to add
#include <stdlib.h>
so the compiler can see the declaration of malloc(). Without that the
compiler assumes (incorrectly) that malloc() returns an int.

Using a cast tells the compiler "Trust me, I know what I'm doing". If
you don't actually know what you're doing, the compiler will get its
revenge.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

ru********@rediffmail.com wrote:

Keith Thompson wrote:

malloc() returns a result of type void*, which will be implicitly
converted to any pointer-to-object type. Casting the result is
unnecessary, and can mask certain errors such as forgetting to
"#include <stdlib.h>" or using a C++ compiler.

Then how we should assign the memo_index[i] .
Is it like
memo_index[i]=malloc(10);
then i am getting this warning
warning: assignment makes pointer from integer without a cast

Then either you have not #included <stdlib.h>, or you are not
programming in C but in an inferior clone.

Richard

[Richard Bos]

"sl*******@yahoo.com" <sl*******@gmail.com> wrote:

Jack Klein wrote:

There is no guarantee or requirement at all in C that all pointers are
the same size. The only guarantees are:

1. Pointer to void and pointer to any of the character types have the
same size and representation. These pointers can store the full
representation of a pointer to any other object type.

2. All pointers to structures and unions have the same size
representation.

3. All pointers to functions, regardless of the return type or
argument list, have the same size.

And

4. All pointers to a qualified type are the same size and representation
as the base type, and v.v.

5. Where it says "size and representation" in points 1-4, add alignment.
Hmm, a lot of code I've seen make the assumption that 1==2. Especially
TCP/IP libraries in Linux, Windows, BSD etc. that casts a char* into
structs to extract data from a packet.

If 1!=2, then you're saying that a void pointer should not ever point
to a struct.
No. A void pointer is guaranteed to be able to contain any other kind of
object pointer. The difference goes the other way 'round: a pointer to a
struct (or, for that matter, to any other type except char) may be
smaller, or require stricter alignment, than a void *. This means that
any object pointer value can be put in a void *; but a void * value can
not necessarily be assigned to any other object pointer. (One exception:
if I assign a <type> pointer value to a void *, I can always assign
_that_ void * value to any <type> pointer.)
Besides, aren't pointers just addresses into memory? Why would a CPU
differentiate between structured and unstructured bytes?

Because it can be used to speed up the code? Because certain types have
alignment requirements? Because your hardware address size addresses
36-bit words only and you want your bytes to be 9 bits?

Richard

[Simon Biber]

ru********@rediffmail.com wrote:

Keith Thompson wrote:

malloc() returns a result of type void*, which will be implicitly
converted to any pointer-to-object type. Casting the result is
unnecessary, and can mask certain errors such as forgetting to
"#include <stdlib.h>" or using a C++ compiler.
Then how we should assign the memo_index[i] .
Is it like
memo_index[i]=malloc(10);

You should multiply 10 by the size of an element of the array.

memo_index[i] = malloc(10 * sizeof *memo_index[i]);

An equivalent way of writing that is:

memo_index[i] = malloc(10 * sizeof (int));

But the first way is better, because it will continue to work if you
change the type of memo_index. There is a simple pattern: whatever you
are assigning to, add 'sizeof *' to the left of it.
then i am getting this warning
warning: assignment makes pointer from integer without a cast

You must have forgotten to write the line
#include <stdlib.h>
at the top of your program.

--
Simon.

[Simon Biber]

sl*******@yahoo.com wrote:

Jack Klein wrote:

There is no guarantee or requirement at all in C that all pointers are
the same size. The only guarantees are:

1. Pointer to void and pointer to any of the character types have the
same size and representation. These pointers can store the full
representation of a pointer to any other object type.

2. All pointers to structures and unions have the same size
representation.

3. All pointers to functions, regardless of the return type or
argument list, have the same size.

Hmm, a lot of code I've seen make the assumption that 1==2. Especially
TCP/IP libraries in Linux, Windows, BSD etc. that casts a char* into
structs to extract data from a packet.

It's not clever to use a struct type to extract data from memory,
because that struct may have different padding bytes inserted on
different C implementations (whether on the same platform or on
different platforms).
If 1!=2, then you're saying that a void pointer should not ever point
to a struct. But this is how polymorphism is usually emulated in C.
Why, even malloc( ) returns a void pointer which can be used to point
to an area of memory to store a struct.
Doing so involves a conversion from one pointer type to another. On any
system where different pointers have different representations, they
must be converted between formats when the conversion is done. This is
part of the syntax of C, it's just that most people would consider
pointer conversion as a no-op, since it is a no-op on most platforms.
Besides, aren't pointers just addresses into memory? Why would a CPU
differentiate between structured and unstructured bytes? I can
understand the difference of function pointers since it points to an
area of executing code, not data memory, and in some systems these are
different address spaces.

Some CPUs have native pointer types that address in words of more than
one byte. On such systems, it makes sense to use those native pointer
types when dealing with data types that are a multiple of the native
word size. Then, only void and char types must use an extended pointer
format, where one part is the address of the word, and the other part is
the offset within the word.

--
Simon.

[Simon Biber]

Keith Thompson wrote:

You can't assume that all pointers are the same size; there are
systems on which they aren't.

If you want a generic pointer, use void*. (char* is guaranteed to
have the same representation and alignment requirements, but that's
for historical reasons.)

If char* and void* have the same representation and alignment
requirements, does that mean they are interchangeable as
a) arguments in a variable-length argument list?
b) arguments in an unprototyped function?
c) arguments in a function called with the incorrect prototype?
d) return values of a function called with the wrong declaration?

A simple example of a) is: printf("%p\n", "hello");

Is that guaranteed to be safe?

One reason that any of the above may not be safe is if char* and void*
are customarily passed in different registers on some system.

--
Simon.

[slebetman]

Simon Biber wrote:

It's not clever to use a struct type to extract data from memory,
because that struct may have different padding bytes inserted on
different C implementations (whether on the same platform or on
different platforms).
Yeah, but this is not only common, but standard practice when dealing
with networking code. Years ago I used to write code for communication
protocols and I used to extract data from packets byte-by-byte in for
loops. It's only 2 or 3 years ago that I started writing TCP/IP code
(libpcap etc..) that I noticed that people are using structs to extract
data form packets. Since it is so wide spread I didn't especially think
of it as 'clever' but just 'standard'.

Some CPUs have native pointer types that address in words of more than
one byte. On such systems, it makes sense to use those native pointer
types when dealing with data types that are a multiple of the native
word size. Then, only void and char types must use an extended pointer
format, where one part is the address of the word, and the other part is
the offset within the word.

Ah, I understand. Like ARM7 for instance which can only point to 32bit
alinged memory. So the compiler needs to generate code to handle
offsets in case of 8 and 16 bit data and the pointer format needs to
store this information somewhere.

[slebetman]

Richard Bos wrote:

This means that any object pointer value can be put in a void *; but a void *
value can not necessarily be assigned to any other object pointer.
(One exception: if I assign a <type> pointer value to a void *, I can always assign
_that_ void * value to any <type> pointer.)

But I don't understand how malloc can be made to work with these rules.
Doesn't malloc just return a void pointer which in normal use you
assign to a variable you want. Isn't the following *normal* code?

struct mystruct *myptr;
myptr = malloc(sizeof(myptr));

Or is what Simon Biber said true, that is, the C runtime does some
pointer conversion in the background in this case. If so what's the
difference with:

struct mystruct *myptr;
void *tmp;
tmp = malloc(sizeof(myptr));
myptr = tmp;

I don't see how malloc can be useful if you can't assign a void pointer
to a struct pointer.

[Tim Rentsch]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

"sl*******@yahoo.com" <sl*******@gmail.com> wrote:

Jack Klein wrote:

There is no guarantee or requirement at all in C that all pointers are
the same size. The only guarantees are:

1. Pointer to void and pointer to any of the character types have the
same size and representation. These pointers can store the full
representation of a pointer to any other object type.

2. All pointers to structures and unions have the same size
representation.

3. All pointers to functions, regardless of the return type or
argument list, have the same size.

And

4. All pointers to a qualified type are the same size and representation
as the base type, and v.v.

5. Where it says "size and representation" in points 1-4, add alignment.

And

6. Pointers to compatible types have the same representation etc
as each other.

Except

2'. Pointers to structures have the same representation etc as
each other; pointers to unions have the same representation etc
as each other; but pointers to structures and pointers to unions
might or might not have the same representation etc as each other.

[Tim Rentsch]

Simon Biber <ne**@ralmin.cc> writes:

Keith Thompson wrote:

You can't assume that all pointers are the same size; there are
systems on which they aren't.

If you want a generic pointer, use void*. (char* is guaranteed to
have the same representation and alignment requirements, but that's
for historical reasons.)
If char* and void* have the same representation and alignment
requirements, does that mean they are interchangeable as
a) arguments in a variable-length argument list?
b) arguments in an unprototyped function?
c) arguments in a function called with the incorrect prototype?
d) return values of a function called with the wrong declaration?

A simple example of a) is: printf("%p\n", "hello");

Is that guaranteed to be safe?

The short answers are:

a) Yes
b) Yes if the function _definition_ has no prototype; No if it does
(with the call site having no prototype in either case)
c) No
d) No

One reason that any of the above may not be safe is if char* and void*
are customarily passed in different registers on some system.

In practical terms I expect all would work on at least the
vast majority of platforms. My answers however were based on
what the Standard says about the topic.

[pete]

sl*******@yahoo.com wrote:

Isn't the following *normal* code?

struct mystruct *myptr;
myptr = malloc(sizeof(myptr));

No, but almost.

myptr = malloc(sizeof *myptr);

--
pete

[Simon Biber]

sl*******@yahoo.com wrote:

Richard Bos wrote:

This means that any object pointer value can be put in a void *; but a void *
value can not necessarily be assigned to any other object pointer.
(One exception: if I assign a <type> pointer value to a void *, I can always assign
_that_ void * value to any <type> pointer.)

But I don't understand how malloc can be made to work with these rules.
Doesn't malloc just return a void pointer which in normal use you
assign to a variable you want. Isn't the following *normal* code?

struct mystruct *myptr;
myptr = malloc(sizeof(myptr));

Yes it is normal code, apart from the wrong size as pete explained.

The conversion is implicit in the assignment from a "pointer to void" to
a "pointer to struct mystruct". The conversion is still performed,
behind the scenes. If the void* had some extra data to represent the
offset within a word, it will be stripped off when the pointer is converted.

Since malloc must return a pointer that is correctly aligned for any
data type, any offset part must logically be zero in any void* that is
returned from malloc.
Or is what Simon Biber said true, that is, the C runtime does some
pointer conversion in the background in this case. If so what's the
difference with:

struct mystruct *myptr;
void *tmp;
tmp = malloc(sizeof(myptr));
myptr = tmp;
There is no difference! In the line above, exactly the same conversion
is performed as in the previous block of code.
I don't see how malloc can be useful if you can't assign a void pointer
to a struct pointer.

I think you misunderstood somewhere. Nobody ever said you can't assign a
void pointer to a struct pointer. It's just that the two pointers may
have a different representation. When you do the assignment, the
pointers will automatically be converted as necessary.

Essentially, you don't need to worry about this unless you start doing
something dodgy, such as accessing a pointer *value* through an
expression of the wrong type.

For example,

/* Define foo as pointer to char, initialise with NULL */
char *foo = NULL;

/* Define bar as int, initialise with 42 */
int bar = 42;

/* Assign pointer to string "hello" to bar */
foo = "hello"; /* No problem */

/* Now define quux as pointer to pointer to int, and
initialise with a suitably converted pointer to foo. */

int **quux = (int **) &foo; /* Dodgy */

/* Find whatever quux points at, and assign it a pointer to bar */

*quux = &bar; /* Undefined Behaviour, but will succeed in
changing foo's value on most systems. */

Here, even accessing *quux was undefined behaviour, since it was
attempting to access a value of type (char *) through an expression of
type (int *).

--
Simon.

[Alan Balmer]

On 8 Nov 2005 23:19:23 -0800, ru********@rediffmail.com wrote:

Keith Thompson wrote:

> malloc will return a void pointer so type cast it and assign it to
> memo_index.
> for (i=0;i<10;i++)
> memo_index[i]=(int *)malloc(10);
> type casting depends on the way you want to use pointer.

No, no, no.

malloc() returns a result of type void*, which will be implicitly
converted to any pointer-to-object type. Casting the result is
unnecessary, and can mask certain errors such as forgetting to
"#include <stdlib.h>" or using a C++ compiler.

Then how we should assign the memo_index[i] .
Is it like
memo_index[i]=malloc(10);
then i am getting this warning
warning: assignment makes pointer from integer without a cast

I love it. You've just illustrated the error Keith was referring to.

#include <stdlib.h>
--
Al Balmer
Balmer Consulting
re************************@att.net

[Alan Balmer]

On 9 Nov 2005 01:12:15 -0800, "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

Simon Biber wrote:

It's not clever to use a struct type to extract data from memory,
because that struct may have different padding bytes inserted on
different C implementations (whether on the same platform or on
different platforms).
Yeah, but this is not only common, but standard practice when dealing
with networking code. Years ago I used to write code for communication
protocols and I used to extract data from packets byte-by-byte in for
loops. It's only 2 or 3 years ago that I started writing TCP/IP code
(libpcap etc..) that I noticed that people are using structs to extract
data form packets. Since it is so wide spread I didn't especially think
of it as 'clever' but just 'standard'.

It's workable, because there's an agreement between sender and
receiver. But it's not standard. There are useful conventions for
communication between different systems, but they are outside the
scope of c.l.c.

Some CPUs have native pointer types that address in words of more than
one byte. On such systems, it makes sense to use those native pointer
types when dealing with data types that are a multiple of the native
word size. Then, only void and char types must use an extended pointer
format, where one part is the address of the word, and the other part is
the offset within the word.

Ah, I understand. Like ARM7 for instance which can only point to 32bit
alinged memory. So the compiler needs to generate code to handle
offsets in case of 8 and 16 bit data and the pointer format needs to
store this information somewhere.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Chris Torek]

>Jack Klein wrote:

There is no guarantee or requirement at all in C that all pointers are
the same size. The only guarantees are:

1. Pointer to void and pointer to any of the character types have the
same size and representation. These pointers can store the full
representation of a pointer to any other object type.

2. All pointers to structures and unions have the same size
representation.

3. All pointers to functions, regardless of the return type or
argument list, have the same size.

(Actually #3 is an overstatement: they can have different sizes as
long as the "bigger" pointers can be stored in the "smaller" ones
temporarily without loss of information when converted back to the
"bigger" ones.)

In article <11**********************@o13g2000cwo.googlegroups .com>,
sl*******@yahoo.com <sl*******@gmail.com> wrote:Hmm, a lot of code I've seen make the assumption that 1==2.
I assume "1==2" is shorthand for some kind of reference to items 1
and 2 in Jack Klein's list, although I am not quite sure what. Still:
Especially TCP/IP libraries in Linux, Windows, BSD etc. that casts
a char* into structs to extract data from a packet.
It is worth noting two things about the BSD code and everything
derived from it (whether directly, as in the case of a number of
other TCP/IP implementations, or indirectly, as in the case of,
well, almost every remaining TCP/IP implementation :-) ).

First, most of the code was written in the early 1980s, before
there was any C standard at all. So the overall design does not
conform well to the standards, for historical reasons. There have
been some attempts to bring the code into the 1990s (including some
on my part, back *in* the 1990s), but with limited success.

Second, the code is in fact *not* portable. Some of this was done
deliberately: the use of ntohl() and htonl(), for instance, is
often turned into a no-op on big-endian machines in the name of
performance. This is important because the VAX has a one megahertz
CPU, and thus no computer is faster than about 1 MHz. :-)

(In other words, a lot of portability was sacrificed to the Little
Tin God of Efficiency. This may well have been the right decision
in 1983. It was, I think, wrong by 2003, if not earlier.)
If 1!=2, then you're saying that a void pointer should not ever point
to a struct. But this is how polymorphism is usually emulated in C.
Why, even malloc( ) returns a void pointer which can be used to point
to an area of memory to store a struct.
This is OK! It may help to use a little "ESP": Exaggeration of System
Parameters. Imagine for a moment that "void *" (and thus "char *" as
well, due to the "same representation" requirement for void* and char*)
each occupy one megabyte of data, while "struct S *" (for any S) uses
four bytes.

Will a four-byte "struct S *" always fit in a one-megabyte buffer?
(Sure!)

Will a one-megabyte "char *" or "void *" fit in a "struct S *"?
(Nope.) But if the four "important" bytes match up, that limited
subset of assignments *does* work:

struct S *orig;
void *tmp;
struct S *new;

orig = <some expression>;

tmp = orig; /* always works: copies 4 bytes into 1-MB buffer */

new = tmp; /* this works too: it copies the 4 "important" bytes back */

To make malloc() work, we just have to make sure that most of the
one-megabyte value is "unused", so that all the "good parts" fit:

tmp = malloc(sizeof(struct S)); /* sets all 1-MB bytes */

orig = tmp; /* copies 4 "important" bytes; works only if
the rest of the bytes really were unimportant */
Besides, aren't pointers just addresses into memory?
Pointers are typed, and have sizes. "Addresses" may or may not
have some other type and size.
Why would a CPU differentiate between structured and unstructured
bytes?

Consider the Cray or the Data General Eclipse (MV/10000). These
machines do not have 8-bit bytes as a "machine level" entity (with
a caveat for the Eclipse); instead, their CPUs address "words" --
64-bit words on the Cray, 16-bit words on the Eclipse. Word 0
contains 8 8-bit bytes (on the Cray) or 2 8-bit bytes (on the
Eclipse).

Most pointer types -- "int *", "struct S *", "double *", and so
on -- point to machine words. They need only the regular old
"machine word pointer" value that the hardware handles directly.
This points to 64 bits (on the Cray) or 16 bits (on the Eclipse).

The compiler-writers could have chosen to make CHAR_BIT 64 (on the
Cray) or 16 (on the Eclipse; the Eclipse has some extra features
that make this a particularly bad idea) -- but they chose instead
to make CHAR_BIT be 8. To do this, they had to make "char *"
(and thus "void *") "smuggle in" some extra bits, above and beyond
the "machine word" address.

On the Cray, with at least some C compilers, the extra bits are
stored near the high end of the machine address word. That is,
machine addresses 0, 1, 2, ... are represented as "byte address"
0, 1, 2, ..., so in order to identify "byte 3 of machine address
0", the needed three bits -- the ones that tell which 8-bit group
is to be used out of the 64-bit word -- are near the high end
of the address. Thus, bytes are addressed as: 0x000...0, 0x100...0,
0x200...0, 0x300...0, 0x400...0, 0x500...0, 0x600...0, 0x700...0,
0x000...1, 0x100...1, 0x200...1, and so on.

On the Eclipse, the hardware actually has support for "byte pointers".
The CPU has special instructions for converting "word pointers" to
"byte pointers" and vice versa. This "special instruction" is
actually just a one-bit shift, discarding the "I" -- indirect --
bit from the word address and introducing a byte-offset bit. So
on the Eclipse:

int *ip;
char *cp;
...
cp = malloc(N * sizeof(int));
ip = (int *)cp;

compiles to the same machine code as:

uint32_t ip, cp;
...
cp = malloc_equivalent(N * sizeof(int));
ip = cp >> 1;

Since malloc() actually returns "void *", malloc() on the Eclipse must
always return a "word-aligned" byte-pointer, whose low bit is 0, so
that "ip = cp >> 1" always discards a zero bit. That way, a later
call like:

cp = ip << 1;
free_equivalent(cp);

passes the correct number -- when ip is converted from a word
pointer to a byte pointer, the result is always word-aligned.

The old PR1ME (which may never have had an ANSI C compiler) had
32-bit "int *" machine-level pointers, and 48-bit "char *" pointers,
as all 32 bits were in use and -- as with the Cray and Eclipse --
the compiler-writers chose to make CHAR_BIT 8 anyway. This meant
the compiler needed extra bits in a "char *", in order to pick out
which byte you wanted, and that required an extra 16 bits.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Mark McIntyre]

On 8 Nov 2005 23:19:23 -0800, in comp.lang.c ,
ru********@rediffmail.com wrote:

Then how we should assign the memo_index[i] .
Is it like
memo_index[i]=malloc(10);
then i am getting this warning
warning: assignment makes pointer from integer without a cast

Then you're doing one of two things:
1) not #including stdlib.h
2) using a C++ compiler

Its vaguely possible you're using a pre-ansi compiler but thats less
likely since it would have to be 25 years old now.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On 8 Nov 2005 22:35:57 -0800, in comp.lang.c , "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

Hmm, a lot of code I've seen make the assumption that (pointers all have the same size). Especially
TCP/IP libraries in Linux, Windows, BSD etc. that casts a char* into
structs to extract data from a packet.
They're quite free to do this, on any given implementation. One
assumes that the writers of this code know their target hardware well
enough to be *absolutely sure* this will always be true.

However their code won't port to different hardware, or will port
badly, or will apparently port and then mysteriously break. .
you're saying that a void pointer should not ever point
to a struct.
Not portably.
But this is how polymorphism is usually emulated in C.
and this is heavily platform specific and nonportable.
Why, even malloc( ) returns a void pointer which can be used to point
to an area of memory to store a struct.
Malloc is a special case. Its /required/ to work like this
Besides, aren't pointers just addresses into memory? Why would a CPU
differentiate between structured and unstructured bytes?

Heavens.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Jordan Abel]

On 2005-11-09, Mark McIntyre <ma**********@spamcop.net> wrote:

On 8 Nov 2005 23:19:23 -0800, in comp.lang.c ,
ru********@rediffmail.com wrote:

Then how we should assign the memo_index[i] .
Is it like
memo_index[i]=malloc(10);
then i am getting this warning
warning: assignment makes pointer from integer without a cast
Then you're doing one of two things:
1) not #including stdlib.h
2) using a C++ compiler

The second would cause a vastly different diagnostic.
Its vaguely possible you're using a pre-ansi compiler but thats less
likely since it would have to be 25 years old now.

25 years since 1989? I think you're off by a decade - it's been 25 years
since _1980_.

Still shoulda included stdlib.h - which would include the line
char *malloc ();

char * is not an integer type, of course.

[Mark McIntyre]

On 9 Nov 2005 01:23:45 -0800, in comp.lang.c , "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

Richard Bos wrote:

This means that any object pointer value can be put in a void *; but a void *
value can not necessarily be assigned to any other object pointer.
(One exception: if I assign a <type> pointer value to a void *, I can always assign
_that_ void * value to any <type> pointer.)
But I don't understand how malloc can be made to work with these rules.

Thats not for us to understand. Any compiler that conforms to the
standard /must/ provide malloc which matches these rules. If it can't
then it isn't a C compiler.
I don't see how malloc can be useful if you can't assign a void pointer
to a struct pointer.

A pointer returned by malloc is guaranteed to be acceptable for
whatever type you need. How malloc manages that is its business. You'd
have to ask in hardware-specific groups to find out how its done on
the different architectures.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Default User]

Mark McIntyre wrote:

On 8 Nov 2005 23:19:23 -0800, in comp.lang.c ,
ru********@rediffmail.com wrote:

Then how we should assign the memo_index[i] .
Is it like
memo_index[i]=malloc(10);
then i am getting this warning
warning: assignment makes pointer from integer without a cast

Then you're doing one of two things:
1) not #including stdlib.h
2) using a C++ compiler

Not to wander too off-topic, but that's not a typical C++ diagnostic
for this case. You'd expect to see "Conversion from 'void*' to pointer
to non-'void' requires an explicit cast" or something of that sort. The
int to void* implies implicit declaration, which is not allowed in C++.

Brian

[pete]

Mark McIntyre wrote:

On 8 Nov 2005 22:35:57 -0800, in comp.lang.c , "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

you're saying that a void pointer should not ever point
to a struct.

Not portably.

I don't see anything wrong with a pointer to void
having a value which compares equal to the address of a struct,
but I don't think that's quite the same thing as pointing
to a struct.

--
pete

[Mark McIntyre]

On Wed, 9 Nov 2005 20:42:46 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote:

On 2005-11-09, Mark McIntyre <ma**********@spamcop.net> wrote:

On 8 Nov 2005 23:19:23 -0800, in comp.lang.c ,
ru********@rediffmail.com wrote: Then you're doing one of two things:
1) not #including stdlib.h
2) using a C++ compiler

The second would cause a vastly different diagnostic.

There's no way to know, since
a) C++ is offtopic here and
b) an implemetnation can emit whatever diagnostics it wants to, when
it encounters a bug.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Jordan Abel]

On 2005-11-10, Mark McIntyre <ma**********@spamcop.net> wrote:

There's no way to know, since
a) C++ is offtopic here and
b) an implemetnation can emit whatever diagnostics it wants to, when
it encounters a bug.

Yes but it would be nonsense to claim "from integer" when it's in fact
an illegal conversion from [c++] void * or [pre-ansi] char *

[slebetman]

pete wrote:

Mark McIntyre wrote:

On 8 Nov 2005 22:35:57 -0800, in comp.lang.c , "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

you're saying that a void pointer should not ever point
to a struct.

Not portably.

I don't see anything wrong with a pointer to void
having a value which compares equal to the address of a struct,
but I don't think that's quite the same thing as pointing
to a struct.

Richard Bos said this IS portable:
A void pointer is guaranteed to be able to contain any other kind of object pointer.

A void pointer can point to anything. But a struct pointer may not be
able to point to a void object except in special cases like an object
generated by malloc which is word aligned.

I think I understand now. Especially since a lot of CPUs that I design
for fun don't have byte addressing ;-)

To sum up:

1. Not all pointers are created equal.
2. Void and char pointers are compatible due to historical reasons.
3. Void pointers can point to anything.
4. Typed pointers can point to void objects only if the object is
properly aligned to not need the extra information contained in the
void pointer. That is, it only needs the 'base address'.

I've been writing code for years on various 8, 16 & 32 bit platforms
but never noticed this subtlety. Anything else I'm missing?

[slebetman]

pete wrote:

sl*******@yahoo.com wrote:

Isn't the following *normal* code?

struct mystruct *myptr;
myptr = malloc(sizeof(myptr));

No, but almost.

myptr = malloc(sizeof *myptr);

--
pete

Ah, thank you for spotting that. Of course I meant sizeof(*myptr).

[slebetman]

Alan Balmer wrote:

On 9 Nov 2005 01:12:15 -0800, "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

Yeah, but this is not only common, but standard practice when dealing
with networking code. Years ago I used to write code for communication
protocols and I used to extract data from packets byte-by-byte in for
loops. It's only 2 or 3 years ago that I started writing TCP/IP code
(libpcap etc..) that I noticed that people are using structs to extract
data form packets. Since it is so wide spread I didn't especially think
of it as 'clever' but just 'standard'.

It's workable, because there's an agreement between sender and
receiver. But it's not standard. There are useful conventions for
communication between different systems, but they are outside the
scope of c.l.c.

I think it's workable because Unix compilers supports this more than
anything else. As someone stated somewhere in this thread, most systems
inherited TCP/IP code from BSD and the BSD stack was written in the
80s. And it was also said that attempts to modernise this code was not
that succesfull. So it's mostly for historical reasons. And yes, I
know, such reasons are not really on topic here.

I have seen TCP/IP code which does not do this though (extract data via
struct pointers). They are usually written for 8 bit micros & embedded
systems.

[pete]

sl*******@yahoo.com wrote:

pete wrote:

Mark McIntyre wrote:

On 8 Nov 2005 22:35:57 -0800, in comp.lang.c ,
"sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

>you're saying that a void pointer should not ever point
>to a struct.

Not portably.

I don't see anything wrong with a pointer to void
having a value which compares equal to the address of a struct,
but I don't think that's quite the same thing as pointing
to a struct.

Richard Bos said this IS portable:

A void pointer is guaranteed to
be able to contain any other kind of object pointer.

A void pointer can point to anything.

It depends on what you mean by "point".
A pointer to void, can hold the address of any object,
but whether or not that's the same thing as "pointing"
is debatable.

http://groups.google.com/group/comp....830a15ee7c882d

In the above referenced post, quotes Douglas A. Gwyn
as saying "A void* doesn't point to *any* object!"

Doug can be wrong, but Doug's name is printed
in K&R2 and also on the C89 last public draft,
so he's just not any Bozo.

--
pete

[Keith Thompson]

"sl*******@yahoo.com" <sl*******@gmail.com> writes:
[snip]

A void pointer can point to anything. But a struct pointer may not be
able to point to a void object except in special cases like an object
generated by malloc which is word aligned.

I think I understand now. Especially since a lot of CPUs that I design
for fun don't have byte addressing ;-)

To sum up:

1. Not all pointers are created equal.
2. Void and char pointers are compatible due to historical reasons.
3. Void pointers can point to anything.
4. Typed pointers can point to void objects only if the object is
properly aligned to not need the extra information contained in the
void pointer. That is, it only needs the 'base address'.

I've been writing code for years on various 8, 16 & 32 bit platforms
but never noticed this subtlety. Anything else I'm missing?

There is no such thing as a "void object".

This is more correctly expressed in terms of conversions between
pointer types.

C99 6.3.2.3 says:

A pointer to void may be converted to or from a pointer to any
incomplete or object type. A pointer to any incomplete or object
type may be converted to a pointer to void and back again; the
result shall compare equal to the original pointer.

[...]

A pointer to an object or incomplete type may be converted to a
pointer to a different object or incomplete type. If the resulting
pointer is not correctly aligned for the pointed-to type, the
behavior is undefined. Otherwise, when converted back again, the
result shall compare equal to the original pointer. When a pointer
to an object is converted to a pointer to a character type, the
result points to the lowest addressed byte of the
object. Successive increments of the result, up to the size of the
object, yield pointers to the remaining bytes of the object.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[slebetman]

Keith Thompson wrote:

There is no such thing as a "void object".

I know that. But I didn't want to write "an area of memory accessible
via a void pointer".
OK, but my understanding of this is basically correct rignt?

[slebetman]

pete wrote:

sl*******@yahoo.com wrote:

A void pointer can point to anything.

It depends on what you mean by "point".
A pointer to void, can hold the address of any object,
but whether or not that's the same thing as "pointing"
is debatable.

http://groups.google.com/group/comp....830a15ee7c882d

In the above referenced post, quotes Douglas A. Gwyn
as saying "A void* doesn't point to *any* object!"

Doug can be wrong, but Doug's name is printed
in K&R2 and also on the C89 last public draft,
so he's just not any Bozo.

Oh wow. Didn't know there was such a long discussion on the meaning of
'point'. I'm talking form a programmer's perspective: pointing is what
pointers does. That is, 'point' is telling me where in memory something
is as oposed to an 'instance' which tells me what value that something
contains.

Anyway.. I defer to that thread on the exact definition of 'point'. But
what I meant simply was the address of an object.

[pete]

sl*******@yahoo.com wrote:

pete wrote:

sl*******@yahoo.com wrote:

A void pointer can point to anything.

Anyway.. I defer to that thread on the exact definition of 'point'.
But
what I meant simply was the address of an object.

OK. I'll pedant some more.
1. Not all pointers are created equal.
2. Void and char pointers are compatible due to historical reasons.
More better to say that they have the same representation.

"Compatible" is a technical term in C.

C99
6.2.7 Compatible type and composite type
[#1] Two types have compatible type if their types are the
same.
3. Void pointers can point to anything.
.... to any object, to any byte in any object,
to one past the last byte of an object,
but not to anywhere else, including not to a function.
4. Typed pointers can point to void objects only if the object is
properly aligned to not need the extra information contained in the
void pointer. That is, it only needs the 'base address'.

I read your discussion with Kieth.
There's no way to get a "void object" that isn't
properly aligned, so the "only if" part isn't necessary.

--
pete

[Old Wolf]

sl*******@yahoo.com wrote:

Simon Biber wrote:

It's not clever to use a struct type to extract data from memory,
because that struct may have different padding bytes inserted on
different C implementations (whether on the same platform or on
different platforms).

Yeah, but this is not only common, but standard practice when
dealing with networking code. Years ago I used to write code
for communication protocols and I used to extract data from
packets byte-by-byte in for loops. It's only 2 or 3 years ago
that I started writing TCP/IP code (libpcap etc..) that I
noticed that people are using structs to extract data form
packets. Since it is so wide spread I didn't especially think
of it as 'clever' but just 'standard'.

This is not portable, because different compilers might use a
different memory layout for the same struct.

However it is extremely convenient and leads to shorter and
easier-to-read code (hence its popularity, I guess).

Usually this technique is done with "packed" structs -- a common
compiler extension that builds a struct with no padding. Then
the code will be reliable, assuming that the data types always
have the same width of course!

Good programmers will include a few extra compile-time
checks, to make sure the structure size is what they expect,
and perhaps also that the member offsets (using the offsetof()
macro) are what they expect.

Also: note that pointing a struct pointer into a block of
chars may fail because of alignment -- the code should
either memcpy the chars into the struct, or make sure that
the chars are correctly aligned (eg. if they were allocated
by malloc).

[Old Wolf]

sl*******@yahoo.com wrote:

To sum up:

1. Not all pointers are created equal.
2. Void and char pointers are compatible due to historical reasons.
3. Void pointers can point to anything.
They can't point to functions. Although it is a very common
extension (eg. POSIX includes it) to allow void pointers to point
to functions.
4. Typed pointers can point to void objects only if the object is
properly aligned to not need the extra information contained in the
void pointer. That is, it only needs the 'base address'.
There are no "void objects", and a void pointer need not have
"extra information" (it could just be extra non-useful junk),
and 'base address' is not necessarily a part of it. Try this:

Typed pointers can point to objects iff the object is properly
aligned for that pointer type.
I've been writing code for years on various 8, 16 & 32 bit
platforms but never noticed this subtlety. Anything else
I'm missing?

Have you ever programmed on a SPARC (Sun) CPU ? They have
alignment and the program blows up if you violate it. Try this:

int main(void)
{
char *pc = malloc(10);
int *pi = (int *)(pc + 1);
*pi = 0;
}

It's possible for compilers to 'work around' this by noticing if
you do an unaligned access, and converting your code into a bunch
of instructions to work with chars. But gcc, for one, doesn't do
this by default.

Many embedded platforms also have "forced" alignment like this.
Other platforms such as IA32 allow unaligned accesses, but they
just run slower (the CPU will break it up into multiple single-
char accesses, behind the scenes).

[Richard Bos]

"sl*******@yahoo.com" <sl*******@gmail.com> wrote:

Richard Bos wrote:

This means that any object pointer value can be put in a void *; but a void *
value can not necessarily be assigned to any other object pointer.
(One exception: if I assign a <type> pointer value to a void *, I can always assign
_that_ void * value to any <type> pointer.)
But I don't understand how malloc can be made to work with these rules.
Doesn't malloc just return a void pointer which in normal use you
assign to a variable you want. Isn't the following *normal* code?

struct mystruct *myptr;
myptr = malloc(sizeof(myptr));

Yes. You're right, that's another exception, but it's also explicitly
mentioned in the Standard's definition of the memory management
functions:
# The pointer returned if the allocation succeeds is suitably aligned so
# that it may be assigned to a pointer to any type of object and then
# used to access such an object or an array of such objects in the space
# allocated (until the space is explicitly deallocated).
Or is what Simon Biber said true, that is, the C runtime does some
pointer conversion in the background in this case.

If void pointers do not have the same representation as, say, int
pointers, then the C runtime code (or the compiled program, or the
interpreter, or whatever) must do pointer conversion _every_ time a void
pointer is assigned to an int pointer, and vice versa. However, in the
cases mentioned above, the conversion _must_ succeed; in any other case,
it needn't. Unless I've forgotten an exception again :-/

Richard

[Richard Bos]

"sl*******@yahoo.com" <sl*******@gmail.com> wrote:

Keith Thompson wrote:

There is no such thing as a "void object".

I know that. But I didn't want to write "an area of memory accessible
via a void pointer".

That's called a char :-)

Richard

[pete]

pete wrote:

sl*******@yahoo.com wrote:

4. Typed pointers can point to void objects only if the object is
properly aligned to not need the extra information contained in the
void pointer. That is, it only needs the 'base address'.

I read your discussion with Kieth.
There's no way to get a "void object" that isn't
properly aligned, so the "only if" part isn't necessary.

I take that back. It's only the first byte of the malloc
reserved object that is properly aligned for every type.
If you want to assign the address of a subsequent byte
to an object type pointer,
then you do have to be careful, as you stated.

--
pete

[Michael Wojcik]

In article <11**********************@g49g2000cwa.googlegroups .com>, "sl*******@yahoo.com" <sl*******@gmail.com> writes:

Alan Balmer wrote:

On 9 Nov 2005 01:12:15 -0800, "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

Yeah, but this is not only common, but standard practice when dealing
with networking code.

For suitably restricted definitions of "standard practice", perhaps.
It's workable, because there's an agreement between sender and
receiver. But it's not standard.
I think it's workable because Unix compilers supports this more than
anything else.

There are implementations for POSIX-compliant systems (some of which
are also Unix-branded, or were back when that was an option; I'm not
sure what the current status of the "Unix" trademark is) where this
is not permissible in the general case.

The most common issue is alignment. There are many POSIX systems
with strict alignment requirements, so pointing a pointer-to-struct
to an arbitrary offset in a buffer and then dereferencing it is
likely to produce not very useful results (SIGBUS, on typical POSIX
systems, though some - eg POSIX-compliant versions of OS/400 running
ILE-mode programs - have other ways of showing their displeasure).
I have seen TCP/IP code which does not do this though (extract data via
struct pointers).

The vast majority of the comms code I've read, and certainly all I've
written (thousands of SLOC) for at least the past decade or so, don't
do this. There's no substitute for proper data marshalling. Done
right, it's completely portable (or, in some cases, portable to all
systems with the appropriate sizes and limits - complete portability
isn't always worth the cost); there's no need to know the alignment
requirements or byte ordering of the implementation. It Just Works.

While it might be nice if C had syntactic sugar for marshalling data,
it doesn't, and pretending that it does by pointing to structs where
no struct exists is a recipie for future maintenance woes. My advice
is to not allow your code to be contaminated by others' bad practices.

--
Michael Wojcik mi************@microfocus.com

Duck: No secret what's worth a hoot ought to be kept quiet.
Pogo: Secrets is usually perty doggone fascinatin'.
Duck: Egg-zackly ... it's completely illogical to keep a secret secret.
Pogo: An' unfair. -- Walt Kelly

[Michael Wojcik]

In article <11**********************@g47g2000cwa.googlegroups .com>, "sl*******@yahoo.com" <sl*******@gmail.com> writes:

To sum up:

1. Not all pointers are created equal.
2. Void and char pointers are compatible due to historical reasons.
3. Void pointers can point to anything.
4. Typed pointers can point to void objects only if the object is
properly aligned to not need the extra information contained in the
void pointer. That is, it only needs the 'base address'.

I've been writing code for years on various 8, 16 & 32 bit platforms
but never noticed this subtlety. Anything else I'm missing?

Others have already commented on the list. I'll add one item I
think is missing:

5. A pointer need not contain anything that directly corresponds to
a "machine address".

In the C implementations for the AS/400, for example, all pointers
are 128-bit objects which contain type, space, and offset informa-
tion. CPU addresses for the '400, on the other hand, are 32- or
64-bit linear quantities.
--
Michael Wojcik mi************@microfocus.com

It's like being shot at in an airport with all those guys running
around throwing hand grenades. Certain people function better with
hand grenades coming from all sides than other people do when the
hand grenades are only coming from inside out.
-- Dick Selcer, coach of the Cinci Bengals

[Mark McIntyre]

On Thu, 10 Nov 2005 00:59:41 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote:

On 2005-11-10, Mark McIntyre <ma**********@spamcop.net> wrote:

There's no way to know, since
a) C++ is offtopic here and
b) an implemetnation can emit whatever diagnostics it wants to, when
it encounters a bug.

Yes but it would be nonsense to claim "from integer" when it's in fact
an illegal conversion from [c++] void * or [pre-ansi] char *

Yea, but so what? Thats a QOI issue, the compiler could emit a warning
stating that your nipples explode with delight if it so desired.

Nethack anyone ?

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Default User]

Mark McIntyre wrote:

Yea, but so what? Thats a QOI issue, the compiler could emit a warning
stating that your nipples explode with delight if it so desired.

Yeah, but you don't answer similar questions about C diagnostics that
way. Look, you were not informative about a different language, no
biggie. All you had to say was, "Oh, ok, whatever."

Brian

--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

[Mark McIntyre]

On 10 Nov 2005 22:40:04 GMT, in comp.lang.c , "Default User"
<de***********@yahoo.com> wrote:

Mark McIntyre wrote:

Yea, but so what? Thats a QOI issue, the compiler could emit a warning
stating that your nipples explode with delight if it so desired.

Yeah, but you don't answer similar questions about C diagnostics that
way. Look, you were not informative about a different language, no
biggie. All you had to say was, "Oh, ok, whatever."

Whatever
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----