Sunday, June 23, 2019

Digest for comp.lang.c++@googlegroups.com - 21 updates in 7 topics

Tim Rentsch <tr.17687@z991.linuxsc.com>: Jun 23 01:08PM -0700

>>> newsgroup.
 
>> Hate speech need to be confronted no matter where it appears.
 
> [..continuing the meta-discussion..]
 
Note to the group -
 
Until further notice please assume that I will not be reading
any more articles posted by David Brown, either in this or
any other newsgroup.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 23 10:38PM +0100

On 23/06/2019 21:08, Tim Rentsch wrote:
 
> Until further notice please assume that I will not be reading
> any more articles posted by David Brown, either in this or
> any other newsgroup.
 
Please explain why any of us should care about that?
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Ian Collins <ian-news@hotmail.com>: Jun 23 11:38AM +1200

On 23/06/2019 00:27, David Brown wrote:
> when needed. (I don't know if this is done at the moment - for the
> small amount of PC programming I have done with C and C++, stack space
> is not an issue.)
 
The default stack limit on Linux is 8MB, which can cause much amusement
on small systems when the abomination known as over-commit is disabled :)
 
--
Ian.
Nathaniel Tripp <nathaniel@xor.systems>: Jun 23 02:50AM +0300

> How exactly should programs be designed, if one wanted to be extra
> paranoid about the possibility of running out of stack space? Or is
> it something that there's simply no recourse against?
 
Generally speaking this is handled by implementing a finite state
machine in your coding logic, e.g. for (;;) { switch (var) {} } and then
intermittently using things like setjmp/longjmp or similar (cringe).
 
Most all scripting languages have to cope with this, if you dig through
the source code for whichever you find easiest to read you'll find they
all mostly do the same thing. The short answer however is they mostly
avoid recursing where possible and emulate functionality via a FSM.
 
the *printf() family of functions is vaguely similar in form and function.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jun 23 01:06AM -0700

On 6/14/2019 5:44 AM, Juha Nieminen wrote:
 
> How exactly should programs be designed, if one wanted to be extra
> paranoid about the possibility of running out of stack space? Or is
> it something that there's simply no recourse against?
 
Funny thing. One time I created two programs. A and B. A would run B on
the system during the "setup" phase, and see how far it could recurse
before B crashed. A would notice the failure, record the current number,
and try again with a slightly smaller number. If B runs to completion, A
recorded the recursion level as a so-called "critical max" to be
avoided. Of course I want to avoid recursion when possible. But, the
code had to use some third-party stuff that used it.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 23 03:36PM +0200

> The default stack limit on Linux is 8MB, which can cause much amusement
> on small systems when the abomination known as over-commit is disabled :)
 
That's not an issue since the untouched pages are just subtracted from
the pagefine on creation of the stack. I.e. the address-range is logi-
cally allocated but not physically until the pages are written.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 23 03:53PM +0200

On 23.06.2019 15:36, Bonita Montero wrote:
 
> That's not an issue since the untouched pages are just subtracted from
> the pagefine on creation of the stack. I.e. the address-range is logi-
> cally allocated but not physically until the pages are written.
 
What's the difference between that (which I believe is called virtual
alloc) and over-commit?
 
 
Cheers!,
 
- Alf
Bonita Montero <Bonita.Montero@gmail.com>: Jun 23 05:56PM +0200

> What's the difference between that (which I believe is called virtual
> alloc) and over-commit?
 
With overcommit the pages arent subtracted from the pagefile on
allocation.
Ian Collins <ian-news@hotmail.com>: Jun 24 07:48AM +1200

On 24/06/2019 01:36, Bonita Montero wrote:
 
> That's not an issue since the untouched pages are just subtracted from
> the pagefine on creation of the stack. I.e. the address-range is logi-
> cally allocated but not physically until the pages are written.
 
If you are going to reply to my posts, don't snip the attributions.
 
--
Ian.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jun 23 12:51PM -0700


> [...] The closest it comes to talking about such matters is to
> define the term "implementation limits": "restrictions imposed
> upon programs by the implementation". [...]
 
What happens when program execution runs out of stack space does
not involve implementation limits, because the software that
determines how much stack space is available is not part of the
implementation. Rather it is part of "a data-processing system"
that supports the implementation, and about which the standard is
specifically and explicitly mute (per the C standard, incorporated
normatively by the C++ standard in section 1 paragraph 2).
 
> It's all very vague and open to dispute. [...]
 
