- "Will Carbon Replace C++?" by Manuel Rubio - 6 Updates
- Is this safe? - 15 Updates
- strange error (QT Creator 4.12.2, based on QT creator 5.14.2) - 4 Updates
| David Brown <david.brown@hesbynett.no>: Mar 02 10:38AM +0100 On 01/03/2023 23:53, Lynn McGuire wrote: > Dude, have you commercially worked with any computer software in the > last ten years ? Commercially means that you got paid by somebody for > your work. I get paid for all my programming work - and I use gcc for the solid majority of it. I used to make much more use of commercial compilers, and for the most part, I am glad to be done with them. It is not a matter of the price of the tools - we have on several occasions paid for commercial packaging of gcc toolchains. It is simply that I find them to be better tools for helping me do my job. If you are talking about getting paid for work on compilers, then the solid majority of gcc development (and presumably also clang) is done by people who are paid to do the job. |
| scott@slp53.sl.home (Scott Lurndal): Mar 02 03:24PM >Dude, have you commercially worked with any computer software in the >last ten years ? Commercially means that you got paid by somebody for >your work. Yes, of course. And paid quite well. And for the last quarter of a century, exclusively using gcc and sometimes clang or systemC. |
| Muttley@dastardlyhq.com: Mar 02 03:39PM On Thu, 02 Mar 2023 15:24:10 GMT >>your work. >Yes, of course. And paid quite well. And for the last quarter >of a century, exclusively using gcc and sometimes clang or systemC. Every single company I've worked at both big and small that wrote software for linux in C/C++ used gcc so I've no idea what that guy is talking about. Seems to me he's the one who doesn't have any commercial experience, or if he does its exclusively working in Windows. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Mar 02 02:13PM -0600 On 3/2/2023 9:24 AM, Scott Lurndal wrote: >> your work. > Yes, of course. And paid quite well. And for the last quarter > of a century, exclusively using gcc and sometimes clang or systemC. So none of these projects included Fortran ? Lynn |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Mar 02 01:18PM -0800 >> Yes, of course. And paid quite well. And for the last quarter >> of a century, exclusively using gcc and sometimes clang or systemC. > So none of these projects included Fortran ? Your assertion is that Fortran is largely a hobby language, not a development language. The rise of freeware Fortran compilers does not support that assertion. C and C++ are mostly compiled with freeware compilers, even by professional C and C++ programmers. The fact that someone posting to a C++ newsgroup hasn't used Fortran doesn't support that assertion. The sets of professional C++ programmers and professional Fortran programmers are likely to be mostly disjoint. Taking a very quick look, I see Fortran questions on Stack Overflow and moderate activity in comp.lang.fortran. I believe that Fortran is still used professionally in some fields. I don't have much direct evidence for that. What evidence do you have? -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| scott@slp53.sl.home (Scott Lurndal): Mar 02 09:26PM >> Yes, of course. And paid quite well. And for the last quarter >> of a century, exclusively using gcc and sometimes clang or systemC. >So none of these projects included Fortran ? Would you find that surprising? Fortran has been niche for almost four decades now and is still heavily used in certain fields. |
| Richard Damon <Richard@Damon-Family.org>: Mar 01 09:37PM -0500 On 3/1/23 5:29 AM, Malcolm McLean wrote: > } > This function will always return 10, so it's to specification. But it's the source > of a bug. It meets the specifications only if there is not a reasonable set of general groud rules that apply to all specification (unless specifically noted). For example, a typical ground rule is that all funcitions should free (or otherwise correct release resources) or pass off control to another entity all items that have had there control passed to them or they have created. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 01 10:30PM -0800 On Thursday, 2 March 2023 at 04:37:50 UTC+2, Richard Damon wrote: > (or otherwise correct release resources) or pass off control to another > entity all items that have had there control passed to them or they have > created. Still it is better example as it at least does not dereference nor do pointer arithmetic with nullptr. |
| Muttley@dastardlyhq.com: Mar 02 09:07AM On Wed, 1 Mar 2023 12:53:22 -0800 (PST) >> int func() { getchar(); return 10; } >> meet the specification as well? >This is where you get trapped by C's misuse of the term "function". Its not a misused, its perfectly valid in the programming sense. >If the term "function" were used in the proper mathematical sense, Programming optionally uses maths, bit its not maths. |
| Muttley@dastardlyhq.com: Mar 02 09:08AM On Wed, 01 Mar 2023 19:53:36 +0000 >> Bug free? >No, the code does not meet it's specification. In fact, the code has >no defined behaviour at all. The specifaction is it returns 10. It does that. You're assuming it will always crash which isn't necessarily the case depending on what machine its running on. |
| David Brown <david.brown@hesbynett.no>: Mar 02 10:29AM +0100 On 01/03/2023 19:48, Keith Thompson wrote: > that it's just a bug. And as far as the C standard is concerned, > there's no guarantee that the function will return 10. > (It has additional UB if int is 16 bits.) Sure. But it would not meet the specifications even if "ptr" were initiated to point to a valid array of 100,000 int's (unless that array were private to the function - in which case it would be correct, but inefficient). There's been a few posts here attempting to set "ground rules" for specifications - things that have to be followed in addition to the explicit function-specific specification. I think perhaps a good choice for that, especially in the context of C and C++, would be to say that any potential influence on observable behaviour of the program has to be specified. Observable behaviour is, fundamentally, part of the output of a function. For those familiar with gcc and clang function attributes, you could say that functions must be "pure" by default - any deviation from this, potentially affecting observable behaviour, needs to be in the specifications. |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Mar 02 01:32AM -0800 > The specifaction is it returns 10. It does that. You're assuming it will > always crash which isn't necessarily the case depending on what machine its > running on. Not necessarily. It might crash or might not. Or it might even overwrite the area of memory used to hold return values, and return a value other than 10. |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Mar 02 01:48AM -0800 On Wednesday, 1 March 2023 at 21:13:59 UTC, Ben Bacarisse wrote: > So lets' call them all "procedures" for the moment and get back to the > question at hand. Should a specification be taken to be essentially > minimal? I would say so. If functions are functions then the bits on function entry define the state of the bits on function exit, and if they match, the function is correct. Programming functions often have an additional specification in terms of Big O running time. It is of course possible to break the spirit of this by writing code which is formally O(N) but in reality is much slower for any likely N than a naive O(N squared) function. However normally you have to either be perverse or to be using a weird and wonderful recasting of the problem to do this. Often there's a straightforwards way of calculating a function, and a more complicated way which has advantages of speed, numerical stability, or the szie of input it can handle. Sometimes intermediate calculations are mathematically unnecessary, but they make it easier for a human reading the code to follow along. I don't think we can fairly say that a piece of code must optimise something (execution speed, clarity, size of data accepted, code size) before it is "to specification". But maybe we can say that it mustn't grossly pessimise anything. There's a kind of implied specification in any instruction. If I say "get me a cup of tea" then either a mug or a teacup would meet the instruction. But not a sporting trophy filled with tea. I'd legitimately complain that my instructions had been interpreted perversely. |
| Muttley@dastardlyhq.com: Mar 02 09:56AM On Thu, 2 Mar 2023 01:32:07 -0800 (PST) >> running on. >Not necessarily. It might crash or might not. Or it might even overwrite the >area of memory used to hold return values, and return a value other than 10. The return value will be a literal in the program text area and if it changed that it would probably be changing the program code itself. Regardless - the function returns 10 as per the spec. The spec doesn't mention that it also shouldn't crash. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 02 04:02AM -0800 > changed that it would probably be changing the program code itself. > Regardless - the function returns 10 as per the spec. The spec doesn't mention > that it also shouldn't crash. Are you suggesting that "should not leak resources", "should not crash, should not hang, should not reboot the system" etc. (billions of bad things) "when preconditions are met" must be specified per each function? Good luck trying to find anyone who wants to pay for that. |
| David Brown <david.brown@hesbynett.no>: Mar 02 03:00PM +0100 On 02/03/2023 13:02, Öö Tiib wrote: > should not hang, should not reboot the system" etc. (billions of bad > things) "when preconditions are met" must be specified per each function? > Good luck trying to find anyone who wants to pay for that. It is not actually /entirely/ a bad idea to specify what should /not/ happen, at least in some circumstances. I don't think it is helpful in software specifications here - I think it is entirely reasonable to view "no possible impact on observable behaviour unless specified" as standard. It is also normal for things like "must be written in C++17 standard", "must be clear and maintainable code", "must be reasonably efficient", etc., to be part of a "global" specification for code. (Projects will, obviously, vary wildly in regards to their needs here.) However, for some things, there can be other aspects that are requirements but which do not fit quite so well with the idea of pre- and post-conditions, such as speed or timing limits. Formally, these could be viewed in terms of inputs and outputs, much like input/output actions can be viewed in pure functional languages in terms of inputting the world before the action, and returning the world after the action. But it could easily be messy, and there are better ways to specify such requirements. Things can get more complicated in hardware, especially from the security viewpoint. There are so many minor effects that are not intended to be observable, and are not part of the functionality, making them very difficult to specify. Here you can't just say "don't do anything else" - that is fine for abstract ideas like software, but not for real, physical things. How can you specify "the cpu should not be vulnerable to Spectra or Meltdown or Rowhammer or similar attacks" ? At best, once an attack is described, you can specify for that particular effect - but you can't specify for things that haven't yet been considered. And if you can't specify it, you can't be sure it is correct. |
| Muttley@dastardlyhq.com: Mar 02 03:38PM On Thu, 2 Mar 2023 04:02:55 -0800 (PST) >should not hang, should not reboot the system" etc. (billions of bad >things) "when preconditions are met" must be specified per each function? >Good luck trying to find anyone who wants to pay for that. Thats my point! Specs do NOT include that sort of detail so a function can follow a spec perfectly but still crash or fail in some other way which is contrary to what Mr Brown was saying. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 02 07:59AM -0800 On Thursday, 2 March 2023 at 16:01:19 UTC+2, David Brown wrote: > happen, at least in some circumstances. I don't think it is helpful in > software specifications here - I think it is entirely reasonable to view > "no possible impact on observable behaviour unless specified" as standard. It is typically specified on some higher level guidelines and standards. These are often hundreds of pages documents even for C ... like that should not pass wrongly aligned pointers, should not use potentially tainted data as (part of) format strings, should not perform operations on "device" files, should not copy FILE objects, should not leave return values that may indicate failure (like calloc, snprintf etc.) unchecked etc. I was asking about specification to *each* function. > "must be clear and maintainable code", "must be reasonably efficient", > etc., to be part of a "global" specification for code. (Projects will, > obviously, vary wildly in regards to their needs here.) Yes, and also the higher level documents differ per project. > best, once an attack is described, you can specify for that particular > effect - but you can't specify for things that haven't yet been > considered. And if you can't specify it, you can't be sure it is correct. Known hardware vulnerabilities can be worked against with software or by using compilers/tools that are designed to work against those. Unknown vulnerabilities can be only fixed with patches after those become known. |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Mar 02 11:08AM -0800 > On Wed, 01 Mar 2023 19:53:36 +0000 > Ben Bacarisse <ben.u...@bsb.me.uk> wrote: > >Mut...@dastardlyhq.com writes: ... > The specifaction is it returns 10. It does that. You're assuming it will > always crash which isn't necessarily the case depending on what machine its > running on. He didn't say "will always crash", he said "no defined behavior". If the standard were changed to guarantee that this code would always crash, that would constitute defined behavior. Undefined behavior means "behavior for which this document [the C++ standard] imposes no requirements" (3.30). That code dereferences a null pointer value, and adds a number greater than 0 to that pointer value - two separate reasons whey the behavior is undefined. Some other document might define what the behavior of that code is, but the C++ standard does not. A program can only be considered to meet a specification if there is something, somewhere, that defines what the behavior of that program will be, and only if that behavior matches the specification. Can you identify some other relevant document, anywhere, that does define the behavior of this code? What, specifically, does that document say about dereferencing null pointers and adding non-zero quantities to null pointers? |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Mar 02 11:16AM -0800 > On Thu, 2 Mar 2023 04:02:55 -0800 (PST) ... > Thats my point! Specs do NOT include that sort of detail so a function can > follow a spec perfectly but still crash or fail in some other way which > is contrary to what Mr Brown was saying. If the crash does not occur until after the routine has returned a value of 10, and the calling routine has completed everything it needs to do, that might be the case. But if this code results in a crash, it's likely to occur before the return statement. Code which fails to return a value of 10, because it caused a crash, cannot be said to have met the specification. Code which defers the crash until after the value of 10 has been returned, but before the calling routine can make any use of that value, is just as bad. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 02 07:35PM > The specifaction is it returns 10. It does that. You're assuming it will > always crash which isn't necessarily the case depending on what machine its > running on. I am not assuming that. I am assuming the semantics as defined by the C language standard which states that the code you posted as, to put it informally, no meaning at all. -- Ben. |
| MarioCPPP <NoliMihiFrangereMentulam@libero.it>: Mar 02 05:25PM +0100 I have this situation : int32_t * Pointer32; // is a 4 byte signed int int8_t * Pointer8; // is a "signed char" // pointer allegedly "unaligned". Pointer32 = new int32_t [10]; // supposedly ALIGNED a multiple of four byte addresses Pointer8 = static_cast <int8_t *> (Pointer32); ERROR : STATIC CAST FROM int * to signed char * IS NOT ALLOWED. I am asking why that ? I mean, the reverse, maybe with a warning, seems weird (at best very slow). But casting a MORE RESTRICTIVELY ALIGNED pointer to one LESS RESTRICTIVELY ALIGNED seems pretty reasonable. Why not ? how comes I cannot access single bytes aligned whatever in an int array ? The type does not even have "NAN" problem or the drawback i.g. of creating underflows, overflows, denormalized values that can happen accessing FLOAT / DOUBLE on a random address bytewise mode. But integral types SHOULD be accessible byte by byte without problems, and a single byte does not have alignment restrictions ... I am at a loss ! help :D -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti MarioCPPP |
| MarioCPPP <NoliMihiFrangereMentulam@libero.it>: Mar 02 05:27PM +0100 On 02/03/23 17:25, MarioCPPP wrote: > Pointer32 = new int32_t [10]; > // supposedly ALIGNED a multiple of four byte addresses > Pointer8 = static_cast <int8_t *> (Pointer32); Using an old style casts deserves just a warning ... Pointer8 = (int8_t *) (Pointer32); but it seems an ugly solution for a problem still not understood, so please explain me the "ratio" of the error with static_cast -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti MarioCPPP |
| Bo Persson <bo@bo-persson.se>: Mar 02 05:44PM +0100 On 2023-03-02 at 17:27, MarioCPPP wrote: > Pointer8 = (int8_t *) (Pointer32); > but it seems an ugly solution for a problem still not understood, so > please explain me the "ratio" of the error with static_cast The problem isn't about alignment, but that the code uses a pointer to signed char. The standard allows inspecting bytes as unsigned char, but has no special allowance for signed char. |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Mar 02 09:44AM -0800 On 03/02/23 8:25 AM, MarioCPPP wrote: > I mean, the reverse, maybe with a warning, seems weird (at best very slow). > But casting a MORE RESTRICTIVELY ALIGNED pointer to one LESS > RESTRICTIVELY ALIGNED seems pretty reasonable. Why not ? "Aligned"? Why are you even mentioning alignment in this context? What does it have to do with anything? C++ is a strictly typed language and `int8_t *` and `int32_t *` are simply two unrelated pointer types. For `static_cast` that's the end of the line. You wanna transgress to lower level representations and re-interpret `int32_t` object representation as a sequence of bytes? That's what `reinterpret_cast` is for. And that's where the matters of alignment begin to kick in. -- Best regards, Andrey |
| 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