Saturday, October 13, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 10 topics

Tim Rentsch <txr@alumni.caltech.edu>: Oct 06 04:30PM -0700

>> is also the case that the types in C++ must match the types in C,
>> but I haven't tried to verify that.)
 
> They must be type aliases in C, declared with typedef.
 
Sorry, I am guilty of using sloppy language. The names do
need to be declared in <stdint.h> as if they were declared
with a typedef. What I meant is they do not need to be
aliases for any standard integer type: they could instead be
aliases for extended integer types, and thus distinct types
from any standard integer type (and in particular the standard
character types). C and C++ both allow extended integer
types.
 
> C++ requires the types declared in C's stdint.h to have the same
> declaration in cstdint.
 
I believe that is not right. C++ n4659 21.4 covers <cstdint>,
and 21.4.1 p2 says
 
The header defines all types and macros the same as the C
standard library header <stdint.h>.
 
The types have to match, but not the declarations. The synopsis
directly under 21.4.1 make it clear that how the types are
declared in <cstdint> is different, or at least can be different,
than how they are declared in the C header <stdint.h>. Then in
section D.5, which discusses the C++ headers corresponding to C
headers, paragraph 3 says this:
 
Every other C header [including <stdint.h>], each of which
has a name of the form name.h, behaves as if each name placed
in the standard library namespace by the corresponding cname
header is placed within the global namespace scope, except
for the functions described in 29.9.5 [Mathematical special
functions], the declaration of std::byte (21.2.1), and the
functions and function templates described in 21.2.5 [byte
type operations]. It is unspecified whether these names are
first declared or defined within namespace scope (6.3.6) of
the namespace std and are then injected into the global
namespace scope by explicit using-declarations (10.3.3).
 
To me this looks like pretty convincing evidence that the types
have to be the same, but how they are declared does not.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 07 09:23PM +0100

On Sun, 7 Oct 2018 16:01:24 -0400
 
> So, if there is a clause that it violates, you can cite that clause and
> explain how such an implementation would be considered in violation of
> that clause.
 
You seem super aggressive today.
 
I said it was implied, for reasons given in my earlier posts which you
are free to read at your leisure. That should make my position clear
enough I hope. The standard leaves many things implicit.
 
I am not asking you to agree with me. I am perfectly happy that you do
not.
Paavo Helde <myfirstname@osa.pri.ee>: Oct 05 09:51AM +0300

On 5.10.2018 0:50, Horizon68 wrote:
 
> Read this very interesting webpage to understand more:
 
> The strange link between the human mind and quantum physics
 
> http://www.bbc.com/earth/story/20170215-the-strange-link-between-the-human-mind-and-quantum-physics
 
Of course there is a link between mind and quantum, the brain consists
of atoms which are best described by quantum physics at low level. The
same holds for a piece of rock, for example.
 
+1 for the article to mention decoherence and explaining this causes the
quantum effects to vanish at room temperatures 1E16 times faster than it
takes for a neuron to trigger a single signal.
 
The article also contains repeated remarks in the form "But there is no
evidence that such a thing is remotely feasible."
 
So I think you are mistaken about the article, it is not about any
mystical link, it is about lunatics seeking such links. Basically all
their mambo-jambo comes down to "I do not understand this, therefore
quantum!". It remains unclear why not "therefore spaghetti monster!" or
"therefore 7 dwarfs!".
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 05 11:02AM +0200

On 05.10.2018 08:51, Paavo Helde wrote:
> evidence that such a thing is remotely feasible."
 
> So I think you are mistaken about the article, it is not about any
> mystical link, it is about lunatics seeking such links.
 
I agree about the lunatics. However, do note that they include Roger
Penrose, chair of the math department (whatever) at Oxford University.
He collaborated with Stephen Hawking on the results Stephen is most
famous for, about black holes.
 
