use delete to destroy primitive/object types but memory is not freed

[jimjim]

Hello,

This is a simple question for you all, I guess .
int main(){
double *g= new double;
*g = 9;
delete g;
cout<< sizeof(g)<<" "<<sizeof(double)<<" "<<sizeof(*g)<<" "<<*g<<" "<<endl;
*g = 111;
cout<< sizeof(g)<<" "<<sizeof(double)<<" "<<sizeof(*g)<<" "<<*g<<" "<<endl;
return 0;
}

The output:
4 8 8 9
4 8 8 111

Although I delete g, why is it that I can still use it and it references to
actual memory?

The same happens when creating and deleting object types with new and
delete!

Please dont answer with what you think but with what actually happens. If
you can point me to web sources I can read on this, it would have been
great!

Thank you in advance.
Regards,
jimjim

 

[Christopher Benson-Manica]

cout<< sizeof(g)<<" "<<sizeof(double)<<" "<<sizeof(*g)<<" "<<*g<<" "<<endl;
cout<< sizeof(g)<<" "<<sizeof(double)<<" "<<sizeof(*g)<<" "<<*g<<" "<<endl;

Please dont answer with what you think but with what actually happens. If
you can point me to web sources I can read on this, it would have been
great!

(comp.lang.c++ is that way ----->)

Your post is off-topic for comp.lang.c. Please visit

http://www.ungerhu.com/jxh/clc.welcome.txt
http://www.eskimo.com/~scs/C-faq/top.html
http://benpfaff.org/writings/clc/off-topic.html

for posting guidelines and frequently asked questions. Thank you.

 

[Eric Sosman]

Hello,

This is a simple question for you all, I guess .
int main(){
double *g= new double;
[...]

Stop right there: The question just becaue non-simple
for us-all here in comp.lang.c. Perhaps it would be simple
for them-all over thar in comp.lang.c++. Tread carefully
as you cross the demilitarized zone.

 

[jimjim]

I knew it was an easy question. I should have looked at a faq first.

The answer is at http://www.eskimo.com/~scs/C-faq/q7.21.html as Christopher
pointed out.

Thanks for the reply

 

[jimjim]

change new to malloc and delete to free and if you dont know the answer
visit http://www.eskimo.com/~scs/C-faq/q7.21.html as Christopher pointed
out.

 

[jimjim]

This layout http://www.lysator.liu.se/c/c-faq/c-faq-toc.html of the faq in
the previous post is easier for us the newbies in C to locate the
questions/answers ;-)

Pay attention at the top of the page. There are link to faqs that are also
extremely interesting for newbies like us to read. Most of my questions are
there!! ftp://rtfm.mit.edu/pub/usenet/news.answers/C-faq/faq as well as this
pub/usenet/comp.lang.c/ and this ftp.uu.net (directory
usenet/news.answers/C-faq/ )

 

[Alan Balmer]

change new to malloc and delete to free and if you dont know the answer
visit http://www.eskimo.com/~scs/C-faq/q7.21.html as Christopher pointed
out.

I'll tell you a secret: Eric does know the answer. When you're
off-topic, you're off-topic. Don't argue about it, just take the good
advice you are given.