It is open to dispute. How vague it is is also open to dispute.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jun 23 01:03PM -0700


> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1637.pdf
 
> which should discuss this under
 
> VI. STRICTLY CONFORMING C PROGRAMS DO NOT EXIST
 
Their analysis is flawed. The program
 
int
main( void ){
char a[65000];
return 0;
}
 
has defined behavior, regardless of what happens when the
program is run.
 
> . The situation for C++ should be similar.
 
An argument could be made that "undefined behavior" means
something different in C++ than it does in C, so the same
inferences might not apply. However, AFAIAA everyone familiar
with the two languages either expects or assumes that the term
means the same thing in both languages, which implies that the
analysis is flawed for C++ also.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jun 23 02:07PM -0700

On 6/23/2019 12:48 PM, Ian Collins wrote:
>> the pagefine on creation of the stack. I.e. the address-range is logi-
>> cally allocated but not physically until the pages are written.
 
> If you are going to reply to my posts, don't snip the attributions.
 
She always seemed to have a little problem with this. I tried to get her
to change way back in the following thread:
 
https://groups.google.com/d/msg/comp.lang.c++/kAz1VAxD2lI/hm6BMuEJAQAJ
 
;^)
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jun 23 10:52AM -0700


> On Thursday, 30 May 2019 16:37:56 UTC+3, Tim Rentsch wrote:
 
[snipping previous stuff since it seems mostly redundant]
 
>> that a program (any program) might do anything at all when the
>> compiled program is executed. That doesn't change whether the
>> behavior /of the program/ is defined or not.
 
Let me start by saying I appreciate your response, and I
hope that is remembered in case some of my responses may
unintentionally come across as antagonistic.
 
> I agree (did several posts ago) that we are repeating ourselves.
 
That isn't the same as what I said, and speaking for myself I
try to avoid just repeating myself.
 
> I have also brought counter-example:
> For example .NET is defined to throw System.StackOverflowExeption
> when it runs into stack limit. So it can't do "anything" unlike C++.
 
I don't see how that has any bearing on this discussion.
 
> Why C++ explicitly avoids specifying any behavior when the
> program runs into limits (that actual reality always has)?
 
The point is the standards /do/ specify behavior. If the passages
that specify a behavior don't say anything about limits, then
those passages apply unconditionally. For example, if variables x
and y have type unsigned int, then 'x+y' has a well-defined value,
regardless of whether heat buildup has caused the CPU to melt.
Clearly there is a limit for how much heat buildup a CPU can
tolerate, but the unsigned addition is defined (that is, has
defined behavior) regardless of whether that physical limit has
been reached.
 
>> your interpretation is that it leads to ridiculous conclusions.
 
> I agree, it is wholly ridiculous situation ... but I may
> misunderstand what aspect of it you have in mind.
 
Probably the most important is that "undefined behavior" as you
envision the term would be either meaningless or useless.
 
>> than it is in C++.
 
> I do not see how C is in better shape in any way. The actual
> problem is same (and I consider it as ridiculous).
 
Note that I am not arguing either that the two languages are
the same or that they are different (ie, with respect to what
"undefined behavior" means). I think the case is harder to
defend if you think C and C++ are the same in this regard,
but since either conclusion looks nonsensical that doesn't
really matter.
 
> millions of runs and even then it may manifest in a way that the
> program does something that its users fully expect and are even
> happy about.
 
I understand that that is a consequence of your worldview. I
don't see the point of adopting a worldview that renders the term
"undefined behavior" meaningless or useless.
 
>> seems pretty unlikely that this kind of useless definition is
>> what was intended.
 
> I can not comment intentions that have lead to there.
 
Are you arguing a point of view based only on what the standards
"truly say"? That's a pointless discussion, because a lot of
what the standards say is ambiguous. In many or even most cases,
to resolve these ambiguities we need to reason about what meaning
was intended. Yes?
 
> [...]
> Are you suggesting that abstract machine is by definition
> with limitless resources? I have seen no such definitions.
 
If a specification for a particular program construct is given,
and it doesn't state any limiting conditions, then there aren't
any and it applies unconditionally. Also, in case this needs
saying again, what and whether behavior is defined is always a
statement /only/ about the abstract machine, since the C and C++
standards always talk about behavior with regard to what happens
in the abstract machine.
 
> It feels logically orthogonal if machine is abstract or actual
> and if resources of it are limitless or limited.
 
I don't know what you mean by this sentence.
 
> sizes) and ways to check those and also undefined behaviors
> (or lack thereof, like modular arithmetic) on case of
> exceeding these.
 
