char vs int

[Merrill & Michele]

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(void){
char *p;
p=malloc(4);
strcpy(p, "tja");
printf("%s\n", p);
free(p);
return 0;
}

Why is p a char and not an int? MPJ

[Michael Mair]

Merrill & Michele wrote:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(void){
char *p;
p=malloc(4);
Check the return value of malloc. Always.
strcpy(p, "tja");
To be on the safe side, you could for example do
*p = '\0';
strncat(p,"tja",4-1);
printf("%s\n", p);
free(p);
return 0;
}

Why is p a char and not an int? MPJ

p is a char *. It is definitely not a char or int.
Please follow the simple rule of rereading your message
before you send it as we otherwise have to guess what
you could have meant apart from the on average high
level of weirdness by which many of your messages are
permeated.

My guess is:
"character constants are of type int and many functions
return int/have int parameters when we are dealing with
single characters -- why is it then that we store strings
in char arrays or memory pointed to by char * variables?"

Is that your question?
For that I have an answer.
-Michael
--
E-Mail: Mine is a gmx dot de address.

[dandelion]

"Merrill & Michele" <be********@comcast.net> wrote in message
news:yr********************@comcast.com...

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(void){
char *p;
p=malloc(4);
strcpy(p, "tja");
printf("%s\n", p);
free(p);
return 0;
}

Why is p a char and not an int? MPJ

Becuase you are copying a char-array into it using a function which requires
a char*?

[Nils O. Selåsdal]

Merrill & Michele wrote:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(void){
char *p;
p=malloc(4);
strcpy(p, "tja");
printf("%s\n", p);
free(p);
return 0;
}

Why is p a char and not an int? MPJ

Cause you, the programmer, made it a char pointer.
Which seems good, as you're coping a C string to it,
and strings are usually best manipulated as sequences
of chars, it is also what "%s" in your printf statement
would expect..

[Robert Gamble]

On Wed, 17 Nov 2004 08:40:20 -0600, Merrill & Michele wrote:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(void){
char *p;
p=malloc(4);
strcpy(p, "tja");
printf("%s\n", p);
free(p);
return 0;
}

Why is p a char and not an int? MPJ

p is a pointer to char, not a char, and this is because that is how you
defined it, why in the world would you expect it to be an int??

Rob Gamble

[Thomas Stegen]

Merrill & Michele wrote:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(void){
char *p;
p=malloc(4);
strcpy(p, "tja");
printf("%s\n", p);
free(p);
return 0;
}

Why is p a char and not an int? MPJ

Are you asking why chars are stored in variables of type char?
And p is not a char.

Honestly, I usually try to give the questioner the benefit of the doubt
and I apply a good amount of charity of interpretation, but your
question does not make sense to me. I cannot even tell if you saying
that p is of type char is a mistake or ignorance on your part.

Please tell us why you think p could have been an int (or probably
pointer to int) instead of a pointer to char. Are you by any chance
referring to the fact that getchar and getc returns ints and not chars?
(So you see, I might be beginning to understand your question after all
though I didn't when I wrote the previous paragraph. But still I need
you to ask it.)

--
Thomas.

[J.L.Cooper]

"Merrill & Michele" <be********@comcast.net> wrote:
<Snip>