I'd go even further and call the idea of black holes as places with
unusual time and space axis directions, just sheer lunacy: failing to
understand that a breakdown in math results means the math or the model
is wrong, not reality is. Which implies... That good old Stephen Hawking
was misled into insanity by Roger Penrose?
 
Hm. Anyway, I once wrote a little ironical piece about Roger Penrose's
insane views on AI. <url:
https://alfps.wordpress.com/2010/06/03/an-ironclad-proof-that-you-are-smarter-than-roger-penrose/>
:)
 
 
 
 
> their mambo-jambo comes down to "I do not understand this, therefore
> quantum!". It remains unclear why not "therefore spaghetti monster!" or
> "therefore 7 dwarfs!".
 
Yes.
 
 
Cheers!,
 
- Alf (offtopic mode, before first coffee!)
Melzzzzz <Melzzzzz@zzzzz.com>: Oct 05 07:36PM

> books about, and his ability to simply not see any inconsistency in his
> attempted mathematical proofs of that. They're trivial errors, not
> recognized or /seen/ by the chair of the Oxford math department.
 
As they are trivial care to show them?
Before Penrose I heard that strong AI is impossible because there is no
algoritm to make algorithms... from my mathematical logic proffesor.
That was in 1987 before Penrose wrote book...
 
--
press any key to continue or any other to quit...
Melzzzzz <Melzzzzz@zzzzz.com>: Oct 05 08:31PM

> Train that data into program and it perhaps acquires creativity in the
> process. ;)
> https://tmrwedition.com/2017/02/06/artificial-intelligence-is-already-a-better-artist-than-you-are/
It is not trivial. My professor started with proof that there is
algorithm for proofing valid logic formulae. Result is that there isn't
one. Then he derived that algorithm for making algorithms does not
exists...
Your example is trivial fallacy, since it talks about something else,
unrelated to the subject.
I hope we will alive in 20 years and talk about this then.
 
 
--
press any key to continue or any other to quit...
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 05 09:54PM +0200

On 05.10.2018 21:36, Melzzzzz wrote:
>> attempted mathematical proofs of that. They're trivial errors, not
>> recognized or /seen/ by the chair of the Oxford math department.
 
> As they are trivial care to show them?
 
I already linked to ¹something I blogged in 2010, up-thread. That was
just one of his attempted proofs. I don't have his books here, and I'm
not sure I still have the first book -- as I recall someone borrowed it
and didn't return it. But I recall the errors were (1) myriad, and (2)
mostly trivial. It's amazing what a religious-like belief can do.
 
 
> Before Penrose I heard that strong AI is impossible because there is no
> algoritm to make algorithms... from my mathematical logic proffesor.
> That was in 1987 before Penrose wrote book...
 
Yes, he was not the first.
 
There were a bunch of philosophers very attracted by the notion of
adding mathematical rigor to their arguments. But they mainly used math
as an impressive-looking /notation/ to express their handwaiving
arguments in. Penrose differed by actually trying to do things
mathematically, but as with a proof of a perpetuum mobile machine you
don't need to even look at the details to know it's wrong, and the
problem (for his sanity) is that he didn't draw that conclusion.
 
 
Cheers!,
 
- Alf
 
¹
https://alfps.wordpress.com/2010/06/03/an-ironclad-proof-that-you-are-smarter-than-roger-penrose/
Melzzzzz <Melzzzzz@zzzzz.com>: Oct 05 07:59PM

> mathematically, but as with a proof of a perpetuum mobile machine you
> don't need to even look at the details to know it's wrong, and the
> problem (for his sanity) is that he didn't draw that conclusion.
 
Problem is that algorithm is finite set of steps. You can't program
creativity.
 
 
--
press any key to continue or any other to quit...
James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 05 08:21AM -0400

On 10/05/2018 05:02 AM, Alf P. Steinbach wrote:
...
> understand that a breakdown in math results means the math or the model
> is wrong, not reality is. Which implies... That good old Stephen Hawking
> was misled into insanity by Roger Penrose?
 