I hope you can see that this statement has no rhetorical value.
Certainly if a passage states that a limit applies, then the
limit applies. But if there is a definition for a particular
behavior, and the defining passages do /not/ state a limit,
then the definition applies unconditionally.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jun 23 10:53AM -0700

>> /will/ do. [snip]
 
> Consider dererefencing a nullpointer outside a `typeid` expression.
 
> One doesn't know whether it will be a nullpointer until run-time.
 
We do know, in the sense that the abstract machine can be
simulated up to the point where the pointer value will be
dereferenced, and checked to see if the value is null.
 
If the program reads input, the simulation can be forked, one fork
for each character value, and each fork checked. If all forks
arrive at a non-null pointer, then the program's behavior is
defined (ie, up to that point). If all forks arrive at a null
pointer, then the program's behavior is unconditionally undefined.
If some but not all forks arrive at a null pointer, then the
program has input-dependent undefined behavior.
 
Similarly, if the simulation encounters an unspecified behavior,
the simulation can be forked, one fork for each choice the
unspecified behavior allows. Like what happens with input forks,
the program's behavior can be defined, unconditionally undefined,
or unspecified-dependent undefined. (Note that some cases of
unspecified behavior give undefined behavior even if only some
forks lead to undefined behavior, but which cases those are is
spelled out in the standards.)
 
Implementation-defined behavior is like unspecified behavior,
except that if we are considering a particular implementation then
we know what choice was made and there is only one fork.
 
A given simulation may give rise to an explosion of forks and so
not be feasible to actually carry out, but that doesn't change
things. The question is not whether we /do/ know, but whether in
principle we /can/ know, what a program should do, based on the
program itself.
 
> behavior of a particular executing instance of the program, at a
> particular point in the execution, not about the program itself as
> such.
 
The question here is a question about the program, not about
executing the program. This is the key point: what behavior
is defined is a question about the program in a mathematical
universe (ie, that of the abstract machine), not a question
about program execution in the physical universe. In all
cases the C and C++ standards define behavior in terms of
what happens in the abstract machine, not what might happen
in a physical machine.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 23 10:52PM +0200

On 23.06.2019 19:53, Tim Rentsch wrote:
> cases the C and C++ standards define behavior in terms of
> what happens in the abstract machine, not what might happen
> in a physical machine.
 
Well, I guess that to you the distinction you're trying to make, which I
don't grasp, is meaningful.
 
And even if you're wrong, which is a possibility, I and possibly also
others might learn something or at least be guided to think about
something if you explain the practical utility of the distinction.
 
So, is there a concrete example where e.g. with the distinction that I
can't even pin down clearly enough to refer to, but with that
distinction, we can say confidently that this program should be portable
with well defined behavior, or not portable, or not well defined
behavior, where with the simpler view of UB happening mostly at run time
and sometimes detectable in at least global view of things at build
time, one wouldn't be able to draw the same conclusion?
 
 
Cheers!,
 
- Alf
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jun 23 12:22AM -0700


> If you are reading this, you are one of 298 names I prayed for
> over the past two hours.
 
> May the Lord guide you and keep you always safe and secure.
 
Thanks Rick! :^)
Melzzzzz <Melzzzzz@zzzzz.com>: Jun 23 07:26AM

>> over the past two hours.
 
>> May the Lord guide you and keep you always safe and secure.
 
> Thanks Rick! :^)
We fast half a year, and pray non stop.
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jun 22 11:14PM -0700

On 6/22/2019 7:03 AM, Kenny McCormack wrote:
>> Show me some monkey which apear more like human and which do something
>> like human
 
> George W. Bush?
 
LOL!
Szyk Cech <szykcech@spoko.pl>: Jun 23 07:23AM +0200

W dniu 22.06.2019 o 19:08, Horizon68 pisze:
> Mac OS X on (x86)
Not exists. Mac OS X runs only on AMD64 compatible.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jun 22 11:13PM -0700

On 6/22/2019 10:23 PM, Szyk Cech wrote:
> W dniu 22.06.2019 o 19:08, Horizon68 pisze:
>> Mac OS X on (x86)
> Not exists. Mac OS X runs only on AMD64 compatible.
 
I used to like Mac on a Motorola.
G G <gdotone@gmail.com>: Jun 22 04:30PM -0700

thanks.
 
> Alt.os.development.
 
> --
> Rick C. Hodgin
 
thanks, i have a question about scheduling to ask
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)