- Why does this work on Xcode ??? - 8 Updates
- "C++: Size Matters in Platform Compatibility" - 5 Updates
- How to get standard paths?!? - 5 Updates
- About getters/setters - 2 Updates
- What is easiest to use static C++ code analyser? - 1 Update
| David Brown <david.brown@hesbynett.no>: Aug 25 11:36AM +0200 On 23/08/2019 23:07, Alf P. Steinbach wrote: > As an example, rewriting a function with loop that uses a fixed size > storage known at compile time, to a recursive function that uses storage > proportional to the function argument, changes the behavior. Not as far as the language is concerned, no. For the programmer, many things are important that are not covered by the language itself. The same therefore applies to compilers. But as far as language conformance goes - and that is what we are discussing, /nothing/ else matters. It doesn't matter if the compiler takes 15 years to finish compiling "Hello, world". It doesn't matter if it uses 26 MB of ram for that program. It doesn't matter if it generates the code as a Turing program and includes a simulator in the exe file. > With the original code one is guaranteed that it will complete. Nonsense. The C++ standards only describe how the language is interpreted and certain aspects of the behaviour. They don't give guarantees about the environment, resources, timings, etc. The /compiler/ might give you more guarantees. The compiler distributor might guarantee that the compiler will generate sane code or you get your money back. (gcc guarantees that if the compiler breaks, you get to keep both halves.) But the C++ standards - the only things relevant for conformance - give no such guarantees. > compiler is formally permitted to change a program that guarantees a > result if it compiles and loads, into a program that almost guaranteed > does not produce a correct result. No. (You seem to be totally misunderstanding the concepts of observable behaviour, C++ conformance, and the role of the language standard in this post.) The compiler can manipulate the code in any way, preserving the observable behaviour, without affecting conformity. Resources don't come into it - usually the compiler doesn't know the resources either. It is not unknown, for real, quality compilers, for different choices of compiler flags to result in programs that work in their target environment or don't work - while the observable behaviour of the code on a target with enough resources is unaffected. This can happen in many ways in resource-constrained embedded systems - optimisation flag choices can make the program too big for flash, use too much ram, too much stack, take too long to run. But these aspects are usually beyond the knowledge of the compiler, and are certainly well beyond the scope of the standards - and therefore irrelevant for conformity. > No, that's not the same way. > In this example a fixed storage requirement is not changed to a > requirement of storage depending on a parameter. I am sure it would not stretch your imagination to adapt the example to your liking. The compiler can insert code to calculate "a" digits of pi between these two statements. Happy? >> thus it would not affect the conformance of the compiler. > It would affect observable behavior. One would get wrong results or > crashes. Instead of with a conforming compiler, correct results. No. Please re-read the part of the C++ standard explaining what "observable behaviour" is in regards to the standards. It does /not/ mean "behaviour observed by the user". >> implementation (though they have a few hints here and there) - that is >> up to the user. > That's right, but this isn't QoI, it's about correctness. Yes - I'm correct, and you're wrong :-) |
| David Brown <david.brown@hesbynett.no>: Aug 25 12:06PM +0200 On 24/08/2019 06:45, Alf P. Steinbach wrote: > 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. There are exceptions, but they are very much exceptions - for some kinds of embedded system development you can do enough static analysis to be sure of stack usage (and typically you don't have heap usage at all). Are you suggesting that during the typical Windows program compilation, the compiler knows the stack requirements of all functions called in DLLs? Are you suggesting that during compilation, the compiler knows the size of the RAM on the system it will run on? Are you suggesting the compiler knows the size of the data files provided by the user? > that doesn't matter. When the program's resource requirements are known > at compile time one can provide sufficient resources for those known > requirements. That's nice in theory, though completely unsupported by the standard and completely missing in almost every practical case. I'm taking figures out the air here, but I'd guess that for a minimum 99.9% of C and C++ programs, stack space either grows automatically as needed or the fixed size is picked as "this is going to be /way/ more than we need". > 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. > One /can/ rely on a C++ program to produce correct results. > When one ensures that it will not exceed the implementation's resource > limits. Of course. The standards say as much. > It's a different matter when the resource requirements are not known > until run time, as with a transformation from iterative to recursive. They are almost never known. Making a transformation from an iterative to a recursive algorithm is likely to make stack requirements "more unknown". And no one disagrees that that is a bad thing. But where you are /wrong/ is thinking that avoiding such transformations makes stack requirements known, or that it is remotely relevant to conformance or observable behaviour as defined by the standards. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 25 01:25PM +0200 On 25.08.2019 12:06, David Brown wrote: >> 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. Those cases happen to include Tim's example. 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. [snipalot associatively suggestive irrelevancies] > 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? Those are social arguments, arguing someone's extreme incompetence about the very basics of tool use, in direct contradiction with what you know about that person, and arguing someone's very limited experience of platforms and compilers, also in direct contradiction with what you know. Two untruths that you know are untrue, which means that you intentionally lie. And they're presented as an ad hominem argument. Which means that this argumentation you offer is not offered in good faith, which means it's FUD. [snip] - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 25 01:27PM +0200 On 25.08.2019 11:36, David Brown wrote: > No. Please re-read the part of the C++ standard explaining what > "observable behaviour" is in regards to the standards. It does /not/ > mean "behaviour observed by the user". In your opinion results are not part of observable behavior. That means you have defined yourself out of being taken seriously. Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: Aug 25 03:11PM +0200 On 25/08/2019 13:25, Alf P. Steinbach wrote: >> 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. >> 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. Information about stack size is sometimes given to linkers, 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. On small embedded systems, you regularly set a desired stack size via the linker, but never IME via the compiler. Equally regularly, your stack size is simply from the top of ram working downwards until it hits the heap growing upwards. > platforms and compilers, also in direct contradiction with what you > know. Two untruths that you know are untrue, which means that you > intentionally lie. And they're presented as an ad hominem argument. Show me how the minimum stack size is set during build time with a range of toolchains targetting a range of OS's, including "bare metal". Otherwise, I believe you are extrapolating from limited experience. There is nothing ad hominem about that - it is a statement of how your claims appear. There is also nothing ad hominem about saying your posts look like your experience here is highly focused on one platform, and probably only one compiler. There is no suggestion that this makes you a poorer programmer, or less competent - merely that it might be why you are wrong about this point. > 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. |
| David Brown <david.brown@hesbynett.no>: Aug 25 03:15PM +0200 On 25/08/2019 13:27, Alf P. Steinbach wrote: >> "observable behaviour" is in regards to the standards. It does /not/ >> mean "behaviour observed by the user". > In your opinion results are not part of observable behavior. It is not /my/ opinion that matters here. (Personally, I can usually observe the difference between programs that run as expected, and those that crash or fail.) It is the /C++ standard definition/ of "observable behaviour" that matters. Nothing else matters for conformity to the standards. How can you find that so difficult? Read 1.9 "Program Execution" of the standards. (That is the section number from C++14, I expect it is similar in other versions.) > That means you have defined yourself out of being taken seriously. Complain to the C++ standards committee, not me. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 25 05:12PM +0200 On 25.08.2019 15:11, David Brown wrote: >> 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. I think you meant something else than what you literally wrote. 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++. 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. 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. 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. 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. 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. 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. > 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. It's a little imperfection that you could have noted with fact, instead of spewing out a series of personal lies. >> 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. So I prove them. That's not paranoia, and you know it. Cheers, - Alf |
| David Brown <david.brown@hesbynett.no>: Aug 25 11:32PM +0200 On 25/08/2019 17:12, Alf P. Steinbach wrote: > 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.) >> 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. > 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. > `--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. > 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. >>> 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. |
| Robert Wessel <robertwessel2@yahoo.com>: Aug 24 11:43PM -0500 On Sat, 24 Aug 2019 20:56:52 +0200, David Brown >trillions or quadrillions of such codes; noble as this effort might be, >you would not use Unicode for such an encoding. [AF] >""" OTOH, the original Unicode spec also specifically said it was a 16-bit code. So these things sometime change. |
| David Brown <david.brown@hesbynett.no>: Aug 25 12:11PM +0200 On 25/08/2019 06:43, Robert Wessel wrote: >> """ > OTOH, the original Unicode spec also specifically said it was a 16-bit > code. So these things sometime change. But surely now that Unicode has support for Ogham Runes, it /can/ be carved in stone :-) You are right, of course - guarantees about future changes are hard to make. I guess that if Unicode ever starts to encroach on the UTF-16 limits, then UTF-16 will be dropped. |
| Richard Damon <Richard@Damon-Family.org>: Aug 25 07:33AM -0700 On 8/25/19 3:11 AM, David Brown wrote: > You are right, of course - guarantees about future changes are hard to > make. I guess that if Unicode ever starts to encroach on the UTF-16 > limits, then UTF-16 will be dropped. Yes, I know that statement, but I also know that practically, at some point the Unicode consortium will have to make some tough decisions on code points, and at some point will renege on the policy that UTF-16 as it currently exists will be able to access every code point in all future versions of Unicode. One thing to remember, and was pointed out, UTF-16 only exists BECAUSE a previous promise was broken, and UCS-2 wasn't good enough anymore for all of Unicode. One thing that could cause this is if the CJK set gets fixed and removed from being second class code points. It may not be well known, but in the process of developing Unicode, in an attempt to make it work, and to have enough code points, the characters in the three major pictograph languages where 'unified' and characters that meant roughly the same thing were combined into a single code point. It really wouldn't be that different than saying that we don't need a separate code point for the character Pi, as that is just the way to write P in Greek. (It isn't just a typography issue, as it isn't just how you write a given character, but they are 'similar' words from distinct languages.) The unification was accepted as it seemed to only possible option to try to make Unicode a 16 bit character set, and it did allow them to make the most common characters in the 16 bit basic plane. |
| Robert Wessel <robertwessel2@yahoo.com>: Aug 25 10:22AM -0500 On Sun, 25 Aug 2019 12:11:46 +0200, David Brown >You are right, of course - guarantees about future changes are hard to >make. I guess that if Unicode ever starts to encroach on the UTF-16 >limits, then UTF-16 will be dropped. The problem is that dropping UTF-16 is a nasty hit to Windows, Java and Javascript. Those are not minor users in the world. I suspect what would happen at that point is that an additional block of surrogate characters will be assigned, so that we can have both the surrogate pairs we now have for UTF-16, plus some new surrogate "triples". You could assign a block of 64 code points from the BMP, for example (if nothing else, grab some more of the private use area like they did the last time), and get six extra bits for the "triple" (or assign two 64-code-point blocks and be able to do "quads" as well). So the UTF-16 users would get hit with about the same thing that happened in the transition from UCS-2. With hindsight*, something like that should have been done the first time. Maybe have three or four blocks of 512 surrogate code points (instead of 2x2048), and allow two or three (or four) surrogate characters in a sequences (not really unlike what was done with UTF-8). *Although calling that a lack of foresight may be too kind. How many times have we been bitten by inadequate address spaces now? 65536, errr..., 1,114,112 character ought to be enough for anyone! |
| David Brown <david.brown@hesbynett.no>: Aug 25 08:27PM +0200 On 25/08/2019 16:33, Richard Damon wrote: > unification was accepted as it seemed to only possible option to try to > make Unicode a 16 bit character set, and it did allow them to make the > most common characters in the 16 bit basic plane. That is interesting information - thanks for posting it. Personally, I won't shed a tear if UTF-16 disappears. But the number of characters has to increase by a factor of 8 or so before it becomes necessary, which could allow for splitting up C, J and K. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 25 05:35AM -0700 > This is kind of similar to some compilers allowing the use of integer > types larger that intmax_t, by calling __int128 an extension (and not > "an extended integer type"). I see you are giving the same wrong arguments that you gave three years ago. C and C++ implementations must support the locale-specific native environment (assuming a hosted implementation in C). They don't get to choose what that is; they are required to document it, but the standards do not AFAICT give any freedom to choose it. If the native environment in MS Windows has more than 65K characters then the implementation is non-conforming. Besides that, regardless of what locale names are documented as being "supported", any locale whose name is accepted by the setlocale() function (ie, return value is not null) must have the property that all of its characters have distinct values that fit in a single wchar_t object. Any violation of this property means the implementation is not conforming. Note that the setlocale() calls all fall within the bounds of Standard-specified behavior. There is no wiggle room available to try to sweep these under the rug as "extensions". |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 25 03:02PM +0200 > but the standards do not AFAICT give any freedom to choose it. > If the native environment in MS Windows has more than 65K characters > then the implementation is non-conforming. Quote the part of the C++-standard that says this. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 25 06:38AM -0700 >> If the native environment in MS Windows has more than 65K characters >> then the implementation is non-conforming. > Quote the part of the C++-standard that says this. In N4659: Section 25.5.1 p1: "The contents and meaning of the header <clocale> are the same as the C standard library header <locale.h>." Section 2 (Normative references) p2: "The library described in Clause 7 of ISO/IEC 9899:2011 is hereinafter called the /C standard library/." |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 25 03:46PM +0200 > are the same as the C standard library header <locale.h>." > Section 2 (Normative references) p2: "The library described in Clause 7 > of ISO/IEC 9899:2011 is hereinafter called the /C standard library/." And where does the C-standard say that the with of wchar_t has to match the platform? |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 25 03:54PM +0200 >> of ISO/IEC 9899:2011 is hereinafter called the /C standard library/." > And where does the C-standard say that the with of wchar_t has to match > the platform? Here, the current 2019 C-draft: "3.7.3: wide character: value representable by an object of type wchar_t, capable of representing any character in the current locale" |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 25 06:16AM On Fri, 2019-08-23, David Brown wrote: > for synchronisation between members for keeping invariants, but usually > you don't want to allow any possibility of other parts of the code > making uncoordinated changes to the values. Personally, for a config struct I'd ask myself "will I create this object early and pass it once to the main application logic?". If the answer is 'yes', I'd happily pass it as const and leave it as it is. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Aug 25 12:12PM +0200 On 25/08/2019 08:16, Jorgen Grahn wrote: > Personally, for a config struct I'd ask myself "will I create this > object early and pass it once to the main application logic?". If the > answer is 'yes', I'd happily pass it as const and leave it as it is. That could well be sufficient protection, yes. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 25 06:09AM On Thu, 2019-08-22, Szyk Cech wrote: > So maybe you have some experience with those tools if so: > Please answer me to question: > What is easiest to use static C++ code analyser? The compiler itself -- the warnings which aren't enabled by default but make sense anyway. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| 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. |
No comments:
Post a Comment