The singularity at the center of a black hole is unambiguously a place
where gravitational fields get so strong that our understanding of
physics breaks down, because we've never been able to conduct
experiments in fields that strong. That's acknowledged by most of the
authorities in the field.
However, that time and space axes undergo distortion due to strong
gravitational fields is a fundamental aspect of the General theory of
Relativity (GR). Physicists have gone out of their way to locate
evidence that distinguishes GR from any proposed alternative, and the
evidence they've collected fits GR better than any meaningfully
different theory (at least one of the alternatives that has been
proposed turned out to be mathematically equivalent to GR, just
described in a different way). If this be lunacy, then I see nothing
wrong with being this kind of a lunatic.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 04:39PM -0400

On 10/07/2018 04:35 PM, Rick C. Hodgin wrote:
> I learned that very often the most intolerant and narrow-minded people
> are the ones who congratulate themselves on their tolerance and
> open-mindedness.
 
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
To address his false teaching:
 
The things Jesus calls us to teach are in the Bible. They
are us teaching His guidance for life and living. They are
not us creating our own interpretation of things, but we are
to be changed by the new spirit life, and to go forth and
teach people how to be saved.
 
When you see Christians doing things which are not appropri-
ate, recognize that it is not Jesus at work there, but it is
sin living in their flesh which is guiding them, rather than
them being guided by the spirit.
 
--
Rick C. Hodgin
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 06 11:45PM +0200

On 06.10.2018 23:07, Tim Rentsch wrote:
>> every time.
 
> The code he posted uses rand(). Different sequences can be
> obtained by calling srand(), eg, at program startup.
 
The code he used, that you chose to snip out, uses
`std::default_random_engine`.
 
And yes, /also/ `rand`, evidently in an attempt to fix things.
 
`srand` is irrelevant for fixing this code.
 
 
Cheers & hth.,
 
- Alf
Juha Nieminen <nospam@thanks.invalid>: Oct 07 01:15PM

> each time. However, if you don't do that, then
> you just get exactly the same result each time nextDouble()
> is called.
 
Whoever offered that criticism might have expressed himself abysmally
poorly.
 
What you are doing in the function you provided is not how RNGs
should be used, nor how they are intended to be used. (What you
are doing there is most probably only going to reduce the quality
of the randomness, possibly making the period of the RNG stream
smaller, possibly a *lot* smaller, and in many cases making it
less efficient.)
 
The random number generators in the standard library store their
internal state within the object you instantiate, and it's this
object that you should be keeping somewhere, if you want a stream
of random numbers. If the task is "write a function that returns
a value between 0.0 and 1.0 at random", one possible way to do
that is like:
 
//-------------------------------------------
namespace
{
std::default_random_engine myRNG(0);
std::uniform_real_distribution<double> myDistribution(0.0, 1.0);
}
 
double RandomGen::nextDouble()
{
return myDistribution(myRNG);
}
//-------------------------------------------
 
(In many cases this is not the most optimal solution design-wise,
or even functionally (eg. it's not thread-safe), but you should get
the idea.)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 06 07:39PM +0200

On 06.10.2018 18:45, Paul wrote:
 
> std::uniform_real_distribution<double> distribution(0.0, 1.0);
> return (distribution(generator));
> }
 
Oh sorry, in addition to earlier remarks, you need to /retain state/
from one call to the next.
 
One is to make the generator `static`, but that would be a kludge.
Instead I'd put the state, i.e. the `generator`, as a member variable in
the `RandomGen` class. The caller has to remember to keep an instance of
that class and not create a new one every time.
 
Also sorry for inadvertently sending this as a reply mail instead of to
the group. Hm.
 
 
Cheers & again hth.,
 
- Alf
Tim Rentsch <txr@alumni.caltech.edu>: Oct 06 02:07PM -0700

>> is called.
 
> No. But with old version of g++ you get the same /sequence/
> every time.
 
