Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #67948
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Why does this work on Xcode ??? |
| Date | 2019-08-25 23:32 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <qjuuph$pam$1@dont-email.me> (permalink) |
| References | (16 earlier) <qjqfe5$o97$1@dont-email.me> <qjtmjl$pfp$1@dont-email.me> <qjtr6v$hvu$1@dont-email.me> <qju1d7$iqu$1@dont-email.me> <qju8ho$pmq$1@dont-email.me> |
On 25/08/2019 17:12, Alf P. Steinbach wrote: > On 25.08.2019 15:11, David Brown wrote: >> On 25/08/2019 13:25, Alf P. Steinbach wrote: >>> On 25.08.2019 12:06, David Brown wrote: >>>> On 24/08/2019 06:45, Alf P. Steinbach wrote: >>>>> On 24.08.2019 01:49, James Kuyper wrote: >>>>>> On 8/23/19 5:07 PM, Alf P. Steinbach wrote: >>>>>>> On 23.08.2019 16:37, David Brown wrote: >>>>>>>> On 23/08/2019 15:28, James Kuyper wrote: >>>>>> ... >>>> >>>>>> It doesn't change the observable behavior. Stack usage isn't >>>>>> observable. >>>>>> The observable behavior won't occur at all if the program runs out of >>>>>> stack space, but that's also a possibility for the iterative >>>>>> version of >>>>>> the program, so it doesn't count as a difference in the observable >>>>>> behavior. >>>>>> >>>>>>> With the original code one is guaranteed that it will complete. >>>>>> >>>>>> From what do you derive that guarantee? >>>>> >>>>> The standard guarantees it. "shall ... within its resource limits ... >>>>> correctly execute that program". >>>>> >>>>> When the resource requirements are known at compile time, there is no >>>>> question about it: if the program loads, and the provided resources >>>>> are >>>>> sufficient for those known requirements, it will execute correctly. >>>>> >>>> >>>> The resource requirements most certainly are /not/ known at compile >>>> time >>>> in general. >>> >>> What matters is that there are cases where the resource requirements are >>> known at compile time. >> >> For programs, rather than particular functions or parts of a program, >> those cases are negligible outside of specialist cases in >> high-reliability embedded programming. Agreed? >> >>> >>> Those cases happen to include Tim's example. >> >> True. That applies to both the recursive and iterative versions of his >> code. >> >>> >>> The programming-in-general case is irrelevant for Tim's case, which >>> reduces to the absurd conclusion that no provably correct C++ program >>> can be made. >>> >> >> In general, you can't prove that C++ programs are correct. It is, I >> would think, very rare when you can do so. And even then the proof is >> dependent and qualified - a program may be proven "correct for >> conforming compilers", "correct for provably correct cpus (good luck >> finding one)", and so on. >> >> Provably correct programming is important - it forms a theoretical basis >> on which practical work can be done. But it doesn't happen much in real >> coding - it requires far too much detail, and far too many restrictions >> and limitations for most work. >> >>> >>> [snipalot associatively suggestive irrelevancies] >>> >>>>> In practice, as you know, that's done by specifying the minimum stack >>>>> size in the build of the program, which ensures that it either >>>>> loads and >>>>> runs correctly, or else fails to load. >>>> >>>> That might be true in very limited practice. But you can't extrapolate >>>> from experience of one Windows compiler and a misunderstanding of the >>>> difference between a compiler and a linker, and assume it applies "in >>>> practice" for other cases. >>> >>> What misunderstanding of compiler and linker? What experience limited to >>> one Windows compiler? >> >> Compilers do not know anything about stack size - at least, not for any >> part involved in supporting the standard language. > > A compiler does know the size of a function's stack frame. It usually > emits instructions to adjust the stack pointer, as part of establishing > the frame, in the function prolog. So any C++ compiler knows a bit about > the stack size. Yes, a compiler knows a /bit/ about stack size. It doesn't know everything. In particular, while it knows about the stack usage within most functions, it rarely knows the usage of functions it calls, especially if these are outside the current translation unit. It can't know about functions linked at run-time, it rarely has a realistic call tree of the functions in the program itself (since call trees are often dynamic based on run-time properties), and it hasn't a hope when faced with multiple threads, recursion, and call-backs. > > I think you meant something else than what you literally wrote. > I don't think I expressed myself very well. The standards don't cover stack usage at all, in any way. And for anything outside the program code, the compiler hasn't a clue. (I would be glad if object formats /did/ included such information, at least for static linking.) > But then, your argumentation against me has been about what I literally > wrote, with a bit of context removed. > > >> Information about >> stack size is sometimes given to linkers, > > That's true, just as it would be true to say that it's sometimes given > to the compiler, which is often how the linker is invoked in C++. Until you are talking about link-time optimisation (when the build process really gets complicated), the compiler typically does not invoke the linker. (It's not good to be too categoric here - there are many ways of organising tools.) > Especially with g++ it's just too dang impractical to invoke ld directly > for linking of C++ code. One lets the front-end g++ do the job of > applying the requisite options for C++ linking. Ah, I see what you are thinking about. But "g++" (or "gcc") is not the compiler. It is a driver program, that calls the compiler, assembler, linker, and other utilities as needed. > > I can't recall saying that a stack size option should be given to the > compiler, or to the linker, and you did not quote any such statement; > instead you quoted me writing "in the build". Which means you're again > trying to convey an impression that you know is false. > > Which, again, is called lying. No, lying would be making intentionally misleading and false statements. I was certainly under the impression that you had said the stack size was given to the compiler - if you didn't, then I made a mistake. However, you have certainly made claims (unjustified in general) that the compiler knows all about stack usage of the code, and that it knows if the program's stack usage is within the stack available. I don't know how you expect that to work out if the compiler doesn't know the stack size available to the program. > > Anyway your idea that such an option can only be given to the linker is > incorrect, and I know that you know that that is incorrect. I didn't say anything like that. (But I accuse you of being mistaken, not of lying.) I only said that was a common case, in my experience. > With Visual > C++ the compiler option to set stack size is `/F<n>`. With g++ (and > hence clang) it can apparently only be given as a linker option, as > `--stack <n>`. But it can be given to the compiler, which forwards it, > as any linker option can, as `-Wl,--stack,<n>`, which for C++ would be > the preferred way due to raw use of `ld` being impractical. I don't know how MSVC handles this sort of thing. But for gcc, you are giving the option to the /driver/ program, which passes it on to the linker, not the compiler invocation. (The "-Wl," options are all passed to the linker - certain other options are also passed to it.) My guess - and it is only a guess - is that MSVC has a somewhat similar system to gcc regarding the split between a driver program, the compiler, and the linker (and assembler, and maybe compilers for other languages, and assorted utilities). > > Even if like me you don't go around remembering the specific options, > you're not an inexperienced novice that doesn't know about the basic > tool usage, so also this was a lie. > I /do/ remember all sorts of specific options - probably more than is healthy. But you were wrong about how gcc and the options work. Please stop accusing me of lying. Tell me you think I'm wrong if you think that is the case - I get things wrong sometimes. Tell me if you think I've written something stupid or jumbled - I do that too. But I am not lying, which is a different thing altogether. > And again, I didn't specify how to do it, or using which of compiler and > linker: that would be in your fantasy, if you /believed/ what you wrote. > > >> which can then be put in >> OS-specific program headers or used during the linking process to make >> the information available to the program. > And in many programs, on >> many systems, you don't specify the stack size >> during build - you get the default for the system executing the program. >> >> In Linux, for example, the default stack size is set by the environment >> executing the program (and can be changed by the user). A running >> program can also extend its own size at run time. There is no (AFAIK) >> equivalent of the Windows PE header information about the required stack >> size that could be set at link time. > > Yes, that's right, I failed to think of that. I've never needed to do > that. But then I continued, which you snipped, > > "But conceivably it could be done in other ways, even for each > execution. However it's done, when a fixed resource requirements program > produced by a conforming compiler is run, it produces a correct result." > > As I see it, "However it's done" covers the Linux way. I didn't think it was worth commenting on everything you wrote. Anyway, neither method in Linux (ulimit by the user, or a run-time call within the program) lets the compiler know, at compile time, what stack space is available to the program. (Conceivably, a compiler could take a command-line switch for stack size and automatically generate a run-time call to request that stack space at the start of main. I know of no such compiler, but it is conceivable.) And this is all beside the point as stack size is not relevant to conformity. > > It's a little imperfection that you could have noted with fact, instead > of spewing out a series of personal lies. > If you accuse me of lying again, it will be the end of the discussion. > >> [snip] >>> Which means that this argumentation you offer is not offered in good >>> faith, which means it's FUD. >>> >> >> Cut down on the paranoia, and you'll enjoy these discussions more. > > I decided some years ago to not let people get away with provable lies. > When people make mistakes, it can be helpful to correct them (especially when the mistakes become a matter of public record). When people are lying, they are usually not worth bothering about. > So I prove them. You have been factually inaccurate throughout the discussion. > > That's not paranoia, and you know it. > Do you /really/ think people would waste time concocting a web of lies and deceits in a technical Usenet thread? To what purpose? Do you think I (and others whom you also have accused of various types of attack) am conducting some sort of personal vendetta against you, perhaps to tarnish your reputation on Usenet? Do you perhaps think I am trying to look good by making you look bad? Do you think I am so insecure that I will lie myself into a deeper hole rather than admit to being shown to be wrong? Or do you have some other theory? Few people lie without very good reason - what do you think my reasons are? Let me give you a clue - you are not /that/ important that anyone would bother lying for your sake.
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Why does this work on Xcode ??? Bob Langelaan <bobl0456@gmail.com> - 2019-07-16 22:03 -0700
Re: Why does this work on Xcode ??? Paavo Helde <myfirstname@osa.pri.ee> - 2019-07-17 08:46 +0300
Re: Why does this work on Xcode ??? Öö Tiib <ootiib@hot.ee> - 2019-07-17 00:06 -0700
Re: Why does this work on Xcode ??? Öö Tiib <ootiib@hot.ee> - 2019-07-17 01:44 -0700
Re: Why does this work on Xcode ??? Juha Nieminen <nospam@thanks.invalid> - 2019-07-17 07:46 +0000
Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-07-17 09:12 -0400
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-17 17:01 +0200
Re: Why does this work on Xcode ??? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-07-17 22:15 +0100
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-17 23:29 +0200
Re: Why does this work on Xcode ??? Christian Gollwitzer <auriocus@gmx.de> - 2019-07-19 08:27 +0200
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-19 09:09 +0200
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-19 09:24 +0200
Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-10 11:18 -0700
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-10 21:05 +0200
Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-22 10:28 -0700
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-22 19:50 +0200
Re: Why does this work on Xcode ??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-08-22 23:45 +0100
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-23 07:22 +0200
Re: Why does this work on Xcode ??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-08-23 13:12 +0100
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-23 16:02 +0200
Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-18 08:50 -0700
Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-23 09:28 -0400
Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-23 16:37 +0200
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-23 23:07 +0200
Re: Why does this work on Xcode ??? Richard Damon <Richard@Damon-Family.org> - 2019-08-23 19:10 -0400
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-24 06:49 +0200
Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-23 19:49 -0400
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-24 06:45 +0200
Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 12:06 +0200
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-25 13:25 +0200
Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 15:11 +0200
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-25 17:12 +0200
Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 23:32 +0200
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-26 11:51 +0200
Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-26 13:26 +0200
Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 11:36 +0200
Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-25 13:27 +0200
Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 15:15 +0200
Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-26 00:43 -0400
Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-24 04:58 -0700
Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-26 09:53 -0700
Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-28 18:03 -0700
Re: Why does this work on Xcode ??? Öö Tiib <ootiib@hot.ee> - 2019-07-19 00:20 -0700
Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-09 07:41 -0700
Re: Why does this work on Xcode ??? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-24 19:49 +0200
Re: Why does this work on Xcode ??? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-07-21 11:41 +0000
Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-10 09:29 -0700
csiph-web