int main(void){
char *p;
p=malloc(4);
strcpy(p, "tja"); <Snip>
Why is p a char and not an int? MPJ

I am going to assume that you are asking the following question.

Why do we store strings in arrays of char data types instead of arrays of
int data types?

Well I would answer that int data types while capable of holding the same
information as a char data type while doing so they are wasting X bytes of
space (size of X depends on the number of bytes in an int on the system
though on most 32 bit machines it is 4 bytes in length so there are 3 bytes
wasted.)

While this doesn't seem like much how about if you have a string buffer that
needs to store a 1024 characters. This would take up 1Kb of space using an
array of char data types but 4Kb of space (on most 32 bit machines again)
if it was using int data types.

If that is not your question then please repost with a clarified version and
I will have another go.
--------------
Jason Cooper

[Merrill & Michele]

"J.L.Cooper" <[e-mail]> wrote in message
news:cn**********@sun-cc204.lut.ac.uk...

"Merrill & Michele" <be********@comcast.net> wrote:
<Snip>

int main(void){
char *p;
p=malloc(4);
strcpy(p, "tja"); <Snip>

Why is p a char and not an int? MPJ

I am going to assume that you are asking the following question.

Why do we store strings in arrays of char data types instead of arrays of
int data types?

Well I would answer that int data types while capable of holding the same
information as a char data type while doing so they are wasting X bytes of
space (size of X depends on the number of bytes in an int on the system
though on most 32 bit machines it is 4 bytes in length so there are 3

bytes wasted.)

While this doesn't seem like much how about if you have a string buffer that needs to store a 1024 characters. This would take up 1Kb of space using an array of char data types but 4Kb of space (on most 32 bit machines again)
if it was using int data types.

If that is not your question then please repost with a clarified version and I will have another go.
--------------
Jason Cooper

Thanks all for replies. That I thought I had partitioned the choice of data
type in this question with int and char shows exactly what I don't
understand. I'll hit K&R and the FAQs and get back to you. MPJ

[Dan Pop]

In <30*************@uni-berlin.de> Michael Mair <Mi**********@invalid.invalid> writes:

Merrill & Michele wrote:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(void){
char *p;
p=malloc(4);

Check the return value of malloc. Always.

That's good advice for code that is meant to be executed. It's bad advice
for code that is meant to merely illustrate a point, because the error
checking code distracts the reader from the real purpose of the code.

strcpy(p, "tja");

To be on the safe side, you could for example do
*p = '\0';
strncat(p,"tja",4-1);

It's not any safer than the original, but it is less readable and has
higher maintenance overhead (the magical constant 4 appears in two places
instead of one).

Even in more complex examples, it is open to debate whether this is the
right thing to do: silently generating the *wrong* result is seldom a
better option than reporting an error. That's why strncat is seldom used
as a "safe" strcpy.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Merrill & Michele]

> >[OP: Why is a char * a char and not an int]

Michael Mair: [insult snipped] My guess is:
"character constants are of type int and many functions
return int/have int parameters when we are dealing with
single characters -- why is it then that we store strings
in char arrays or memory pointed to by char * variables?"
Is that your question?
For that I have an answer I would imagine that your answer is similar to K&R §5.5 . But since I don't
get it, I would welcome the answer to that question.
Nils Selasdal:
Cause you, the programmer, made it a char pointer.
Which seems good, as you're cop[y]ing a C string to it,
and strings are usually best manipulated as sequences
of chars, it is also what "%s" in your printf statement
would expect..

K&R §2.2: "There are only a few basic data types in C: char, int, float,
double."
Is char * a data type? How about int **? MPJ

[Merrill & Michele]

"Thomas Stegen" <th***********@gmail.com> wrote in message
news:30*************@uni-berlin.de...

Merrill & Michele wrote:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(void){
char *p;
p=malloc(4);
strcpy(p, "tja");
printf("%s\n", p);
free(p);
return 0;
}

Why is p a char and not an int? MPJ

Are you asking why chars are stored in variables of type char?
And p is not a char.

Honestly, I usually try to give the questioner the benefit of the doubt
and I apply a good amount of charity of interpretation, but your
question does not make sense to me. I cannot even tell if you saying
that p is of type char is a mistake or ignorance on your part.

Don't underestimate my ability to be simultaneously mistaken and ignorant.
Please tell us why you think p could have been an int (or probably
pointer to int) instead of a pointer to char. Are you by any chance
referring to the fact that getchar and getc returns ints and not chars?
(So you see, I might be beginning to understand your question after all
though I didn't when I wrote the previous paragraph. But still I need
you to ask it.)

I think you're getting at one aspect of my confusion. MPJ
..

[Michael Mair]

Merrill & Michele wrote:

[OP: Why is a char * a char and not an int]

Michael Mair:

"character constants are of type int and many functions
return int/have int parameters when we are dealing with
single characters -- why is it then that we store strings
in char arrays or memory pointed to by char * variables?"
Is that your question?
For that I have an answer

I would imagine that your answer is similar to K&R §5.5 .
But since I don't get it, I would welcome the answer to
that question.

It has been answered by others in this thread. So, here's
the short of it:
- 'a' is a character constant. A variable of type char can
hold a variable constant. The constant itself could also
be (in a non-portable way) expressed as a number in the
range [CHAR_MIN,...,CHAR_MAX]. Integer constants without
u/U, l/L or a combination are considered to be of type int.
- As characters and character constants can be (from the
C type point of view) most efficiently be stored in
char variables, we use char arrays to store more than one
of them instead of int arrays. If there is a value 0 in
this char array, we have a C string (terminated by 0, or
'\0' if you like that better).
- We only talk of "strings" if the array is a char array.
- Functions dealing with strings expect dealing with char
arrays or memory areas pointed to by char *.

Nils Selasdal:
Cause you, the programmer, made it a char pointer.
Which seems good, as you're cop[y]ing a C string to it,
and strings are usually best manipulated as sequences
of chars, it is also what "%s" in your printf statement
would expect..

K&R §2.2: "There are only a few basic data types in C:

^^^^^ char, int, float, double."
Is char * a data type? How about int **? MPJ

Yes. 'Tis.
You seem to have problems wrapping your mind around the
concept of pointers. Is this right?
If no, are you comfortable with the relationship between
pointers and arrays? Else: What do you think an array is?
Do you understand why there is a difference between
passing a variable's value or its adress?

If your actual problem is with pointers, you should try
to pin down your difficulties, have a peek at the FAQ
(most people think along similar lines when it comes
to misunderstanding pointers), reread the chapter in K&R
and come back here to ask the questions left.
Please formulate them in a succinct but precise way (if
necessary, do a definition of terms first).
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.

[Michael Mair]

Merrill & Michele wrote:

[OP: Why is a char * a char and not an int]

Michael Mair:

"character constants are of type int and many functions
return int/have int parameters when we are dealing with
single characters -- why is it then that we store strings
in char arrays or memory pointed to by char * variables?"
Is that your question?
For that I have an answer

I would imagine that your answer is similar to K&R §5.5 .
But since I don't get it, I would welcome the answer to
that question.

It has been answered by others in this thread. So, here's
the short of it:
- 'a' is a character constant. A variable of type char can
hold a character constant. The constant itself could also
be (in a non-portable way) expressed as a number in the
range [CHAR_MIN,...,CHAR_MAX]. Integer constants without
u/U, l/L or a combination are considered to be of type int.
- As characters and character constants can be (from the
C type point of view) most efficiently be stored in
char variables, we use char arrays to store more than one
of them instead of int arrays. If there is a value 0 in
this char array, we have a C string (terminated by 0, or
'\0' if you like that better).
- We only talk of "strings" if the array is a char array.
- Functions dealing with strings expect dealing with char
arrays or memory areas pointed to by char *.

Nils Selasdal:
Cause you, the programmer, made it a char pointer.
Which seems good, as you're cop[y]ing a C string to it,
and strings are usually best manipulated as sequences
of chars, it is also what "%s" in your printf statement
would expect..

K&R §2.2: "There are only a few basic data types in C:

^^^^^ char, int, float, double." Is char * a data type? How about int **? MPJ

Yes. 'Tis.
You seem to have problems wrapping your mind around the
concept of pointers. Is this right?
If no, are you comfortable with the relationship between
pointers and arrays? Else: What do you think an array is?
Do you understand why there is a difference between
passing a variable's value or its adress?

If your actual problem is with pointers, you should try
to pin down your difficulties, have a peek at the FAQ
(most people think along similar lines when it comes
to misunderstanding pointers), reread the chapter in K&R
and come back here to ask the questions left.
Please formulate them in a succinct but precise way (if
necessary, do a definition of terms first).
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.
--
E-Mail: Mine is a gmx dot de address.

[Lawrence Kirby]

On Thu, 18 Nov 2004 10:23:15 -0600, Merrill & Michele wrote:

....

K&R §2.2: "There are only a few basic data types in C: char, int, float,
double."
Is char * a data type? How about int **? MPJ

char * is a data type, but it is a derived type, not a basic type. char *
is derived from char. int ** is derived from int * which in turn is
derived from int.

Lawrence

[Mike Wahler]

"Merrill & Michele" <be********@comcast.net> wrote in message
news:lN********************@comcast.com...

K&R §2.2: "There are only a few basic data types in C: char, int, float,
double."
Is char * a data type? How about int **? MPJ

Yes, they both are types, but not 'basic types'.
They are 'derived types'.

See ISO 9899:1999 6.2.5/14 and 6.2.5/20
-MIke

[Merrill & Michele]

"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:30*************@uni-berlin.de...

Merrill & Michele wrote:

>>> [OP: Why is a char * a char and not an int]

> K&R §2.2: "There are only a few basic data types in C:
^^^^^

> char, int, float, double."

> Is char * a data type? How about int **? MPJ

Yes. 'Tis.

Your posts were identical to my eye. Am I right to think that the four
basic data types followed by any number of asterisks are unique data types?
E.g. int * is as different from int *** as a char is from a double.
You seem to have problems wrapping your mind around the
concept of pointers. Is this right?
I can't wrap my mind around a lot of things, e.g. how airfoil can lift
something like a tank, yet I fly. The problem with the K&R development
right now is that everything has to come together. I think it's more to the
point that I'm simultaneously struggling with functions. What I'd like to
do is revisit the derangement code but with the static int myrand that you
suggested. I'll have to find a hard copy of it. That I can't follow
program control through these calls is a serious hurdle.
If no, are you comfortable with the relationship between
pointers and arrays? Else: What do you think an array is?
Do you understand why there is a difference between
passing a variable's value or its adress?
o.k. on all that for the time being. That's a Fehlleistung on the spelling
of Anschrift.
If your actual problem is with pointers, you should try
to pin down your difficulties, have a peek at the FAQ
(most people think along similar lines when it comes
to misunderstanding pointers), reread the chapter in K&R
and come back here to ask the questions left.
Please formulate them in a succinct but precise way (if
necessary, do a definition of terms first).

I spent two hours in the FAQs today, one hour in K&R, and it's noon. I'm
going to see if I can find the answer at the watering hole. MPJ

[Eric Sosman]

Merrill & Michele wrote:

K&R §2.2: "There are only a few basic data types in C: char, int, float,
double."
Is char * a data type? How about int **? MPJ

Those are "derived type," as others have mentioned.
But what about `short int', `long int', and `long double'?
And then there are the `unsigned' variants ... Despite
the multi-word names, these are in no sense "derived"
types. Finally there's `void' -- which might be excluded
from the ranks of "data types" by virtue of its weirdness.

My guess is that one needs to read a little more of
K&R's context to understand what they mean by "basic."

--
Er*********@sun.com

[Merrill & Michele]

"Eric Sosman" <er*********@sun.com> wrote in message
news:cn**********@news1brm.Central.Sun.COM...
Merrill & Michele wrote:

K&R §2.2: "There are only a few basic data types in C: char, int, float,
double."
Is char * a data type? How about int **? MPJ

Those are "derived type," as others have mentioned.
But what about `short int', `long int', and `long double'?
And then there are the `unsigned' variants ... Despite
the multi-word names, these are in no sense "derived"
types. Finally there's `void' -- which might be excluded
from the ranks of "data types" by virtue of its weirdness.

My guess is that one needs to read a little more of
K&R's context to understand what they mean by "basic."
You'd be stuck reading tea leaves with the K&R context here. short, long,
signed and unsigned are mentioned along with the basic data declarations,
but I have yet to stumble across a sentence that says, "well folks, chp. 2
is long behind us, and we're going to nuance this discussion of type." And
please don't ask me why Mr. Sosman's comments don't have arrows on them.
MPJ

[pete]

Merrill & Michele wrote:

"Eric Sosman" <er*********@sun.com> wrote in message
news:cn**********@news1brm.Central.Sun.COM...
Merrill & Michele wrote:

K&R §2.2: "There are only a few basic data types in C: char, int, float,
double."
Is char * a data type? How about int **? MPJ

Those are "derived type," as others have mentioned.
But what about `short int', `long int', and `long double'?
And then there are the `unsigned' variants ... Despite
the multi-word names, these are in no sense "derived"
types. Finally there's `void' -- which might be excluded
from the ranks of "data types" by virtue of its weirdness.

void is an incomplete type, not an object type.

--
pete

[Lawrence Kirby]

On Thu, 18 Nov 2004 12:07:58 -0600, Merrill & Michele wrote:

....

Your posts were identical to my eye. Am I right to think that the four
basic data types followed by any number of asterisks are unique data types?
E.g. int * is as different from int *** as a char is from a double.

Yes int * and int *** are different types. You can't assign one to the
other and doing so wouldn't make a lot of sense. One can point to objects
of type int, the other to objects of type int **.

Lawrence

[Dan Pop]

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:

"Eric Sosman" <er*********@sun.com> wrote in message
news:cn**********@news1brm.Central.Sun.COM...

Those are "derived type," as others have mentioned.
But what about `short int', `long int', and `long double'?
And then there are the `unsigned' variants ... Despite
the multi-word names, these are in no sense "derived"
types. Finally there's `void' -- which might be excluded
from the ranks of "data types" by virtue of its weirdness.

void is an incomplete type, not an object type.

No one said it's an object type, but a valid, non-null void pointer
value can only be pointing to an object. Hence the weirdness of void.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[John Bode]

"Merrill & Michele" <be********@comcast.net> wrote in message news:<cd********************@comcast.com>...

"Eric Sosman" <er*********@sun.com> wrote in message
news:cn**********@news1brm.Central.Sun.COM...
Merrill & Michele wrote:

K&R §2.2: "There are only a few basic data types in C: char, int, float,
double."
Is char * a data type? How about int **? MPJ

Those are "derived type," as others have mentioned.
But what about `short int', `long int', and `long double'?
And then there are the `unsigned' variants ... Despite
the multi-word names, these are in no sense "derived"
types. Finally there's `void' -- which might be excluded
from the ranks of "data types" by virtue of its weirdness.

My guess is that one needs to read a little more of
K&R's context to understand what they mean by "basic."
You'd be stuck reading tea leaves with the K&R context here. short, long,
signed and unsigned are mentioned along with the basic data declarations,
but I have yet to stumble across a sentence that says, "well folks, chp. 2
is long behind us, and we're going to nuance this discussion of type." And
please don't ask me why Mr. Sosman's comments don't have arrows on them.
MPJ

You might want to look at other references as well. My primary
reference is Harbison & Steele, and here's how they organize types:

Scalar Types
Arithmetic Types
Integral Types
short, int, long, long long (signed/unsigned)
char (signed/unsigned)
_Bool
enum {...}

Floating-point Types
float, double, long double
float _Complex, double _Complex, long double _Complex,
float _Imaginary, double _Imaginary,
long double _Imaginary

Pointer Types
T *

Aggregate Types
Array Types
T [...]

Structure Types
struct {...}

Union Types
union {...}

Function Types
T (...)

Void Type
void

H&S don't try to distinguish between "basic" and "derived" types, and
I'm not sure I could do so. I've never had to worry about it in the
past. I would imagine that enum, char, short, int, long, long long,
float, double, and long double are basic types; everything else
(pointers, arrays, structs, unions, etc.) is derived from those types.

[Kevin D. Quitt]

On Thu, 18 Nov 2004 10:26:52 -0600, "Merrill & Michele"
<be********@comcast.net> wrote:

Don't underestimate my ability to be simultaneously mistaken and ignorant.

Grabbed. Generalized to be M&M corollary of Sprague's law.

Sprague's Law:
"There are three orders of magnitude more dumbshits in the world than
there can be any use for." --William Sprague

Quitt's Clarification to Sprague's Law:
"Stupid isn't not being smart; stupid is not using one's smarts."
--Kevin D. Quitt

The M&M corollary of Sprague's law:
"Don't underestimate the ability to be simultaneously mistaken and
ignorant." --Merrill & Michele

In answer to "How can people be so stupid as to...":
"We all do what we're good at." --Kevin D. Quitt
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

[Merrill & Michele]

"John Bode" <jo*******@my-deja.com> wrote in message
news:43**************************@posting.google.c om...

"Merrill & Michele" <be********@comcast.net> wrote in message

news:<cd********************@comcast.com>...

"Eric Sosman" <er*********@sun.com> wrote in message
news:cn**********@news1brm.Central.Sun.COM...
Merrill & Michele wrote:

K&R §2.2: "There are only a few basic data types in C: char, int, float, double."
Is char * a data type? How about int **? MPJ

Those are "derived type," as others have mentioned.
But what about `short int', `long int', and `long double'?
And then there are the `unsigned' variants ... Despite
the multi-word names, these are in no sense "derived"
types. Finally there's `void' -- which might be excluded
from the ranks of "data types" by virtue of its weirdness.

My guess is that one needs to read a little more of
K&R's context to understand what they mean by "basic."
You'd be stuck reading tea leaves with the K&R context here. short, long, signed and unsigned are mentioned along with the basic data declarations, but I have yet to stumble across a sentence that says, "well folks, chp. 2 is long behind us, and we're going to nuance this discussion of type." And please don't ask me why Mr. Sosman's comments don't have arrows on them.
MPJ

You might want to look at other references as well. My primary
reference is Harbison & Steele, and here's how they organize types:

Scalar Types
Arithmetic Types
Integral Types
short, int, long, long long (signed/unsigned)
char (signed/unsigned)
_Bool
enum {...}

Floating-point Types
float, double, long double
float _Complex, double _Complex, long double _Complex,
float _Imaginary, double _Imaginary,
long double _Imaginary

Pointer Types
T *

Aggregate Types
Array Types
T [...]

Structure Types
struct {...}

Union Types
union {...}

Function Types
T (...)

Void Type
void

H&S don't try to distinguish between "basic" and "derived" types, and
I'm not sure I could do so. I've never had to worry about it in the
past. I would imagine that enum, char, short, int, long, long long,
float, double, and long double are basic types; everything else
(pointers, arrays, structs, unions, etc.) is derived from those types.

I'm due to spend another $50 on a C book. Since H&S is referenced in the
FAQs, I'll go with that. MPJ

[Merrill & Michele]

"Kevin D. Quitt" <KQ**********@IEEIncUNMUNG.com> wrote in message
news:6q********************************@4ax.com...

On Thu, 18 Nov 2004 10:26:52 -0600, "Merrill & Michele"
<be********@comcast.net> wrote:

Don't underestimate my ability to be simultaneously mistaken and

ignorant.
Grabbed. Generalized to be M&M corollary of Sprague's law.

Sprague's Law:
"There are three orders of magnitude more dumbshits in the world than
there can be any use for." --William Sprague

Quitt's Clarification to Sprague's Law:
"Stupid isn't not being smart; stupid is not using one's smarts."
--Kevin D. Quitt

The M&M corollary of Sprague's law:
"Don't underestimate the ability to be simultaneously mistaken and
ignorant." --Merrill & Michele

In answer to "How can people be so stupid as to...":
"We all do what we're good at." --Kevin D. Quitt
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

Many people might find uncomfortable having one's shortcomings turned into a
"law." I like to think of it as being unafraid to leave my zone of comfort
to try a new dance. MPJ

[Joona I Palaste]

Merrill & Michele <be********@comcast.net> scribbled the following:

"Kevin D. Quitt" <KQ**********@IEEIncUNMUNG.com> wrote in message
news:6q********************************@4ax.com...

--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

Many people might find uncomfortable having one's shortcomings turned into a
"law." I like to think of it as being unafraid to leave my zone of comfort
to try a new dance. MPJ

Please snip away other people's signatures before replying, or reply
between the content and the signature. The way you did it, your reply
appears as part of Kevin's signature.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"I am looking for myself. Have you seen me somewhere?"
- Anon

[pete]

Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:

"Eric Sosman" <er*********@sun.com> wrote in message
news:cn**********@news1brm.Central.Sun.COM...

Those are "derived type," as others have mentioned.
But what about `short int', `long int', and `long double'?
And then there are the `unsigned' variants ... Despite
the multi-word names, these are in no sense "derived"
types. Finally there's `void' -- which might be excluded
from the ranks of "data types" by virtue of its weirdness.
void is an incomplete type, not an object type.

No one said it's an object type,

That's why I said it.
OP listed some object types and mentioned their variants
and then mused about why void was different.
but a valid, non-null void pointer
value can only be pointing to an object. Hence the weirdness of void.

All pointers to incomplete types are like that.
Incomplete types don't have values and
pointers to incomplete types don't have arithmetic.

--
pete

[pete]

pete wrote:

Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:

> "Eric Sosman" <er*********@sun.com> wrote in message
> news:cn**********@news1brm.Central.Sun.COM...
>
> Those are "derived type," as others have mentioned.
> But what about `short int', `long int', and `long double'?
> And then there are the `unsigned' variants ... Despite
> the multi-word names, these are in no sense "derived"
> types. Finally there's `void' -- which might be excluded
> from the ranks of "data types" by virtue of its weirdness.

void is an incomplete type, not an object type.

No one said it's an object type,

That's why I said it.

That's why I said what I said: that it's an incomplete type.

--
pete

[Dan Pop]

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:

Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:

>> "Eric Sosman" <er*********@sun.com> wrote in message
>> news:cn**********@news1brm.Central.Sun.COM...
>>
>> Those are "derived type," as others have mentioned.
>> But what about `short int', `long int', and `long double'?
>> And then there are the `unsigned' variants ... Despite
>> the multi-word names, these are in no sense "derived"
>> types. Finally there's `void' -- which might be excluded
>> from the ranks of "data types" by virtue of its weirdness.
>
>void is an incomplete type, not an object type.
No one said it's an object type,

That's why I said it.

So, you're talking out of context.
OP listed some object types and mentioned their variants
and then mused about why void was different.

but a valid, non-null void pointer
value can only be pointing to an object. Hence the weirdness of void.
All pointers to incomplete types are like that.

Yes, but void is, by far, the most important incomplete type. Few
programs use other incomplete types or pointers to them.
Incomplete types don't have values and
pointers to incomplete types don't have arithmetic.

GNU C defines pointer arithmetic on void pointers and this is a fairly
useful feature. Too bad it was ignored by the C standardisation process.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union