The code he posted uses rand(). Different sequences can be
obtained by calling srand(), eg, at program startup.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 06 11:47PM +0200

On 06.10.2018 23:40, Tim Rentsch wrote:
> seedCounter. There is also the retained state of rand(),
> whatever that may be. This approach may not be a very
> good way of doing things, but it does have retained state.
 
That's a technically correct observation, but entirely misses the point.
 
When the code is fixed, the features that you chose to regard as most
important, will be entirely gone.
 
They're irrelevant, attempted fixes that should just be cleaned out.
 
 
Cheers & hth.,
 
- Alf
Tim Rentsch <txr@alumni.caltech.edu>: Oct 06 03:18PM -0700

Paul <pepstein5@gmail.com> writes:
 
[edited and rearranged]
 
> time. However, if you don't do that, then you just get exactly
> the same result each time nextDouble() is called.
 
> Can anyone make any sense of this complaint? [...]
 
Generally it's not a good idea to use setting a seed value to get
another random number. The usual advice is seed once, then
extract as many random numbers as you need.
 
I realize that what you're doing here follows a different
pattern. However it's still not a good idea. The size of the
state space may be greatly reduced. The quality of the
generated seeds may be low (rand() is notoriously unreliable).
And random number generators sometimes take an iteration or
several to "get up to speed" after being seeded.
 
If it were me I might do something along these lines (please
excuse changes in naming):
 
class RandomGenerator {
static std::default_random_engine uniform_double_generator;
 
public:
static double uniform_double();
 
static void seed_uniform_double( unsigned long long s ){
uniform_double_generator.seed( s );
}
};
 
std::default_random_engine RandomGenerator::uniform_double_generator;
 
double
RandomGenerator::uniform_double(){
std::uniform_real_distribution<double> distribution(0.0, 1.0);
return distribution( uniform_double_generator );
}
 
I added an interface to seed the underlying generator, and
avoided any call to rand(). Usually it's a good idea not
to couple different generators, so numbers used for one
purpose don't interfere with another. The key point though
is to use the underlying generator, and not rely on seeding
to give the randomness.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 06 07:27PM +0200

On 06.10.2018 18:45, Paul wrote:
> each time. However, if you don't do that, then
> you just get exactly the same result each time nextDouble()
> is called.
 
No. But with old version of g++ you get the same /sequence/ every time.
 
Oh look, I answered that on Stack Overflow 3 days ago, what a
coincidence! <url:
https://stackoverflow.com/questions/52625317/c14-2-random-generators-one-works-the-other-doesnt/52625445#52625445>
 
Note: I'm at reputation 1 there again, because I used the "i" word
(incompetence) again. It was about someone first voting to close a very
reasonable and clear and interesting question, then not admitting it was
wrong to do that and instead asserting that there could be no answer
because it was too broad, which it was not, then sort of instantly
downvoting my answer delineating the exactly two ways to do it at the
core language level. I didn't name him, just wrote that whoever
downvoted my answer displayed an extraordinary incompetence. I think
they've automated the suspension process for me, and for other misfits
who use clear Descriptive Words™. :)
 
 
 
> std::uniform_real_distribution<double> distribution(0.0, 1.0);
> return (distribution(generator));
> }
 
 
Cheers & hth.,
 
- Alf
Tim Rentsch <txr@alumni.caltech.edu>: Oct 06 02:40PM -0700

>> }
 
> Oh sorry, in addition to earlier remarks, you need to /retain
> state/ from one call to the next.
 
The code does have retained state, in the static variable
seedCounter. There is also the retained state of rand(),
whatever that may be. This approach may not be a very
good way of doing things, but it does have retained state.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 05:25PM -0400

On 10/07/2018 05:17 PM, Mr Flibble wrote:
>> (*Trolling*) "*to deviate from the stated topic of the group*"
 
> And you don't do that when you spam your religious posts? Never in my
> life have I seen such a blatant bare faced example of hypocrisy.
 
