By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,962 Members | 1,767 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,962 IT Pros & Developers. It's quick & easy.

curious about array initialization.

P: n/a
say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).

Is this compiler dependent or random?

Thanks

Apr 22 '06 #1
Share this Question
Share on Google+
30 Replies


P: n/a
questions? wrote:
say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).

Is this compiler dependent or random?

Thanks

I would imagine that it would be compiler-dependant, but I don't know
the Standard nearly as well as a lot of people here.

You can't assume that your arrays will be initialized to 0, so the
specific reason that you can't is for the most part irrelevant.
Apr 23 '06 #2

P: n/a
"questions?" <un************@hotmail.com> writes:
say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).


If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type). If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.

--
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.
Apr 23 '06 #3

P: n/a

Keith Thompson wrote:
"questions?" <un************@hotmail.com> writes:
say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).


If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type). If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.


What do you mean by static storage duration? Are you referring to array
declaration as the one given above?

Also, I have tried to run the code in DevC++ 4.9.9.2:
#include <stdio.h>

int main() {
int i;

struct random_struct{
char name[10];
int month[12];

} mystruct;

for (i=0; i<10; i++) {
printf("%d\t%c\n", mystruct.month[i], mystruct.name[i]);
}

getchar();

return 0;
}
---------------------------------

Here is the output. Neither the integer array, nor char were
initialized to 0. You cannot assume that. So just preinitialize
everything that you are using to avoid any problems. Check out
memset(). I think memset(&mystruct, 0, sizeof(mystruct)); should do the
job for the whole structure at once, but double check that.

