Tutorials on Memory are Lacking

[Computergeek01]

@ cire: Who's definition of undefined are you using here? More accurately, the behavior of this program is unspecified meaning that the standard defers the requirements of its behavior to some other parameter. In this case it's the calling convention that takes precedence, but that is only because a dozen other factors do not come into play in this specific instance. I'm not splitting hairs here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
Section 1.3 outlines the definitions that I'm following (SIDE_NOTE: I personally think that the guy who wrote the definition for 'ill-formed' is well overdue for a sharp kick to their ass). I never stated that the observed behavior of this program was indicative of C++ standard behavior. In fact I have spent an unhealthy amount of time and energy rephrasing things to avoid giving anyone that impression.

Keep in mind that the language specification of the function (which is a component of the calling convention) is part of the implementation; although I purposefully avoided using the term "implementation defined" specifically because the definition that appears in the above document does not fit. I tried and failed to introduce my own terminology by calling this behavior "platform-specific\dependent" and I'm starting to think that me dancing around terms in the standard is at least half of the reason that my posts look like so much insane non-sense.

Any chance you can point to that documentation?

Sure, for what function? From which release of which compiler adhering to which standard? On what OS(Kernel) running on what architecture? Under what circumstances? With what optimization level set? Debug or Release? Break points or no¹? Statically or dynamically linked¹? These are of course rhetorical questions, I'm obviously not going to run around the net like a jack-ass seeking approval for your amusement. If you have been following this thread then you know why there is no definitive answer to this question given the complete absence of information that you have provided.

¹: Assuming it's relevancy, otherwise omit qualifier.

@ dhayden: I see you're post. You've clearly been skipping around the thread and just causally gleaming information from here or there. So I will try again in the morning to address your post with a response that isn't fixated on eviscerating your asinine or otherwise loaded comment. I've already stated my dislike of people changing the parameters of a problem to fit their use-case version of an argument so I can only assume that you are trying to goad some kind of a reaction, I'll ignore that. Also please note that your blurb:

Nope.

suggests, I know incorrectly given your past contributions, that you are in over your head on this topic. Did you even bother to notice how everyone else who contested my statements either provided a link to an article or a commonly recognized quotation\statement from the standard? Don't let laziness or apathy discredit you here. I am making a statement given the information provided from the OP explaining the reason for his observation if you have some other evidence that shows that this behavior is different from that which is observed without significantly changing the context then I would love to see it. I am not some lounge lizard looking for attention.

If I wanted mindless regurgitation of irrelevant information I would still be visiting Reddit.

[cire]

Computergeek01 wrote:

Who's definition of undefined are you using here?

The only one that matters of course. That given by the standard. Definition follows; emphasis, mine.

IS wrote:

undefined behavior
behavior for which this International Standard imposes no requirements
[ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed.
—end note ]

We're clearly talking about using erroneous data (an invalid pointer) so this is undefined behavior. It is not unspecified behavior, nor is it implementation defined.

Computergeek01 wrote:

In this case it's the calling convention that takes precedence, but that is only because a dozen other factors do not come into play in this specific instance. I'm not splitting hairs here:

Linkage specifications have nothing to do with observable code behavior, and certainly do not come into play here.

Sure, for what function? From which release of which compiler adhering to which standard? On what OS(Kernel) running on what architecture? Under what circumstances? With what optimization level set? Debug or Release? Break points or no1? Statically or dynamically linked1? These are of course rhetorical questions, I'm obviously not going to run around the net like a jack-ass seeking approval for your amusement. If you have been following this thread then you know why there is no definitive answer to this question given the complete absence of information that you have provided.

The "function" provided in the OP. I'll settle for the documentation for any release setting of any compiler on any OS. You claim such documentation exists. I'm asking for you to verify your claim, not "run around the net like a jack-ass seeking approval."

[Edit: I wonder if the OP has seen the pointer-hotel analogy given at http://stackoverflow.com/a/6445794 ]

[helios]

We're clearly talking about using erroneous data (an invalid pointer) so this is undefined behavior. It is not unspecified behavior, nor is it implementation defined.

However, a particular implementation may choose to define a behavior that is undefined in the standard. I very much doubt that's the case here, though.

[LB]

helios wrote:

However, a particular implementation may choose to define a behavior that is undefined in the standard.

What does that even mean? If an implementation doesn't do... what you said... then are you saying that compiled executables are in a quantum state? If I look at the bytes on tuesday they're different from when I looked on monday? My point is, how could an implementation not choose to do... what you said... ?

If you meant "document" instead of "define" then that makes much more sense.

[MiiNiPaa]

My point is, how could an implementation not choose to do... what you said... ?

Implementation does not have to be consistent with that behavior. Bytes indeed do not change and you might expect to get similar results between runs (unless you are using uninitialised memory. Then you depends on what had been left here)

But changes to compiler, compiler version, compiler options, moon phase, unrelated changes in your code, your pc specs could result in different compiled executable and behavior. I posted examples of that before. I posted links to articles which shows how agressive compiler optimisations could be. Undefined state is so weak, that it is indeed has some quanum properties and can result in time travel. Bugs that do not exist in debug builds are pretty common.

[LB]

That's not what I was trying to emphasize - my point is that we keep using the word "define" in different ways and then interpreting it differently.

[helios]

If I look at the bytes on tuesday they're different from when I looked on monday

They might if you recompiled. For example, a compiler might perform preincrements between the same sequence points in a random order, such that the executable output of ++i + ++i would be non-deterministic.

If you meant "document" instead of "define" then that makes much more sense.

Same thing, really.

[LB]

helios wrote:

Same thing, really.

The difference is that one is more ambiguous and open to interpretation than the other. Most of the discussion happening here is a direct result of (mis)using "define" and then (mis)interpreting it differently.

[JLBorges]

As I see it: in the context of C++, 'undefined' in undefined behaviour means:
a. the standard does not explicitly define of the observable behaviour, and
b. the standard does not explicitly categorise the behaviour is either 'unspecified' or 'implementation-defined'.

A conforming implementation is free to document (define) the behaviour that is left undefined by the standard.

IS:

Permissible undefined behavior ranges from ..., to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to ...

C Rationale (C99, 2003):

The terms unspecified behavior, undefined behavior, and implementation-defined behavior are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe.
...
Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior.

The term 'stack', may also have been the cause of some ambiguity in this rambling thread . A FIFO data structure, yes; but implemented in software as in std::stack<> or supported by the hardware with push/pop/call/return machine instructions? Would an object with automatic storage duration placed in a heap-based call-stack be using 'heap allocated memory' or 'stack allocated memory'?

A succinct description of such a run-time stack found on some IBM mainframes:
http://stackoverflow.com/questions/10900885/are-there-stackless-or-heapless-implementation-of-c/10903928#10903928

For the record, I completely agree with the assertions of msknapp84 in the beginning of this thread about our tutorials.