People are free to report anything I post to any authority they
choose to do so. I will accept the consequences as they are
doled out.
 
You subscribe to a service which is enabling you to post true
impersonation posts that even Google Groups does not recognize
is not me. It shows up with my channel icon, ascribes the
posts to me. I don't even see them as unread when I view them
on Google Groups.
 
What you're doing, Leigh, is evil. You are attacking a servant
of God with your anti-Christ rhetoric. And you do not realize
the piles of burning coals you are heaping upon your own head.
 
I would save from all of that, but you won't hear any of it.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 04:38PM -0400

On 10/07/2018 04:32 PM, Rick C. Hodgin wrote:
> for the evil they have done before they even start clearing their
> throats and telling me that I wouldn't know right from wrong without
> their permission. I'm sorry, I won't be spoken to in that tone of voice.
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
To address his false teaching:
 
Sin operates in a multitude of ways in this world. For some,
it is in the life lived apart from God, the one that seems to
be good, beneficial, moral, ethical, but without any forgive-
ness of sin by Jesus Christ. Because of the no forgiveness
of sin, those people who lived "moral" lives are in for a big
shock when they face judgment.
 
Other sin operates against people by causing people to do bad
things in the name of Jesus. But Jesus doesn't call us to be
bad or do bad things. It is only sin operating in those people
that causes them to behave that way.
 
Jesus calls us to truth, righteousness, holiness, purity, to
teach others the true message of forgiveness of sin through
Him, and the new spirit life that comes from that exchange.
But even so, our lives still require focus, discipline, and a
true purpose in the things we do because we still face a real
enemy who seeks to still destroy us, to make us weak, to dam-
age our witness, to make it easier for people to take only a
casual 500 foot glance in the direction of "Christianity,"
and see the false things done in Christ's name, and conclude
that Jesus is that evil they see there from 500 feet away.
 
Such people are already condemned because they won't step
closer. They won't investigate the truth for themselves.
They are lost in their own love of sin, and their own wil-
lingness to believe falseness and lies as though they were
truth.
 
--
Rick C. Hodgin
Ian Collins <ian-news@hotmail.com>: Oct 08 03:51PM +1300

On 08/10/18 08:28, Paul wrote:
 
> {
> // Some code
 
> }
 
What errors do you see?
 
--
Ian.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 04:45PM -0400

On 10/07/2018 04:41 PM, Rick C. Hodgin wrote:
> Darwin's Theory of Evolution, but they don't know anything about either.
> But when they go to the hospital, you'll notice, they act as if Darwin
> is more likely to be right.
 
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
To address his false teaching:
 
Jesus Himself said, "The healthy do not need a doctor, but
only the sick."
 
We have fallen-in-sin bodies, and we need medical attention
and care to address these physical needs in this sinful
world.
 
We have a guidance to override our choices by the guidance
of the spirit, and God can perform miracles through nurses
and doctors as He sees fit.
 
But we are always, in our flesh, to do everything we can
do, and then stand. We do not first seek to be away from
God, but we seek to honor God by doing all we can first,
and then He moves us forward in whatever way He does.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 07 04:47PM -0400

On 10/07/2018 04:43 PM, Rick C. Hodgin wrote:
> I'm a member of no party. I have no ideology. I'm a rationalist; I do
> what I can in the international struggle between science and reason, and
> the barbarism, superstition and stupidity that's all around us.
 
 
I, the real Rick C. Hodgin, did not write the post I'm quoting.
It is written by a coward named Leigh Johnston who likes to parody
my posts with his anti-Christ rhetoric. He teaches people false
things and piles upon his own head punishment that he cannot even
imagine. It breaks my heart to see.
 
Examine the headers and see the difference. I only post from Google
News, or Eternal September, and from Indianapolis, IN.
 
To address his false teaching:
 
Jesus leads us to be salt and light in this world, to shine
His Holy Light of truth upon the world of darkness.
 