-1 `
2009252814 #
2293528 $
8
2293728
2009291924 \
2009145456 +
-1 w
2009252579
2009315348

Regards

Apr 23 '06 #4

P: n/a
bobrics wrote:

Keith Thompson wrote:
"questions?" <un************@hotmail.com> writes:
say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}
If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0',
or NULL depending on
the type).
If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.
What do you mean by static storage duration?


He definitely means something.
Are you referring to array
declaration as the one given above?
Can't tell, without seeing the object definition.

Also, I have tried to run the code in DevC++ 4.9.9.2:
#include <stdio.h>

int main() {
int i;

struct random_struct{
char name[10];
int month[12];

} mystruct;

for (i=0; i<10; i++) {
printf("%d\t%c\n", mystruct.month[i], mystruct.name[i]);
}

getchar();

return 0;
}
---------------------------------

Here is the output. Neither the integer array, nor char were
initialized to 0.


Try new.c instead.

Here is the output.

0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0

The integer array, and char were initialized to 0.
You can assume that, for external object definitions,
because they have static duration.

/* BEGIN new.c */

#include <stdio.h>

struct random_struct {
char name[10];
int month[12];
} mystruct;

int main(void)
{
int i;

for (i=0; i<10; i++) {
printf("%d\t%c\n", mystruct.month[i], '0' + mystruct.name[i]);
}
return 0;
}

/* END new.c */
--
pete
Apr 23 '06 #5

P: n/a
"bobrics" <bo*****@gmail.com> writes:
Keith Thompson wrote:
"questions?" <un************@hotmail.com> writes:
> say I have a structure which have an array inside.
>
> e.g.
>
> struct random_struct{
> char name[10];
> int month[12];
> }
>
> if the array is not intialized by me, in a sense after I allocated a
> memory for the structure, will the integer array be initialized to 0
> for all entries? (e.g. month[0]-month[11] are all equal 0).
If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type). If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.


What do you mean by static storage duration? Are you referring to array
declaration as the one given above?


No, the declaration above declares a type, not an object, so it has no
storage duration.

An object with static storage duration lives until the program
finishes. An object with automatic storage duration ceases to exist
at the end of the block or function in which it's declared.

An object declared outside any function has static storage duration.
An object declared inside a function has automatic storage duration
unless it's declared with the keyword "static".

The reason only objects with static storage duration are initialized
to zero is basically implementation convenience. On many (most?)
implementations, objects with static storage duration are allocated in
a contiguous block that's zeroed all at once when the program is first
loaded. For automatic objects to be initialized to zero, the compiler
would have to generate additional initialization code that's executed
whenever the scope (e.g., the containing function) is entered.
Also, I have tried to run the code in DevC++ 4.9.9.2:
#include <stdio.h>

int main() {
int i;

struct random_struct{
char name[10];
int month[12];

} mystruct;
mystruct has automatic storage duration, so it's not initialized.
for (i=0; i<10; i++) {
printf("%d\t%c\n", mystruct.month[i], mystruct.name[i]);
}

getchar();

return 0;
}

[...]

If you want to initialize it to zero, you can always do so explicitly:

struct random_struct{
char name[10];
int month[12];
} mystruct = { 0 };

-
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.
Apr 23 '06 #6

P: n/a

Keith Thompson wrote:
"bobrics" <bo*****@gmail.com> writes:
Keith Thompson wrote:
"questions?" <un************@hotmail.com> writes:
> say I have a structure which have an array inside.
>
> e.g.
>
> struct random_struct{
> char name[10];
> int month[12];
> }
>
> if the array is not intialized by me, in a sense after I allocated a
> memory for the structure, will the integer array be initialized to 0
> for all entries? (e.g. month[0]-month[11] are all equal 0).

If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type). If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.


What do you mean by static storage duration? Are you referring to array
declaration as the one given above?


No, the declaration above declares a type, not an object, so it has no
storage duration.

An object with static storage duration lives until the program
finishes. An object with automatic storage duration ceases to exist
at the end of the block or function in which it's declared.

An object declared outside any function has static storage duration.
An object declared inside a function has automatic storage duration
unless it's declared with the keyword "static".

The reason only objects with static storage duration are initialized
to zero is basically implementation convenience. On many (most?)
implementations, objects with static storage duration are allocated in
a contiguous block that's zeroed all at once when the program is first
loaded. For automatic objects to be initialized to zero, the compiler
would have to generate additional initialization code that's executed
whenever the scope (e.g., the containing function) is entered.
Also, I have tried to run the code in DevC++ 4.9.9.2:
#include <stdio.h>

int main() {
int i;

struct random_struct{
char name[10];
int month[12];

} mystruct;


mystruct has automatic storage duration, so it's not initialized.
for (i=0; i<10; i++) {
printf("%d\t%c\n", mystruct.month[i], mystruct.name[i]);
}

getchar();

return 0;
}

[...]

If you want to initialize it to zero, you can always do so explicitly:

struct random_struct{
char name[10];
int month[12];
} mystruct = { 0 };

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


Thanks for the nice explanation. Cool!

Apr 24 '06 #7

P: n/a
Keith Thompson wrote:
If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type).


I think of {0} as being the universal default initializer
for static objects.

--
pete
Apr 25 '06 #8

P: n/a
Keith Thompson wrote:
"bobrics" <bo*****@gmail.com> writes:
Keith Thompson wrote:
"questions?" <un************@hotmail.com> writes:
> say I have a structure which have an array inside.
>
> e.g.
>
> struct random_struct{
> char name[10];
> int month[12];
> }
>
> if the array is not intialized by me, in a sense after I allocated a
> memory for the structure, will the integer array be initialized to 0
> for all entries? (e.g. month[0]-month[11] are all equal 0).

If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type). If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.


What do you mean by static storage duration? Are you referring to array
declaration as the one given above?


No, the declaration above declares a type, not an object, so it has no
storage duration.

An object with static storage duration lives until the program
finishes.


Since main is not recursively callable, the compiler is allowed to
allocate its autos "as if" they were static, thus making them have
program lifetime. (This might be useful if the call stack space is
more precious than your data segment in your environment.) Or
alternatively, one can argue that the program lifetime is always under
the scope of main, meaning that its autos have duration of the whole
program.

I would instead say, that a static *variable* is something either with
file scope (declared outside of any function) or an auto with a static
declaration. General static objects also include initialization values
with implicit storage (such as inline strings, and potential structs,
or unions that contain them, initialized to something other than an
array) and clearly have a value that is self declared rather than being
0.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Apr 25 '06 #9

P: n/a
we******@gmail.com wrote:
Keith Thompson wrote:
An object with static storage duration lives until the program
finishes.


Since main is not recursively callable,


Says who?

comp.lang.c++ is over there -->

Richard
Apr 25 '06 #10

P: n/a
we******@gmail.com wrote:
Keith Thompson wrote:

.... snip ...

An object with static storage duration lives until the program
finishes.


Since main is not recursively callable, the compiler is allowed to
allocate its autos "as if" they were static, thus making them have
program lifetime. (This might be useful if the call stack space
is more precious than your data segment in your environment.) Or
alternatively, one can argue that the program lifetime is always
under the scope of main, meaning that its autos have duration of
the whole program.


Very sloppy, and highly inaccurate. main IS recursively callable.
It cannot in general allocate automatic storage as if static.

#include <stdio.h>

int main(int argc, char **argv) {

if (argc > 1) {
puts(argv[--argc]);
main(argc, argv);
}
return 0;
}

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Apr 25 '06 #11

P: n/a
we******@gmail.com writes:
Keith Thompson wrote: [...]
An object with static storage duration lives until the program
finishes.


Since main is not recursively callable, the compiler is allowed to
allocate its autos "as if" they were static, thus making them have
program lifetime. (This might be useful if the call stack space is
more precious than your data segment in your environment.) Or
alternatively, one can argue that the program lifetime is always under
the scope of main, meaning that its autos have duration of the whole
program.


main is recursively callable.
I would instead say, that a static *variable* is something either with
file scope (declared outside of any function) or an auto with a static
declaration. General static objects also include initialization values
with implicit storage (such as inline strings, and potential structs,
or unions that contain them, initialized to something other than an
array) and clearly have a value that is self declared rather than being
0.


I'm not sure this distinction between objects and "variables" is
useful. The standard carefully avoids defining what a "variable" is
(though it uses the word informally a few times).

--
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.
Apr 25 '06 #12

P: n/a
we******@gmail.com writes:
Since main is not recursively callable,


I think you are confusing C with C++. main() may not be called
recursively in C++, but it may in C.
--
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield
Apr 25 '06 #13

P: n/a
Keith Thompson wrote:
we******@gmail.com writes:
Keith Thompson wrote:

[...]
An object with static storage duration lives until the program
finishes.


Since main is not recursively callable, the compiler is allowed to
allocate its autos "as if" they were static, thus making them have
program lifetime. (This might be useful if the call stack space is
more precious than your data segment in your environment.) Or
alternatively, one can argue that the program lifetime is always under
the scope of main, meaning that its autos have duration of the whole
program.


main is recursively callable.


Hmmm ... so it is. I didn't realize this was a C++ only thing. I don't
quite get why there would be a difference between the two languages on
this.
I would instead say, that a static *variable* is something either with
file scope (declared outside of any function) or an auto with a static
declaration. General static objects also include initialization values
with implicit storage (such as inline strings, and potential structs,
or unions that contain them, initialized to something other than an
array) and clearly have a value that is self declared rather than being
0.


I'm not sure this distinction between objects and "variables" is
useful. The standard carefully avoids defining what a "variable" is
(though it uses the word informally a few times).


Yeah, well the "standard" is not something from which you can derive
any true understanding of anything.

The fact that certain hunks of data can exist should be a seperate
concept to a variable it happens to be sitting in. A *variable* can
cause a hunk of data to inherit const semantics at run time while a
hunk of data intrinsically in of itsef cannot change its const
semantics. So this distinction kind of matters, and it means knowing
the difference between variables, and "objects" is a prerequisite for
"getting" this.

So for example, if you have an inline string, can you return it from a
function? It depends on the attributes of the *variable* it was first
bound to. It can be returned if it was stuck in a char *, but *not* if
it is stuck in a char[]. How does one think about this without
understanding that its through the variable declaration that we
determine this?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Apr 26 '06 #14

P: n/a
we******@gmail.com writes:
Keith Thompson wrote:
we******@gmail.com writes: [...]
> I would instead say, that a static *variable* is something either with
> file scope (declared outside of any function) or an auto with a static
> declaration. General static objects also include initialization values
> with implicit storage (such as inline strings, and potential structs,
> or unions that contain them, initialized to something other than an
> array) and clearly have a value that is self declared rather than being
> 0.
I'm not sure this distinction between objects and "variables" is
useful. The standard carefully avoids defining what a "variable" is
(though it uses the word informally a few times).


Yeah, well the "standard" is not something from which you can derive
any true understanding of anything.


I certainly can. I don't know what your problem is.
The fact that certain hunks of data can exist should be a seperate
concept to a variable it happens to be sitting in. A *variable* can
cause a hunk of data to inherit const semantics at run time while a
hunk of data intrinsically in of itsef cannot change its const
semantics. So this distinction kind of matters, and it means knowing
the difference between variables, and "objects" is a prerequisite for
"getting" this.

So for example, if you have an inline string, can you return it from a
function? It depends on the attributes of the *variable* it was first
bound to. It can be returned if it was stuck in a char *, but *not* if
it is stuck in a char[]. How does one think about this without
understanding that its through the variable declaration that we
determine this?


By understanding the attributes of the objects that the program is
operating on.

By "inline string", I assume you mean a string literal. A string
literal corresponds to a static object with certain attributes as
defined in the standard. If it's "stuck in a char*", then you have an
object of type char* that points to the object. If it's "stuck in a
char[]", then you've copied the value of that object to another
object. If that object has automatic storage duration, then returning
a pointer to that object outside the object's scope can cause
undefined behavior; the origin of the value stored in that object is
no longer relevant.

This is all stuff that I learned from the standard.

I don't know what you mean by "variable", other than that it's
apparently something distinct from an object. If you can provide a
rigorous definition of the word "variable", perhaps we can discuss
this.

--
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.
Apr 26 '06 #15

P: n/a
c compiler does NOT initialize the variables.when a variable alloceted
in memory it takes random values.

Apr 26 '06 #16

P: n/a
"Typhonike" <ty*******@gmail.com> writes:
c compiler does NOT initialize the variables.when a variable alloceted
in memory it takes random values.


Incorrect, incomplete, and lacking context.

Read <http://cfaj.freeshell.org/google/>.

The correct answer has already been given in this thread.

--
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.
Apr 26 '06 #17

P: n/a
Typhonike wrote:
c compiler does NOT initialize the variables.when a variable alloceted
in memory it takes random values.


Please review the information below.

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.
Apr 26 '06 #18

P: n/a
Keith Thompson wrote:
we******@gmail.com writes:
Keith Thompson wrote:
we******@gmail.com writes: [...] > I would instead say, that a static *variable* is something either with
> file scope (declared outside of any function) or an auto with a static
> declaration. General static objects also include initialization values
> with implicit storage (such as inline strings, and potential structs,
> or unions that contain them, initialized to something other than an
> array) and clearly have a value that is self declared rather than being
> 0.

I'm not sure this distinction between objects and "variables" is
useful. The standard carefully avoids defining what a "variable" is
(though it uses the word informally a few times).
Yeah, well the "standard" is not something from which you can derive
any true understanding of anything.


I certainly can. I don't know what your problem is.


That's like saying spelling bee champions are expert linguists. A
language standard that goes out of its way to avoid the word variable
seems to me like it maybe has been built on questionable premises.
The fact that certain hunks of data can exist should be a seperate
concept to a variable it happens to be sitting in. A *variable* can
cause a hunk of data to inherit const semantics at run time while a
hunk of data intrinsically in of itsef cannot change its const
semantics. So this distinction kind of matters, and it means knowing
the difference between variables, and "objects" is a prerequisite for
"getting" this.

So for example, if you have an inline string, can you return it from a
function? It depends on the attributes of the *variable* it was first
bound to. It can be returned if it was stuck in a char *, but *not* if
it is stuck in a char[]. How does one think about this without
understanding that its through the variable declaration that we
determine this?


By understanding the attributes of the objects that the program is
operating on.

By "inline string", I assume you mean a string literal. A string
literal corresponds to a static object with certain attributes as
defined in the standard. If it's "stuck in a char*", then you have an
object of type char* that points to the object.


Well, more than that you have implicit storage. The inline string has
to actually exist as a wad of data somewhere.
[...] If it's "stuck in a
char[]", then you've copied the value of that object to another
object.
No, that's a matter of implementation.

char x[] = "xxxx";

is the same as

char x[];
memset (x, 'x', 4);
x[4] = '\0';

and a compiler might easily do that, without the requirement of the
existence of any "xxxx" "object" (actually, this is more likely with
char x[]="", for obvious reaons). Similarly, if you mismatch the size
of the array declaration with the inline string, the compiler has a
bunch of choices as to how to deal with the truncation or expansion of
the array, including the mutation of the representation of the inline
string where it is stored. Since there is no reference to the original
inline string, it does not actually have to exist, or have any property
you think it might have. There's no way for you to force the string
literal to have any particular manifestation you want it to outside of
a particular implementation.

The variable x on the other hand has all sorts of properties. Note
here that in both cases, the variable declaration tells us what the
nature of the string literal's manifestation is, not the string itself.
Understanding comes from knowing what is going on with the variable,
not the string literal.
[...] If that object has automatic storage duration, then returning
a pointer to that object outside the object's scope can cause
undefined behavior; the origin of the value stored in that object is
no longer relevant.

This is all stuff that I learned from the standard.
Yes, but there is the question of what you didn't learn.
I don't know what you mean by "variable",
Its a concept from computer programming. If you are not familliar with
computer programming, you may not have heard of it, but you can't call
yourself a computer programmer, if you don't know what a variable is.
[...] other than that it's
apparently something distinct from an object. If you can provide a
rigorous definition of the word "variable", perhaps we can discuss
this.


Independent named storage? In C I guess it would be declared
independent named storage.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Apr 27 '06 #19

P: n/a
we******@gmail.com writes:
Keith Thompson wrote:
we******@gmail.com writes:
> Keith Thompson wrote:
>> we******@gmail.com writes: [...]
>> > I would instead say, that a static *variable* is something either with
>> > file scope (declared outside of any function) or an auto with a static
>> > declaration. General static objects also include initialization values
>> > with implicit storage (such as inline strings, and potential structs,
>> > or unions that contain them, initialized to something other than an
>> > array) and clearly have a value that is self declared rather than being
>> > 0.
>>
>> I'm not sure this distinction between objects and "variables" is
>> useful. The standard carefully avoids defining what a "variable" is
>> (though it uses the word informally a few times).
>
> Yeah, well the "standard" is not something from which you can derive
> any true understanding of anything.


I certainly can. I don't know what your problem is.


That's like saying spelling bee champions are expert linguists. A
language standard that goes out of its way to avoid the word variable
seems to me like it maybe has been built on questionable premises.


Not really. The C standard uses the word "object", and describes
properties that objects have. I truly don't see how introducing the
word "variable" (presumably variables are a subset of objects?) would
be helpful.

> The fact that certain hunks of data can exist should be a seperate
> concept to a variable it happens to be sitting in. A *variable* can
> cause a hunk of data to inherit const semantics at run time while a
> hunk of data intrinsically in of itsef cannot change its const
> semantics. So this distinction kind of matters, and it means knowing
> the difference between variables, and "objects" is a prerequisite for
> "getting" this.
>
> So for example, if you have an inline string, can you return it from a
> function? It depends on the attributes of the *variable* it was first
> bound to. It can be returned if it was stuck in a char *, but *not* if
> it is stuck in a char[]. How does one think about this without
> understanding that its through the variable declaration that we
> determine this?


By understanding the attributes of the objects that the program is
operating on.

By "inline string", I assume you mean a string literal. A string
literal corresponds to a static object with certain attributes as
defined in the standard. If it's "stuck in a char*", then you have an
object of type char* that points to the object.


Well, more than that you have implicit storage. The inline string has
to actually exist as a wad of data somewhere.
[...] If it's "stuck in a
char[]", then you've copied the value of that object to another
object.


No, that's a matter of implementation.

char x[] = "xxxx";

is the same as

char x[];
memset (x, 'x', 4);
x[4] = '\0';


No, it isn't. The first form is legal; the second is not.

I think you mean:

char x[5];
memset(x, 'x', 4);
x[4] = '\0';
and a compiler might easily do that, without the requirement of the
existence of any "xxxx" "object" (actually, this is more likely with
char x[]="", for obvious reaons). Similarly, if you mismatch the size
of the array declaration with the inline string, the compiler has a
bunch of choices as to how to deal with the truncation or expansion of
the array, including the mutation of the representation of the inline
string where it is stored. Since there is no reference to the original
inline string, it does not actually have to exist, or have any property
you think it might have. There's no way for you to force the string
literal to have any particular manifestation you want it to outside of
a particular implementation.
Yes, in the case of
char x[] = "xxxx";
the compiler doesn't have to allocate storage for the string literal.
The variable x on the other hand has all sorts of properties. Note
here that in both cases, the variable declaration tells us what the
nature of the string literal's manifestation is, not the string itself.
Understanding comes from knowing what is going on with the variable,
not the string literal.


And how does calling x a "variable" rather than an "object" help
anything? x is an object that has certain properties, including a
type and a (current) value.
[...] If that object has automatic storage duration, then returning
a pointer to that object outside the object's scope can cause
undefined behavior; the origin of the value stored in that object is
no longer relevant.

This is all stuff that I learned from the standard.


Yes, but there is the question of what you didn't learn.


Of which I'm sure there's a lot. What is your point?
I don't know what you mean by "variable",


Its a concept from computer programming. If you are not familliar with
computer programming, you may not have heard of it, but you can't call
yourself a computer programmer, if you don't know what a variable is.


Now you're just being insulting.

Of course I know, in general terms, what a variable is. That's not
what I asked. I said I don't know *what you mean* by "variable".

It is not obvious what the word "variable" should mean in the context
of C. For example:

int x;
/*
* Obviously x is a variable.
*/
int arr[10];
/*
* arr is a variable.
* Is arr[0] a variable?
*/
struct {
int x;
int y;
} s;
/*
* Is s.x a variable?
*/
const int c = 42;
/*
* Is c a variable?
* It can't vary (unless you invoke undefined behavior).
* If c isn't a "variable", how useful is the word?
*/
int *ptr = malloc(sizeof *ptr);
/*
* Assuming ptr != NULL, is *ptr a variable?
*/

Replace "variable" by "object" in the above, and the answer to each of
these questions is clearly yes.
[...] other than that it's
apparently something distinct from an object. If you can provide a
rigorous definition of the word "variable", perhaps we can discuss
this.


Independent named storage? In C I guess it would be declared
independent named storage.


Independent of what?

--
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.
Apr 27 '06 #20

P: n/a
Keith Thompson wrote:
we******@gmail.com writes:
Keith Thompson wrote:
we******@gmail.com writes:
> Keith Thompson wrote:
>> we******@gmail.com writes:
[...]
>> > I would instead say, that a static *variable* is something either with
>> > file scope (declared outside of any function) or an auto with a static
>> > declaration. General static objects also include initialization values
>> > with implicit storage (such as inline strings, and potential structs,
>> > or unions that contain them, initialized to something other than an
>> > array) and clearly have a value that is self declared rather than being
>> > 0.
>>
>> I'm not sure this distinction between objects and "variables" is
>> useful. The standard carefully avoids defining what a "variable" is
>> (though it uses the word informally a few times).
>
> Yeah, well the "standard" is not something from which you can derive
> any true understanding of anything.

I certainly can. I don't know what your problem is.
That's like saying spelling bee champions are expert linguists. A
language standard that goes out of its way to avoid the word variable
seems to me like it maybe has been built on questionable premises.


Not really. The C standard uses the word "object", and describes
properties that objects have. I truly don't see how introducing the
word "variable" (presumably variables are a subset of objects?) would
be helpful.


Well, every single computer 101 student knows what variable is. It
means its a base of knowledge by which you have universal understanding
and agreement without question. It would be helpful because everyone
would know what you are talking about.

If you want a tough definition, try giving one for "object".
> The fact that certain hunks of data can exist should be a seperate
> concept to a variable it happens to be sitting in. A *variable* can
> cause a hunk of data to inherit const semantics at run time while a
> hunk of data intrinsically in of itsef cannot change its const
> semantics. So this distinction kind of matters, and it means knowing
> the difference between variables, and "objects" is a prerequisite for
> "getting" this.
>
> So for example, if you have an inline string, can you return it from a
> function? It depends on the attributes of the *variable* it was first
> bound to. It can be returned if it was stuck in a char *, but *not* if
> it is stuck in a char[]. How does one think about this without
> understanding that its through the variable declaration that we
> determine this?

By understanding the attributes of the objects that the program is
operating on.

By "inline string", I assume you mean a string literal. A string
literal corresponds to a static object with certain attributes as
defined in the standard. If it's "stuck in a char*", then you have an
object of type char* that points to the object.


Well, more than that you have implicit storage. The inline string has
to actually exist as a wad of data somewhere.
[...] If it's "stuck in a
char[]", then you've copied the value of that object to another
object.


No, that's a matter of implementation.

char x[] = "xxxx";

is the same as

char x[];
memset (x, 'x', 4);
x[4] = '\0';


No, it isn't. The first form is legal; the second is not.

I think you mean:

char x[5];
memset(x, 'x', 4);
x[4] = '\0';
and a compiler might easily do that, without the requirement of the
existence of any "xxxx" "object" (actually, this is more likely with
char x[]="", for obvious reaons). Similarly, if you mismatch the size
of the array declaration with the inline string, the compiler has a
bunch of choices as to how to deal with the truncation or expansion of
the array, including the mutation of the representation of the inline
string where it is stored. Since there is no reference to the original
inline string, it does not actually have to exist, or have any property
you think it might have. There's no way for you to force the string
literal to have any particular manifestation you want it to outside of
a particular implementation.


Yes, in the case of
char x[] = "xxxx";
the compiler doesn't have to allocate storage for the string literal.


Meaning that calling "xxxx" an object doesn't really mean anything now
does it?
The variable x on the other hand has all sorts of properties. Note
here that in both cases, the variable declaration tells us what the
nature of the string literal's manifestation is, not the string itself.
Understanding comes from knowing what is going on with the variable,
not the string literal.


And how does calling x a "variable" rather than an "object" help
anything? x is an object that has certain properties, including a
type and a (current) value.


I think it would help the OP, who I am sure understands very clearly
what a variable is, but probably does not understand what an object is.
[...] If that object has automatic storage duration, then returning
a pointer to that object outside the object's scope can cause
undefined behavior; the origin of the value stored in that object is
no longer relevant.

This is all stuff that I learned from the standard.


Yes, but there is the question of what you didn't learn.


Of which I'm sure there's a lot. What is your point?


That the standard is not something from which you can derive
understanding.
I don't know what you mean by "variable",


Its a concept from computer programming. If you are not familliar with
computer programming, you may not have heard of it, but you can't call
yourself a computer programmer, if you don't know what a variable is.


Now you're just being insulting.


Well, I'll admit that that may have been my original intent, but in
reading your follow-up, it appears as though this point seems
startlingly applicable.
Of course I know, in general terms, what a variable is. That's not
what I asked. I said I don't know *what you mean* by "variable".
I mean what it means in general terms. The concept doesn't take
different meanings in different contexts of computer programming.
We're not talking about statistics or algebra here.
It is not obvious what the word "variable" should mean in the context
of C. For example:

int x;
/*
* Obviously x is a variable.
*/
Its independent, corresponds to storage, and its named. So yes, its a
variable.
int arr[10];
/*
* arr is a variable.
Yes.
* Is arr[0] a variable?
No. arr[0] is not independent of arr, and arr[0] is not a name. In C
you can apply "const" to variables. You cannot apply const to arr[0],
unless you also apply it to all of arr simultaneously.
*/
struct {
int x;
int y;
} s;
/*
* Is s.x a variable?
*/
Similarly to arr, s.x is not independent of s, and s.x is not a name.
const int c = 42;
/*
* Is c a variable?
Yes.
* It can't vary (unless you invoke undefined behavior).
This is about computer programming concepts, not word deconstruction.
* If c isn't a "variable", how useful is the word?
Well -- it *is* a variable. Its constant, but that's a semantic. I
mean what would you call a variable that only had one value throughout
its lifetime? Or which you can prove will only have one value? That
it varies or can legally vary is not a well defined criteria, and its
obviously not what constitutes a variable.
*/
int *ptr = malloc(sizeof *ptr);
/*
* Assuming ptr != NULL, is *ptr a variable?
No, *ptr is not a name, and its not independent of ptr.
*/

Replace "variable" by "object" in the above, and the answer to each of
these questions is clearly yes.


Replace it by "storage", and the answer is also yes. (Logical
reasoning is also a good thing to have if you plan on seriously
endeavouring to be a computer programmer.)
[...] other than that it's
apparently something distinct from an object. If you can provide a
rigorous definition of the word "variable", perhaps we can discuss
this.


Independent named storage? In C I guess it would be declared
independent named storage.


Independent of what?


Of other variables.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Apr 27 '06 #21

P: n/a
we******@gmail.com writes:
Keith Thompson wrote:
we******@gmail.com writes: [...]
Not really. The C standard uses the word "object", and describes
properties that objects have. I truly don't see how introducing the
word "variable" (presumably variables are a subset of objects?) would
be helpful.


Well, every single computer 101 student knows what variable is. It
means its a base of knowledge by which you have universal understanding
and agreement without question. It would be helpful because everyone
would know what you are talking about.

If you want a tough definition, try giving one for "object".


An object is a "region of data storage in the execution environment,
the contents of which can represent values". What's so tough about
that?

[...]
Yes, in the case of
char x[] = "xxxx";
the compiler doesn't have to allocate storage for the string literal.


Meaning that calling "xxxx" an object doesn't really mean anything now
does it?


I didn't call "xxxx" an object.

A string literal is "used to initialize an array of static storage
duration and length just sufficient to contain the sequence". That
array is an object. As with any object, the compiler is free to
optimimize it away.

[...]
> Yes, but there is the question of what you didn't learn.


Of which I'm sure there's a lot. What is your point?


That the standard is not something from which you can derive
understanding.


That is manifestly untrue.

[discussion of what "variable" means snipped]

Ok, so a "variable" is a declared object that's not a component of
some other object, and a const-qualified object is still a variable.
That's not an unreasonable definition. As I've said before, I tend to
avoid using the term (at least here in comp.lang.c) because (a) the
standard doesn't define the term, and (b) different people might
define it differently. For example, someone might say that a struct
member is a variable, or that a const-qualified object isn't. I have
enough trouble understanding what you're talking about; I didn't want
to make any assumptions. For example, your use of the phrase "inline
string" for what most of us call a "string literal" didn't help
matters.

Now that we've agreed on what you mean by the term, I've lost track of
whatever point you were trying to make. But that's probably ok.

--
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.
Apr 27 '06 #22

P: n/a
Keith Thompson wrote:
we******@gmail.com writes:
Keith Thompson wrote:
we******@gmail.com writes: [...] Not really. The C standard uses the word "object", and describes
properties that objects have. I truly don't see how introducing the
word "variable" (presumably variables are a subset of objects?) would
be helpful.
Well, every single computer 101 student knows what variable is. It
means its a base of knowledge by which you have universal understanding
and agreement without question. It would be helpful because everyone
would know what you are talking about.

If you want a tough definition, try giving one for "object".


An object is a "region of data storage in the execution environment,
the contents of which can represent values". What's so tough about
that?


It has no universal agreement. Ask a practitioner of any other
programming language other than C what they think of this definition.
They will wonder why you don't just call that "storage". This is a
worthless definition, and you should not plan on teaching anyone
anything by adopting it.
Yes, in the case of
char x[] = "xxxx";
the compiler doesn't have to allocate storage for the string literal.


Meaning that calling "xxxx" an object doesn't really mean anything now
does it?


I didn't call "xxxx" an object.


Keith Thompson wrote:
"[...] A string
literal corresponds to a static object with certain attributes as
defined in the standard. If it's "stuck in a char*", then you have an
object of type char* that points to the object. If it's "stuck in a
char[]", then you've copied the value of that object to another
object. [...]"
A string literal is "used to initialize an array of static storage
duration and length just sufficient to contain the sequence". That
array is an object. As with any object, the compiler is free to
optimimize it away.
For it to be optimized away presumes it exists in the first place. It
doesn't have to. The compiler decides what to do based on how the
*variable* is declared. At best, the "string literal" exists as a
compile time element, and only gains a real manifestation as dictated
by the declaration or at the whim of the compiler developer.
[...]
> Yes, but there is the question of what you didn't learn.

Of which I'm sure there's a lot. What is your point?
That the standard is not something from which you can derive
understanding.


That is manifestly untrue.


Well, you probably have a different meaning for "understanding" than I
do.
[discussion of what "variable" means snipped]

Ok, so a "variable" is a declared object that's not a component of
some other object, and a const-qualified object is still a variable.
That's not an unreasonable definition. As I've said before, I tend to
avoid using the term (at least here in comp.lang.c) because (a) the
standard doesn't define the term,
Right, but at the same time, strstr ("comp.lang.c", "std") returns
NULL.
[...] and (b) different people might
define it differently.
Sort of like how you are redefining object? The concept of a variable
is pretty universal. I didn't pull that definition out of my ass.
[...] For example, someone might say that a struct
member is a variable, or that a const-qualified object isn't.
They could, but they'd be wrong. Its sort of like calling "Intelligent
Design" science. Subverting definitions is what allows people to try
to get away with "that depends on the meaning of the word is".
[...] I have
enough trouble understanding what you're talking about; I didn't want
to make any assumptions. For example, your use of the phrase "inline
string" for what most of us call a "string literal" didn't help
matters.
Whatever; I don't pray at K&R's altar, so why should I quote their
scripture?
Now that we've agreed on what you mean by the term, I've lost track of
whatever point you were trying to make. But that's probably ok.


The OP was having trouble understanding the initialization of
variables, and you started talking about objects and other weird things
in ways that are not appropriate for beginners. I clarified by
describing static as being applied to variables, then you went off and
said variables is not a well defined concept. So I gave the definition
for it. Google Groups is not completely worthless you know.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Apr 27 '06 #23

P: n/a
we******@gmail.com writes:
Keith Thompson wrote:
we******@gmail.com writes:
> Keith Thompson wrote:
>> we******@gmail.com writes:

[...]
>> Not really. The C standard uses the word "object", and describes
>> properties that objects have. I truly don't see how introducing the
>> word "variable" (presumably variables are a subset of objects?) would
>> be helpful.
>
> Well, every single computer 101 student knows what variable is. It
> means its a base of knowledge by which you have universal understanding
> and agreement without question. It would be helpful because everyone
> would know what you are talking about.
>
> If you want a tough definition, try giving one for "object".


An object is a "region of data storage in the execution environment,
the contents of which can represent values". What's so tough about
that?


It has no universal agreement. Ask a practitioner of any other
programming language other than C what they think of this definition.
They will wonder why you don't just call that "storage". This is a
worthless definition, and you should not plan on teaching anyone
anything by adopting it.


It's the definition in the C standard. The C standard defines the C
language. The C language is what we discuss in this newsgroup.

I don't believe you're too stupid to understand that; apparently you
just disagree with it for some reason. Presumably you're not going to
change your mind on this point, so there's no reason to continue this
discussion.

--
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.
Apr 27 '06 #24

P: n/a

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

It's the definition in the C standard. The C standard defines the C
language. The C language is what we discuss in this newsgroup.


Paul,

This is the core issue when dealing with Keith's multiple personalities.
When he's on "CLC personality," he will explicitly deny the existence of
anything outside the most current C specification that he obtained. He will
deny historical context, assembly language, mathematics, physics, and
anything else that is not specifically in the C specification. He will
argue that one is wrong even when one (like me) has posted paraphrases of
Doug Gwyn. If he is uncertain, he will then pop over to comp.std.c and get
the same answer (of course) from Doug Gwyn himself. He will then argue with
Doug Gwyn telling him he's wrong. Doug Gwyn, unlike Keith, doesn't ignore
the historical context or the fact that a standard is useless without
hardware or assembly language and frequently places his answers in such a
context. You need to think of Keith as the "Oz," aka "Wizard," in the
"Wizard of Oz." If you don't know the truth beforehand, you'll come away
believing he helped you.
Rod Pemberton
Apr 28 '06 #25

P: n/a

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

It's the definition in the C standard. The C standard defines the C
language. The C language is what we discuss in this newsgroup.


Paul,

This is the core issue when dealing with Keith's multiple personalities.
When he's on "CLC personality," he will explicitly deny the existence of
anything outside the most current C specification that he obtained. He will
deny historical context, assembly language, mathematics, physics, and
anything else that is not specifically in the C specification. He will
argue that one is wrong even when one (like me) has posted paraphrases of
Doug Gwyn. If he is uncertain, he will then pop over to comp.std.c and get
the same answer (of course) from Doug Gwyn himself. He will then argue with
Doug Gwyn telling him he's wrong. Doug Gwyn, unlike Keith, doesn't ignore
the historical context or the fact that a standard is useless without
hardware or assembly language and frequently places his answers in such a
context. You need to think of Keith as the "Oz," aka "Wizard," in the
"Wizard of Oz." If you don't know the truth beforehand, you'll come away
believing he helped you.
Rod Pemberton
Apr 28 '06 #26

P: n/a
"Rod Pemberton" <do*********@sorry.bitbuck.cmm> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

It's the definition in the C standard. The C standard defines the C
language. The C language is what we discuss in this newsgroup.


Paul,

This is the core issue when dealing with Keith's multiple personalities.

[snip]

*yawn*

--
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.
Apr 28 '06 #27

P: n/a
Keith Thompson wrote:
we******@gmail.com writes:
Keith Thompson wrote:
we******@gmail.com writes:
> Keith Thompson wrote:
>> we******@gmail.com writes:
[...]
>> Not really. The C standard uses the word "object", and describes
>> properties that objects have. I truly don't see how introducing the
>> word "variable" (presumably variables are a subset of objects?) would
>> be helpful.
>
> Well, every single computer 101 student knows what variable is. It
> means its a base of knowledge by which you have universal understanding
> and agreement without question. It would be helpful because everyone
> would know what you are talking about.
>
> If you want a tough definition, try giving one for "object".

An object is a "region of data storage in the execution environment,
the contents of which can represent values". What's so tough about
that?
It has no universal agreement. Ask a practitioner of any other
programming language other than C what they think of this definition.
They will wonder why you don't just call that "storage". This is a
worthless definition, and you should not plan on teaching anyone
anything by adopting it.


It's the definition in the C standard. The C standard defines the C
language. The C language is what we discuss in this newsgroup.


That doesn't imply that we discuss the language of the standard in this
group. Also notice that there is a group named comp.std.c that doesn't
generally cross post into this group. You *choose* to only discuss C
within the confines of the language of the standard like it was your
bible, because you are basically a religious fanatic.
I don't believe you're too stupid to understand that; apparently you
just disagree with it for some reason.


Well its hardly just me. The volume of material and other standards
that seem to think that "object" means something else is pretty large.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Apr 28 '06 #28

P: n/a
we******@gmail.com writes:
Keith Thompson wrote:
we******@gmail.com writes:
> Keith Thompson wrote:
>> we******@gmail.com writes:
>> > Keith Thompson wrote:
>> >> we******@gmail.com writes:
>> [...]
>> >> Not really. The C standard uses the word "object", and describes
>> >> properties that objects have. I truly don't see how introducing the
>> >> word "variable" (presumably variables are a subset of objects?) would
>> >> be helpful.
>> >
>> > Well, every single computer 101 student knows what variable is. It
>> > means its a base of knowledge by which you have universal understanding
>> > and agreement without question. It would be helpful because everyone
>> > would know what you are talking about.
>> >
>> > If you want a tough definition, try giving one for "object".
>>
>> An object is a "region of data storage in the execution environment,
>> the contents of which can represent values". What's so tough about
>> that?
>
> It has no universal agreement. Ask a practitioner of any other
> programming language other than C what they think of this definition.
> They will wonder why you don't just call that "storage". This is a
> worthless definition, and you should not plan on teaching anyone
> anything by adopting it.


It's the definition in the C standard. The C standard defines the C
language. The C language is what we discuss in this newsgroup.


That doesn't imply that we discuss the language of the standard in this
group. Also notice that there is a group named comp.std.c that doesn't
generally cross post into this group. You *choose* to only discuss C
within the confines of the language of the standard like it was your
bible, because you are basically a religious fanatic.


You have somehow managed to avoid having any real understanding of
this newsgroup (or of me, but that's beside the point).

The fact that the scope of this newsgroup is the C language as defined
by the ISO standards in no way implies that there's anything wrong
with things not defined by the ISO C standards. It merely means that
we choose not to discuss them here.

comp.std.c is for discussion of the standard as a document, not for
discussion of the language defined by the standard. It includes
discussions of the process used to create and update the standard, and
proposals for changing it. It's a subtle distinction, but a very
useful one.

There are many system-specific newsgroups where discussions of
system-specific issues, such as language extensions, are topical.
There also also a number of more general newsgroups, such as
comp.programming, where general programming concepts can be discussed
without limiting the discussion to a single well-defined language.

There is *one* newsgroup (two, if you count comp.lang.c.moderated)
that discusses the C programming language as defined by the ISO C
standard, plus one that discusses the standard itself. I participate
here because it happens to be an interest of mine. You apparently
aren't satisfied with that. That's just too bad.

If you want to have a newsgroup that discusses C without limiting
itself to the standard, you can advocate the creation of such a
newsgroup (or, if you want it to be in the alt hierarchy, you can just
create it yourself). I suggest writing a charter that defines the
scope of the new newsgroup, to avoid silly arguments like this one. I
won't necessarily vote for such a newsgroup, but if it's created I
might even participate; if I do, I will of course abide by the group's
charter.

I do not expect you to be willing to understand any of this.

--
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.
Apr 28 '06 #29

P: n/a

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
we******@gmail.com writes:
Keith Thompson wrote:
we******@gmail.com writes:
> Keith Thompson wrote:
>> we******@gmail.com writes:
>> > Keith Thompson wrote:
>> >> we******@gmail.com writes:
>> [...]
>> >> Not really. The C standard uses the word "object", and describes
>> >> properties that objects have. I truly don't see how introducing the >> >> word "variable" (presumably variables are a subset of objects?) would >> >> be helpful.
>> >
>> > Well, every single computer 101 student knows what variable is. It >> > means its a base of knowledge by which you have universal understanding >> > and agreement without question. It would be helpful because everyone >> > would know what you are talking about.
>> >
>> > If you want a tough definition, try giving one for "object".
>>
>> An object is a "region of data storage in the execution environment,
>> the contents of which can represent values". What's so tough about
>> that?
>
> It has no universal agreement. Ask a practitioner of any other
> programming language other than C what they think of this definition.
> They will wonder why you don't just call that "storage". This is a
> worthless definition, and you should not plan on teaching anyone
> anything by adopting it.

It's the definition in the C standard. The C standard defines the C
language. The C language is what we discuss in this newsgroup.


That doesn't imply that we discuss the language of the standard in this
group. Also notice that there is a group named comp.std.c that doesn't
generally cross post into this group. You *choose* to only discuss C
within the confines of the language of the standard like it was your
bible, because you are basically a religious fanatic.


You have somehow managed to avoid having any real understanding of


<snip>

*boring irrelevant drivel*
Rod Pemberton
Apr 29 '06 #30

P: n/a
Keith Thompson <ks***@mib.org> writes:
"Rod Pemberton" <do*********@sorry.bitbuck.cmm> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

It's the definition in the C standard. The C standard defines the C
language. The C language is what we discuss in this newsgroup.


Paul,

This is the core issue when dealing with Keith's multiple personalities.

[snip]

*yawn*


Please don't post off topic Keith : you know how angry it makes you and
Al and that fella who quotes you in his .signature.
May 2 '06 #31

This discussion thread is closed

Replies have been disabled for this discussion.