Even if the simple substitution you propose actually worked (it
doesn't) there are still differences between C and C++ memory
allocation, and comp.lang.c++ is where you'll get the right answers,
reviewed by the right people.

 

[E. Robert Tisdale]

This is a simple question for you all, I guess .

int main(){
double *g = new double;

double* g = (double*)malloc(sizeof(double));

*g = 9;
delete g;

free((void*)g);

cout<< sizeof(g)<<" "<<sizeof(double)<<" "<<sizeof(*g)<<" "<<*g<<" "<<endl;

fprinf(stdout, ...

*g = 111;
cout<< sizeof(g)<<" "<<sizeof(double)<<" "<<sizeof(*g)<<" "<<*g<<" "<<endl;

fprintf(stdout, ...

return 0;
}

The output:

4 8 8 9
4 8 8 111

Although I delete g,
why is it that I can still use it and it references to actual memory?

The same happens
when creating and deleting object types with new and delete!

Please don't answer with what you think but with what actually happens.
If you can point me to web sources I can read on this,
it would have been great!

delete g;

or

free((void*)g);

delete's or free's the object to which g points.
g is still a valid [pointer] object
but the object to which it points is *not*.
Any reference to *g is *undefined* --
not defined by either the C or C++ standards
after *g is delete'd or free'd.

> cat main.cc

#include <iostream>

int main(int argc, char* argv[]) {
double* p = new double;
*p = 9;
delete p;
double* g = new double;
std::cout << sizeof(g) << ' ' << sizeof(double) << ' '
<< sizeof(*g) << ' ' << *g << std::endl;
*p = 111;
std::cout << sizeof(g) << ' ' << sizeof(double) << ' '
<< sizeof(*g) << ' ' << *g << std::endl;
return 0;
}

> g++ -Wall -ansi -pedantic -o main main.cc
> ./main

4 8 8 9
4 8 8 111

Notice that, after *p is delete'd (free'd),
the storage be allocated for another object (*g in this case).

 

[jimjim]

hen you're off-topic, you're off-topic. Don't argue about it, just take
the good advice you are given.

I cant understand why if I am off topic an answer exists in the C-faq. Of
course for the C equivalent of the C++ code I provided in my original post.
Take few steps back and look at the bigger picture please (Dont take it that
I am trying to be "clever" now please)

Even if the simple substitution you propose actually worked (it doesn't)

int main(){
int *g= malloc(sizeof(int));
*g = 9;
free(g);
printf("%d %d %d %d\n",sizeof(g),sizeof(double),sizeof(*g),*g);
*g = 111;
printf("%d %d %d %d\n",sizeof(g),sizeof(double),sizeof(*g),*g);
return 0; }

The above substitution gives me the same results. Please why dont you try to
explain to me what exactly you mean? This is a typical phainomenon in
newsgroups; people having the knowledge to answer but provide cryptic
answers. If you are not to give a clear answer to my question, its better
not to answer at all!

there are still differences between C and C++ memory allocation, and

comp.lang.c++ is where you'll get the right >answers, reviewed by the right
people.

Can you please explain to me what is the case in C. This is again a genuine
question. I just want to learn!

 

[jimjim]

ha, that was such a good example!!

Thank you

 

[Stephen Sprunk]

doesn't)

int main(){
int *g= malloc(sizeof(int));
*g = 9;
free(g);
printf("%d %d %d %d\n",sizeof(g),sizeof(double),sizeof(*g),*g);
*g = 111;
printf("%d %d %d %d\n",sizeof(g),sizeof(double),sizeof(*g),*g);
return 0; }

Do you mean *g to be an int or a double? Mixing types the way you've done
is not portable and will not work on at least one popular architecture.

The above substitution gives me the same results. Please why dont you try to
explain to me what exactly you mean? This is a typical phainomenon in
newsgroups; people having the knowledge to answer but provide cryptic
answers. If you are not to give a clear answer to my question, its better
not to answer at all!

free() is not required to release memory immediately, nor is it required to
make that memory somehow inaccessible; on most implementations it's
impossible to do that at the granularity of a single int. For example, on
unix-like systems it's common that memory can only be requested from or
released to the OS in page-sized (typically 4kB) blocks and release must be
done in LIFO order.

Accessing freed memory explicitly causes Undefined Behavior, which may in
most cases do what you expect it to do. Or it might not -- that's why it's
called "undefined".

S

 

[E. Robert Tisdale]

free() is not required to release memory immediately
nor is it required to make that memory somehow inaccessible;
on most implementations,
it's impossible to do that at the granularity of a single int.
For example, on unix-like systems it's common that
memory can only be requested from or released to the OS
in page-sized (typically 4kB) blocks
and release must be done in LIFO order.

Accessing freed memory explicitly causes Undefined Behavior,
which may in most cases do what you expect it to do.
Or it might not -- that's why it's called "undefined".

You're off-topic and out of your depth here.
The way that the OS acquires physical memory for processes
is transparent to allocating free storage in your C program.
The typical implementation of free storage is a free list
and it can and often does allow the program to allocate and free
memory at the granularity of a single int.
My GNU C compiler, for example, does this.

 

[Keith Thompson]

double* g = (double*)malloc(sizeof(double));


free((void*)g);


fprinf(stdout, ...


fprintf(stdout, ...

What a mess. Try this:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
double *g = malloc(sizeof *g);

*g = 9;
free(g);

printf("sizeof g = %d, sizeof(double) = %d, sizeof *g = %d\n",
(int)sizeof g, (int)sizeof(double), (int)sizeof *g);
*g = 111;

/*
* Note: There's no much point in repeating the printf;
* there's no way the sizes can change.
*/
printf("sizeof g = %d, sizeof(double) = %d, sizeof *g = %d\n",
(int)sizeof g, (int)sizeof(double), (int)sizeof *g);

return 0;
}

When I run this, I get:

sizeof g = 4, sizeof(double) = 8, sizeof *g = 8, *g = 9
sizeof g = 4, sizeof(double) = 8, sizeof *g = 8, *g = 111

delete's or free's the object to which g points.
g is still a valid [pointer] object
but the object to which it points is *not*.
Any reference to *g is *undefined* --
not defined by either the C or C++ standards
after *g is delete'd or free'd.

After the call to free(g), any reference to *g invokes undefined
behavior. Also, any reference to g, the pointer variable, invokes
undefined behavior, even if you don't dereference it. Although the
call to free() isn't going to change the bits that make up the value
of g, that value becomes invalid; even comparing g to another pointer
value invokes undefined behavior.

Of course, undefined behavior is a tricky thing; it can, and often
does, manifest itself as the program doing exactly what you think it
should. (Murphy's law, which is outside the scope of the C standard,
implies that it will then stop working at the most inconvenient
possible moment.)

After you've called free(g), you can assign a new value to g:

g = malloc(sizeof *g);
... /* g is now valid */
free(g);
... /* g is now invalid */
g = malloc(sizeof *g);
... /* g is now valid again */

This is allowed because it assigns a new value to g without referring
to the previous value.

C and C++ are two different languages, and we really can't discuss C++
here in comp.lang.c. If you want to discuss C++, feel free to do so
in one of the C++ newsgroups.

 

[E. Robert Tisdale]

After the call to free(g),
any reference to *g invokes undefined behavior.
Also, any reference to g, the pointer variable,
invokes undefined behavior, even if you don't dereference it.
Although the call to free() isn't going to change the bits
that make up the value of g,

It can't. g is passed by value.

that value becomes invalid;

That's meaningless.

even comparing g to another pointer value invokes undefined behavior.

Even if *g has not been free'd.

Of course, undefined behavior is a tricky thing;
it can, and often does, manifest itself
as the program doing exactly what you think it should.

No. Undefined behavior
is simply behavior not defined by the ANSI/ISO C [89]9 standard.
The behavior may be defined by the implementation,
the computer architecture, the operating system or some other standard.

(Murphy's law, which is outside the scope of the C standard,
implies that it will then stop working
at the most inconvenient possible moment.)

Not if the behavior is defined
by something besides the ANSI/ISO C [89]9 standard.

C is used to write platform specific applications such as
device drivers, operating system kernels and standard C libraries.
It is neither practical or desirable to comply
with the ANSI/ISO C standards in such applications.

After you've called free(g), you can assign a new value to g:

g = malloc(sizeof *g);
... /* g is now valid */
free(g);
... /* g is now invalid */
g = malloc(sizeof *g);
... /* g is now valid again */

But you said, "Also, any reference to g, the pointer variable,
invokes undefined behavior, even if you don't dereference it."

Doesn't

g = malloc(sizeof *g);

reference g?

This is allowed because it assigns a new value to g
without referring to the previous value.

That's not the same thing as "referencing g".

C and C++ are two different languages,
and we really can't discuss C++ here in comp.lang.c.

That's your opinion. You're welcome to it.
But I don't share it.

If you want to discuss C++,
feel free to do so in one of the C++ newsgroups.

That's religious intolerance. I don't share your bigotry.
If you don't want to discuss C++, please ignore all references to C++.
Just snip them out of your replies.

 

[August Derleth]

ha, that was such a good example!!

Thank you

In the general case, following Trollsdale's example will only lead to
pain and sloppy code.

 

[Keith Thompson]

It can't. g is passed by value.
Right.


That's meaningless.

No, it isn't, though my use of the term "invalid" was somewhat
informal. Recall that g is a pointer to double. The call free(g)
causes the allocated double object (which can be referred to as *g) to
reach the end of its lifetime. C99 6.2.4p2 says:

The value of a pointer becomes indeterminate when the object it
points to reaches the end of its lifetime.

Attempting to refer to an indeterminate value causes undefined
behavior. (In most implementations, this won't actually cause any
problems, but the standard allows it to become a trap representation,
and referring to the pointer value could conceivably crash the
program. This would actually be sensible for a debugging
implementation.) In any case, there's no point in trying to refer the
value of a pointer after a call to free(); an attempt to do so
probably indicates a bug in the code.

Even if *g has not been free'd.

No, if free(g) hasn't been called, g can safely be compared for

= do invoke undefined behavior; perhaps that's what you were thinking of.

Of course, undefined behavior is a tricky thing;
it can, and often does, manifest itself
as the program doing exactly what you think it should.

No. Undefined behavior
is simply behavior not defined by the ANSI/ISO C [89]9 standard.
The behavior may be defined by the implementation,
the computer architecture, the operating system or some other standard.

And how does that contradict what I said? In any case, many instances
of undefined behavior are *not* defined by any other standard.

(Murphy's law, which is outside the scope of the C standard,
implies that it will then stop working
at the most inconvenient possible moment.)

Not if the behavior is defined
by something besides the ANSI/ISO C [89]9 standard.

You do know that Murphy's law is a joke, right?

C is used to write platform specific applications such as
device drivers, operating system kernels and standard C libraries.
It is neither practical or desirable to comply
with the ANSI/ISO C standards in such applications.

It is both practical and desirable to comply with the ISO standard as
much as possible (but no more than possible). It is neither practical
nor desirable to discuss the details of any platform-specific code in
this newsgroup; the people who can discuss it intelligently hang out
in platform-specific newsgroups.

But you said, "Also, any reference to g, the pointer variable,
invokes undefined behavior, even if you don't dereference it."

Yes. Perhaps I should have said any reference to the value of g.

Doesn't

g = malloc(sizeof *g);

reference g?

No. The operand of the sizeof operator is not evaluated (unless the
operand is a C99 variable length array, but that doesn't apply here).
The assignment doesn't refer to the value of g, it simply assigns a
new value.

That's not the same thing as "referencing g".

What's not the same thing? I can't tell whether you're agreeing or
disagreeing with me. By "referencing g", I mean "referring to (or
using) the value of g".

That's your opinion. You're welcome to it.
But I don't share it.

I presume you're referring to the second part of my statement; you
agree that C and C++ are two different languages, don't you?

Is it your opinion that the existing C++ newsgroups should be
abolished, and both languages should be discussed in the C newsgroups?
You're free to advocate that, but I don't think you'll have much luck.

That's religious intolerance. I don't share your bigotry.
If you don't want to discuss C++, please ignore all references to C++.
Just snip them out of your replies.

Nonsense. If I don't want to discuss C++, I won't read the C++
newsgroups. If I do, I will. The consensus against discussing C++ in
comp.lang.c isn't about any dislike of the C++ language; for the most
part, it's because the regulars of comp.lang.c aren't able to provide
knowledgeable answers to questions about C++, or to correct errors in
other people's postings. That's *exactly* what comp.lang.c++ is for.

To the original poster (if you haven't given up by now): your original
question was about the new and delete operators, which are specific to
C++ and do not exist in C. You were advised to post your question in
comp.lang.c++, not because we were trying to get rid of you, but
because that's where to find the people who are able to answer
questions about new and delete. When you posted a revised question
about malloc() and free(), that was perfectly appropriate for
comp.lang.c, but it was a different question. malloc() and free() are
similar to new and delete, but they're not the same thing -- and I,
for one, am not competent to explain in detail what the differences
are. (If you're curious, comp.lang.c++ would be a good place to ask
about it, since C++ includes the C standard lirary. Be sure to check
the C++ FAQ first; it might already answer any questions you have.)

Some of us may seem abrupt at times (and sometimes some of us can be
downright rude) but for the most part we're sincerely trying to be
helpful -- even (or especially) when we advise you to go somewhere
else.

 

[jimjim]

Hi, I am still here

Right.

g is passed by value to free( ) and this is why it continues to have the
same value -pointing to the same memory location- after free( ) is called (I
hope I ve got it right). What may cause the pointer to assume an
indeterminate value?

No. The operand of the sizeof operator is not evaluated (unless the
operand is a C99 variable length array, but that doesn't apply here).
The assignment doesn't refer to the value of g, it simply assigns a
new value.

I still cant understand this :-(

You said: "After the call to free(g) any reference to *g invokes undefined
behavior". I would have thought that as sizeof *g refers to/uses *g it may
invoke an undefined behavior. You said that the operator is not evaluated.
Can you elaborate please?

I presume you're referring to the second part of my statement; you
agree that C and C++ are two different languages, don't you?

If there was a standardised code of conduct for use in the comp.lang.c, it
would have definitely describe this as an inappropriate behaviour
(and who am I to judge you,e?)

To the original poster (if you haven't given up by now): your original
question was about the new and delete operators, which are specific to
C++ and do not exist in C.

This is true . I clicked on the wrong newsgroup.

However Robert was kind enough to convert my code in C and answer my
question in terms of C in which I am also interested in. I was wondering how
is it possible to free( ), dereference the pointer and still access the data
which I had assigned before. His example answered exactly this. Then Keith
told me that I should not refer to or dereference a pointer; it may cause an
undefined behaviour. The bottom line is that may and I have learned a lot -
which is the whole point of newsgroups- even though I posted my question to
the wrong newsgroup. There is no need for people to get upset and be rude.
This is what Robert wants to communicate.

I should also add that there are many like Robert in newsgroups. I have
seen questions that should have been posted to different newsgroup being
answered by people that happened to know the answer. I have also seen
questions that should have been posted to different newsgroup just being
ignored. I have also seen polite answers pointing out where one should ask
in order to find an answer to his/her question. I have also seen sarcastic,
inappropriate rude answers by people that consider themselves the
"fathers/guardians" of a new newsgroup. An answer reflects the quality of
ones character.

Some of us may seem abrupt at times (and sometimes some of us can be

downright rude)

There is no reason to be rude in newsgroups or even get upset by some
posts. The whole idea is openess, sharing of ideas, providing help,
co-operation, companionship......if one gets upset by some posts s/he may
consider to stop providing his/hers services to the newsgroup as there will
always be people just like myself that will unintetionaly post questions to
the wrong place and get them upset.

 

[CBFalconer]

.... snip ...


Nonsense. If I don't want to discuss C++, I won't read the C++
newsgroups. If I do, I will. The consensus against discussing
C++ in comp.lang.c isn't about any dislike of the C++ language;
for the most part, it's because the regulars of comp.lang.c aren't
able to provide knowledgeable answers to questions about C++, or
to correct errors in other people's postings. That's *exactly*
what comp.lang.c++ is for.

To the original poster (if you haven't given up by now): your
original question was about the new and delete operators, which
are specific to C++ and do not exist in C. You were advised to
post your question in comp.lang.c++, not because we were trying
to get rid of you, but because that's where to find the people
who are able to answer questions about new and delete. When you .... snip ...

Some of us may seem abrupt at times (and sometimes some of us can
be downright rude) but for the most part we're sincerely trying
to be helpful -- even (or especially) when we advise you to go
somewhere else.

However ERT, popularly known as Trollsdale, is not one of those
helpful ones. His objective seems to be to impart misinformation,
sometimes subtly, sometimes crudely, and even sometimes interposed
between accuracies. You must never trust anything in his
messages, even if they appear to be quotes from others, because he
has the admirable habit of altering these to suit his
unmentionable taste and objectives.

 

[Chris Torek]

(On "free(g)")

g is passed by value to free( ) and this is why it continues to have the
same value -pointing to the same memory location- after free( ) is called (I
hope I ve got it right). What may cause the pointer to assume an
indeterminate value?

Have you ever used the low-level instructions on the 80x86 series
of CPUs? These have a mode of operation -- not used much if at
all today -- in which it really can happen.

Suppose the compiler implements passing the value of "g" via the
segment pointer ES combined with the data pointer EDI, for instance.
That is:

use(g);

compiles to (more or less):

mov g_segmet, %es
mov g_offset, %edi
call use

Now, for free(g) we get:

mov g_segmet, %es
mov g_offset, %edi
call free

Suppose that free() manipulates the segment table so that the value
in %es now refers to an invalid segment, then returns. If you then
attempt to call use(g), the "mov g_segment, %es" step will cause
a runtime trap. The bits in g_segment and g_offset have not changed,
but the "move g_segment into %es" register -- which used to be a
legal instruction sequence based on the segment table -- is now an
illegal instruction sequence, based on the now-changed segment
table.

(Nobody generates code like that today because it does not really
buy anything. It might help when debugging but it would run much
slower than simply not using the segment register.)

[On "operand of sizeof is not evaluated", so that sizeof *g is OK]

I still cant understand this :-(

The compiler *is* allowed to put g's segment into %es when you "use
the value" of g:

use(g); /* tries to load %es => trap */
p = g; /* for some reason, also tries to load %es */
*g = 3; /* again tries to load %es */

The compiler is *not* allowed to put g's segment into %es when you
write "sizeof *g":

x = sizeof *g; /* MUST NOT try to load %es */

[Someone] said: "After the call to free(g) any reference to *g
invokes undefined behavior". I would have thought that as sizeof
*g refers to/uses *g it may invoke an undefined behavior. You said
that the operator is not evaluated. Can you elaborate please?

It is just a quirk of the C standard, which says that sizeof never
evaluates its operand (except for some new VLA cases in C99).

If the C standard said "any variable named Zorg must always be
negative", then any variable named Zorg would always be negative.
There would be no fundamental reason; it would just be so.

There are a number of things in the C standard that I think are
wrong design decisions, but they are there and I have to put up
with them (or else not use Standard C). There are a number of
"right decisions" too, and some that I think are indifferent. It
is up to each individual (or corporation or whatever) to decide
whether to live with an existing standard, augment it with additional
standards, subtract from it, ignore it, etc.; but here in comp.lang.c
we generally talk only about Standard C.

"If the C standard says that the behavior depends on the phase of
the moon, the programmer should be prepared to look out the window
as necessary." --me

 

[E. Robert Tisdale]

(On "free(g)")



Have you ever used the low-level instructions
on the 80x86 series of CPUs? These have a mode of operation --
not used much if at all today -- in which it really can happen.

Suppose the compiler implements passing the value of "g" via the
segment pointer ES combined with the data pointer EDI, for instance.
That is:

use(g);

compiles to (more or less):

mov g_segmet, %es
mov g_offset, %edi
call use

Now, for free(g) we get:

mov g_segmet, %es
mov g_offset, %edi
call free

Suppose that free() manipulates the segment table
so that the value in %es now refers to an invalid segment,
then returns. If you then attempt to call use(g),
the "mov g_segment, %es" step will cause a runtime trap.

Can you demonstrate this "runtime trap"
with a function that "manipulates the segment table"?

The bits in g_segment and g_offset have not changed,
but the "move g_segment into %es" register --
which used to be a legal instruction sequence
based on the segment table --
is now an illegal instruction sequence,
based on the now-changed segment table.

If free() invalidates g by manipulating the segment table,
what prevents the invalidation of other pointers?

Your reasoning is fallacious because no implementation of free()
does not, in fact, manipulate the segment table
as you have hypothesized:

http://www.don-lindsay-archive.org/skeptic/arguments.html#hypothesis

(Nobody generates code like that today because it does not really
buy anything. It might help when debugging but it would run much
slower than simply not using the segment register.)

Implementation that did generate "code like that"
would compile Keith Thompson's example without complaint
and produce the same results.

[On "operand of sizeof is not evaluated", so that sizeof *g is OK]

I still can't understand this :-(

The compiler *is* allowed to put g's segment into %es
when you "use the value" of g:

use(g); /* tries to load %es => trap */
p = g; /* for some reason, also tries to load %es */
*g = 3; /* again tries to load %es */

The compiler is *not* allowed to put g's segment into %es
when you write "sizeof *g":

x = sizeof *g; /* MUST NOT try to load %es */

[Someone] said: "After the call to free(g) any reference to *g
invokes undefined behavior". I would have thought that as sizeof
*g refers to/uses *g it may invoke an undefined behavior. You said
that the operator is not evaluated. Can you elaborate please?

It is just a quirk of the C standard, which says that sizeof never
evaluates its operand (except for some new VLA cases in C99).

Is sizeof evaluated at compile-time or at run-time?

If the C standard said "any variable named Zorg must always be
negative", then any variable named Zorg would always be negative.
There would be no fundamental reason; it would just be so.

There are a number of things in the C standard that I think are
wrong design decisions, but they are there and I have to put up
with them (or else not use Standard C). There are a number of
"right decisions" too, and some that I think are indifferent.
It is up to each individual (or corporation or whatever)
to decide whether to live with an existing standard, augment it
with additional standards, subtract from it, ignore it, etc.;
but here in comp.lang.c we generally talk only about Standard C.

"If the C standard says that the behavior depends on the phase of
the moon, the programmer should be prepared to look out the window
as necessary." --me

Are you advocating "blind faith" in the standards documents?