The message He brings is not for those who are perishing.
It is for those who are being saved only.
 
If you can hear His voice, rejoice and be exceedingly glad.
Jump up and down with joy because God is reaching out to
save your eternal soul from damnation.
 
The things of this world all tied back to God. They have
come from Him, and they are returning to Him. You can ex-
amine any aspect of anything scientific, and you will see
two voices at work: (1) The voice of God lending credence
to His creation and design, and (2) another voice of the
enemy who seeks to undo the works of God and provide an alt-
ernate explanation for everything.
 
All who are led by the spirit of God will be drawn to Christ,
led by the spirit to spiritual things, which will teach each
person the truth. But those who are led only by the flesh
will perish in their false-belief made possible through sin
at work in their lives.
 
--
Rick C. Hodgin
Tim Rentsch <txr@alumni.caltech.edu>: Oct 12 09:31PM -0700

>>>>>> of stack space is not undefined behavior as the C standard defines
>>>>>> the term. A lot of people find this very counter-intuitive; let
>>>>>> me see if I can explain it.
 
[...]
 
> there are only two mains with defined behavior). That is my
> opinion of course, your seems to be that these all are defined no
> matter what.
 
Your response doesn't answer the question that I asked. I
deliberately avoided using any of the terms "behavior",
"defined", or "undefined". Please read my question again: "For
which of these programs does the C++ standard impose requirements
for what status is returned?" Let's label the programs A, B, C,
D, E, and F, from top to bottom. The answer should be a set of
those letters (the empty set, all of them, or somewhere in
between). The phrase "impose requirements" could be read as
"impose a requirement", that is, singular or plural makes no
difference. Can you tell me what your answer to this question
is?
Tim Rentsch <txr@alumni.caltech.edu>: Oct 05 08:29AM -0700


> Standard does describe situations. Those are situations that cause
> malloc to return null pointer or errno to be set ENOMEM or ENOSPC
> and the like. What else these are?
 
That isn't what I meant by "situation", but let's take a look at
it. The C++ standard says this (in n4659 23.10.11 p2) about the
<cstdlib> allocation functions (which includes malloc):
 
Effects: These functions have the semantics specified in the
C standard library.
 
The C standard, in n1570 7.22.3 p2, says this about the behavior
of memory management functions (which includes malloc) [in part;
the full paragraph is much longer, but this sentence is the only
relevant one]:
 
If the space cannot be allocated, a null pointer is returned.
 
Two points are important here. First, the condition "space
cannot be allocated" is stated in the text of the C standard,
which means it is something known to the abstract machine. In
fact we don't know what it means in terms of running on actual
hardware. The condition "being out of stack space" is exactly
the opposite of that: it is defined only in terms of what's
going on in the actual hardware, and not something that is known
to the abstract machine. Isn't it true that C++ programs, like C
programs, are defined in terms of behavior in the abstract
machine?
 
Second, the dependence (of what malloc(), etc., do) on this
condition is explicit in the text of the standard. Unless there
is some explicit statement to the contrary, the stated semantics
are meant to apply without exception. For example, 7.22.2.1 p2
gives these semantics for rand():
 
The rand function computes a sequence of pseudo-random
integers in the range 0 to RAND_MAX.
 
This statement doesn't mean rand() gives a pseudo-random value
unless one "cannot be generated"; it means rand() always gives a
pseudo-random value, or more precisely that the definition of
rand() specifies that it always gives a pseudo-random value.
Or here is another example. Consider the code fragment:
 
unsigned a = 10, b = -3, c = a+b;
 
The definition of the + operator specifies the result of
performing the addition, and that definition is unconditional.
If it happens that the chip running the executable has a hot spot
that flips a bit in one of its registers, that doesn't make the
expression 'a+b' have undefined behavior. The behavior is
defined regardless of whether running the program is carried out
correctly.
 
There is no explicit statement in the C standard, or AFAIAA the
C++ standard, giving a dependence (in the stated semantics) on
some condition like "running out of stack". Hence whether that
condition is true cannot change whether a program has defined
behavior or undefined behavior.
 
>> doesn't change that.
 
> Anything that is not defined by any passage of standard *is*
> undefined behavior in C++. That may be different in C.
 
The same is true in C, with the understanding that any _behavior_
that is not defined is undefined behavior, which is also the
case for C++. If there is any explicit definition of behavior,
then the behavior is not undefined.
 
> Is it in C that because standard does not state that automatic
> storage has limits and what happens when the limits are exhausted
> then the automatic storage is unlimited in C?
 
AFAICT neither standard has any statement about automatic storage
having limits, let alone a statement about what happens when such
limits are exhausted.
 
The C++ standard gives this general statement, in 4.1 p2.1:
 
If a program contains no violations of the rules in this
International Standard, a conforming implementation shall,
within its resource limits, accept and correctly execute
that program.
 
There is no requirement that an implementation correctly execute
a program that exceeds any resource limit, including the resource
of automatic storage. But that doesn't change whether the
semantics of said program are defined: if the C/C++ standards
define the semantics, they are still defined whether the program
can be correctly executed or not.
 
> some local variable breaks automatic storage limits then what
> actually happens is undefined behavior exactly because standard
> did not define it.
 
That isn't right. In both standards, the rule is that when there
is a definition for the semantics of a particular construct, that
definition applies unconditionally unless there is an explicit
provision to the contrary. It is only when a construct has no
definition that the behavior is undefined.
 
To put this in concrete terms, consider the following program:
 
#include <stdio.h>
 
unsigned ribbet( unsigned );
 
int
main( int argc, char *argv[] ){
unsigned u = ribbet( 0U - argc );
printf( "%u\n", u );
return 0;
}
 
unsigned long
ribbet( unsigned u ){
if( u == 0 ) return 1234567;
return 997 + ribbet( u + 1000003 );
}
 
Going through it a piece at a time:
 
In main():
 
The expression '0U - argc' has explicitly defined behavior,
and the definition is unconditional.
 
The function call 'ribbet( 0U - argc )' has explicitly
defined behavior, and the definition is unconditional.
 
The initializing declaration 'unsigned u = ...' has
explicitly defined behavior, and the definition is
unconditional.
 
The statement calling printf() has explicitly defined
behavior, and the definition is unconditional (assuming
a hosted implementation in C, which IIUC C++ requires).
 
The 'return 0;' has explicitly defined behavior, and the
definition is unconditional.
 
In ribbet():
 
The expression 'u == 0' has explicitly defined behavior, and
the definition is unconditional.
 
The controlled statement 'return 1234567;' has explicitly
defined behavior, and the definition is unconditional.
 
The if() statement has explicitly defined behavior, and the
definition is unconditional.
 
The expression 'u + 1000003' has explicitly defined behavior,
and the definition is unconditional.
 
The recursive call to ribbet() has explicitly defined
behavior, and the definition is unconditional.
 
The expression '997 + ribbet( ... )' has explicitly defined
behavior, and the definition is unconditional.
 
The final return statement has explicitly defined behavior,
and the definition is unconditional.
 
Every piece of the program has its behavior explicitly defined,
and in every case there are no exceptions given for the stated
semantics. There is therefore no undefined behavior. If a
particular implementation runs out of some resource trying to
execute the program, it may not execute correctly, but that
doesn't change the definition of the program's semantics (which
is to say, its behavior). The key point is that the behavior is
_defined_: we know what the program is supposed to do, even if
running the program doesn't actually do that. Pulling the plug,
having the processor catch on fire, the OS killing the process
because it ran out of swap space, or running out of automatic
storage, all can affect what program execution actually does;
but none of those things changes what the standard says the
program is meant to do. Undefined behavior means the standard
doesn't say anything about what is meant to happen, and that
is simply not the case here.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)