- who's at fault, me or compiler? - 14 Updates
- Is this undefined behavior? - 8 Updates
- Observable end padding in arrays - 2 Updates
| Juha Nieminen <nospam@thanks.invalid>: Jul 09 07:25AM >>would imply that classes can only be instantiated if their exact internal >>structure is known, else it's impossible. > It doesn't imply anything of the sort. There's no way of interpreting "the class memory layout has to be stored in some form somewhere in the binary otherwise on the fly objects could never be created" other than that it's impossible to instantiate a class at runtime if its exact internal structure is not known. The exactly layout is not always needed. The only two things you need in certain cases are 1) the size of the class, and 2) the offsets of the member variables in whatever code is accessing those variables. Requirement 2 does not necessarily need to encode the offsets of *all* the member variables, if not all of them are ever accessed. > However the binary needs some > representation of the class and if not stripped it'll also contain the function > and attribute names too otherwise debuggers wouldn't work. Now you are bringing up debuggers, which have absolutely nothing to do with your original assertion. How big will the pileup become? |
| Bo Persson <bo@bo-persson.se>: Jul 09 10:29AM +0200 On 2020-07-09 at 09:25, Juha Nieminen wrote: >> and attribute names too otherwise debuggers wouldn't work. > Now you are bringing up debuggers, which have absolutely nothing to do with your > original assertion. How big will the pileup become? Stripping symbols is a Linux thing, nothing C++ specific. Other systems store the debug info in a separate database, and not in the binary. Bo Persson |
| boltar@nowhere.co.uk: Jul 09 08:45AM On Thu, 9 Jul 2020 10:29:52 +0200 >> original assertion. How big will the pileup become? >Stripping symbols is a Linux thing, nothing C++ specific. Other systems >store the debug info in a separate database, and not in the binary. Yes, we know how primitive Windows is in a number of respects. |
| boltar@nowhere.co.uk: Jul 09 08:48AM On Thu, 9 Jul 2020 07:25:52 +0000 (UTC) >Now you are bringing up debuggers, which have absolutely nothing to do with >your >original assertion. How big will the pileup become? If you're not able to follow a thread maybe keep out of it. I'm honestly tired of arguing with you over trivial that should be fucking obvious. |
| Bo Persson <bo@bo-persson.se>: Jul 09 11:41AM +0200 >> Stripping symbols is a Linux thing, nothing C++ specific. Other systems >> store the debug info in a separate database, and not in the binary. > Yes, we know how primitive Windows is in a number of respects. Now the "primitive" way of doing this proves that the binary doesn't have to contain all the info. Contrary to some claims. And the code still works the same when the debug database is not present. Bo Person |
| Juha Nieminen <nospam@thanks.invalid>: Jul 09 01:01PM >>original assertion. How big will the pileup become? > If you're not able to follow a thread maybe keep out of it. I'm honestly > tired of arguing with you over trivial that should be fucking obvious. Ah, the ultimate concession of defeat, when you have no response. It only lacks calling me a "beginner programmer" or something. |
| boltar@nowhere.co.uk: Jul 09 05:33PM On Thu, 9 Jul 2020 11:41:25 +0200 >> Yes, we know how primitive Windows is in a number of respects. >Now the "primitive" way of doing this proves that the binary doesn't >have to contain all the info. Contrary to some claims. No, but Visual Shitshow has to generate a seperate file which you then have to remember to cart around if you wish to debug in situ. Just what you want when you're deploying to N machines. >And the code still works the same when the debug database is not present. Wow, amazing, truly tech from the future. |
| boltar@nowhere.co.uk: Jul 09 05:36PM On Thu, 9 Jul 2020 13:01:38 +0000 (UTC) >> tired of arguing with you over trivial that should be fucking obvious. >Ah, the ultimate concession of defeat, when you have no response. >It only lacks calling me a "beginner programmer" or something. If you don't understand what debuggers and class attribute and method names stored in binary files have to do with what I was talking about then either you're a troll or a complete moron. Take your pick. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 09 06:48PM +0100 > If you don't understand what debuggers and class attribute and method names > stored in binary files have to do with what I was talking about then either > you're a troll or a complete moron. Take your pick. A binary executable does NOT contain any type information whatsoever: it merely contains data in the data segment and text in the text segment. A C++ program and a C program could produce exactly the same text segment(s) after compiling and linking completely different source code. You adding debug information to your argument is a just a case of you shifting the goalposts as you have lost the argument. /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," Byrne 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." |
| boltar@nowhere.co.uk: Jul 09 06:00PM On Thu, 9 Jul 2020 18:48:43 +0100 >> stored in binary files have to do with what I was talking about then either >> you're a troll or a complete moron. Take your pick. >A binary executable does NOT contain any type information whatsoever: it I didn't say type information, I said names. You might want to try learning to read. >You adding debug information to your argument is a just a case of you shifting >the goalposts as you have lost the argument. My argument is that class layouts are stored in some form in the binary. Is that true or false? If its false then explain how objects are created on the fly. Take your time. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 09 07:12PM +0100 > My argument is that class layouts are stored in some form in the binary. Is > that true or false? If its false then explain how objects are created on the > fly. Take your time. A class layout would be akin to meta data which would be akin to type information and as I have already indicated text segments contain no type information WHATSOEVER. Now you have to use your brain and workout what really constitutes an object in a running program. Take all the time you need. /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," Byrne 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." |
| boltar@nowhere.co.uk: Jul 09 06:38PM On Thu, 9 Jul 2020 19:12:32 +0100 >information and as I have already indicated text segments contain no type >information WHATSOEVER. Now you have to use your brain and workout what really >constitutes an object in a running program. Take all the time you need. I noticed you didn't explain anything. Perhaps you don't know. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 09 07:44PM +0100 >> information WHATSOEVER. Now you have to use your brain and workout what really >> constitutes an object in a running program. Take all the time you need. > I noticed you didn't explain anything. Perhaps you don't know. It is obvious to all that you certainly don't know. Here is a clue to help you in your quest: The C++ Abstract Machine and the final running executable ARE NOT THE SAME THING. Good luck. /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," Byrne 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." |
| Juha Nieminen <nospam@thanks.invalid>: Jul 09 07:14PM > If you don't understand what debuggers and class attribute and method names > stored in binary files have to do with what I was talking about then either > you're a troll or a complete moron. Take your pick. I actually know exactly what you are doing, because I have seen it many, many times. I have frequenting usenet since the mid-90's, and believe me I have seen a lot during that time. What you are doing there is trying to hide your mistake by moving goalposts and sidetracking. You realized that your original statement about the necessity of storing information about the class structure was incorrect, so now to try to safe face and avoid having to admit having made an error, you invent a new goalpost and pretend that that was what you were talking about in the first place. In other words, you are just trying to dodge and obfuscate. And, obviously, you just throw names and insults on top of it, as if that made you sound smarter somehow. I have seen this kind of behavior many, many times over the past two and a half decades. This is nothing new. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 08 04:33PM -0700 On Thursday, 9 July 2020 01:59:20 UTC+3, Alf P. Steinbach wrote: > And again, that happens because an informal, practically oriented > standard is treated as a precise formal work, which it clearly isn't. Some of members of committee also seem to treat it not like specification of software development tool (C++ programming language) but like legislative document about said tool. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jul 08 04:39PM -0700 > No. UB is not solely a static property of a program. It's also a > dynamic property, such as exceeding a buffer size, or an > implementation limit. Who says the abstract machine specifies only static properties? [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 09 02:50AM +0200 On 09.07.2020 01:39, Keith Thompson wrote: >> dynamic property, such as exceeding a buffer size, or an >> implementation limit. > Who says the abstract machine specifies only static properties? No one so far. Tim Rentsch maintains that UB is determined solely by the specification. The specification is static. He does that in order to eliminate dynamic UB as a concept, by redefining the term. It's a common exercise by politicians seeking to influence the unthinking public. Not so common in technical debates. - Alf |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jul 08 06:17PM -0700 > No one so far. > Tim Rentsch maintains that UB is determined solely by the > specification. The specification is static. In what sense is it static? The specification (the language standard) describes dynamic (run-time) behavior. If your program does this (contrived example): int n = INT_MAX; n += rand() % 2; the second line may or may not have undefined behavior depending on the *dynamic* value returned by rand(). That can be inferred from the specification. > He does that in order to eliminate dynamic UB as a concept, by > redefining the term. It's a common exercise by politicians seeking to > influence the unthinking public. Not so common in technical debates. He didn't use the word "static". Why did you introduce it? [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 09 05:56AM +0200 On 09.07.2020 03:17, Keith Thompson wrote: >> specification. The specification is static. > In what sense is it static? The specification (the language standard) > describes dynamic (run-time) behavior. No, he's talking about the specification of a program, the source code. Unclear language is part & parcel of the "convince by redefining terms" approach. [snip] - Alf |
| Juha Nieminen <nospam@thanks.invalid>: Jul 09 07:20AM > are undesired), I'm very unhappy about the lunacy in the standard that > formally permits this last point, that the /compiler/ is permitted to > /introduce/ undefined behavior. Even if that's true, is there something in the C standard that explicitly forbids generating a recursive implementation from iterative code? |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 09 05:36AM -0700 > dynamically allocated memory acquires an effective type that is an array > type, technically the only position in that memory that you can create a > pointer to is the first one. This claim is nonsense. Effective type has consequences only for expressions that access an object, and pointer arithmetic never involves accessing any object. > because those three methods are explicitly described as giving an object > with no declared type an effective type that matches the effective type > of the object being copied (C2011 6.5p6). All this is irrelevant, because the rules for pointer arithmetic don't say anything about the type of the array being indexed. There is a requirement that the pointer or pointers involved point to (or one past) elements of an array /object/, but there is no mention of the type of said objects. > can, for the purposes of pointer arithmetic, be treated as if it were an > array of the pointed-at type - but there's nothing in either standard > that actually says so. Yes, there is, and has been since C90. Here for example is the first part of 7.20.3 p1 in N1256 The order and contiguity of storage allocated by successive calls to the calloc, malloc, and realloc functions is unspecified. The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated). [...] |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 09 07:59AM -0700 >> /introduce/ undefined behavior. > Even if that's true, is there something in the C standard that explicitly > forbids generating a recursive implementation from iterative code? There is nothing in the C standard that precludes a conforming implementation from using recursion to implement an iterative function, either explicitly or otherwise. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 09 05:47AM -0700 >> indicating a definition). >> An array type under the C definition has no padding. > That's not implied by your quote. As I read the C standard, it is. My reasoning is pretty much the same as that given by James Kuyper. > Which C standard is the quote from, anyway? C 2011, the same as what was mentioned in the normative reference. (I should add that technically my quote came from the pre-standard draft rather than the official standard, but I believe the wording is the same in both documents.) >> standard, it seems reasonable to conclude arrays in C++ cannot >> have padding. > Yes, but first one has to prove the C case. It has been established to my satisfaction. You are free to draw a different conclusion if that's what you would like to do. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 09 07:04AM -0700 > The C++ standard doesn't define that particular phrase, but it discusses > array types in 6.9.2 [basic.compound] and 11.3.4 [dcl.array] (references > are to C++17). I hadn't noticed the passage in 6.9.2; thank you for pointing it out. The references to array type in 11.3.4 are ones I had seen as part of my review prior to the earlier posting. These passages do refer to "array type"; I don't think either one is meant to define the term, only to refer to it. >> indicating a definition). > C++17 11.3.4: "An object of array type contains a contiguously > allocated non-empty set of N subobjects of type T." That sentence states a property of objects (of array type) but doesn't define the term "array type" itself. For that matter it isn't a definition of array-type objects either: it says they /contain/ "a contiguously allocated non-empty set of N subobjects" but doesn't say what else might be true (or not) about them. > The C++ standard includes (most of) the C library by reference, > but as I understand it it provides its own descriptions of > everything in the core language. The second paragraph of section 1 (intro.scope) says this: C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:2011 Programming languages -- C (hereinafter referred to as the C standard). In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces, operator overloading, function name overloading, references, free store management operators, and additional library facilities. > is defined directly by the C++ standard. If there are omissions, my > first assumption would be that they're unintentional, not that the C > core language definition fills in the gaps. That assumption may very well be right. I do think though that the existing wording can be read either way. The quoted 1 p2 does say "In addition to the facilities /provided/ by C" (my emphasis). If we can agree that either interpretation is at least plausible then I am happy to leave it at that. > It's not 100% clear to me that either the C or C++ discussion of array > types completely excludes the possibility of padding at the end. As far as C goes, I consider it a settled question. My reasoning is much the same as what James Kuyper said in his followups to Alf and Manfred: the definition of "array type" doesn't consider the possibility of anything other than a contiguously allocated set of objects, and other derived types that do admit padding all mention padding explicitly. Also, if it helps, I asked about this question many years ago in comp.lang.c (or maybe comp.std.c?). There was a response from Doug Gwyn, who said array types cannot have padding (or words to that effect). I'm sorry I can't be more specific; it was a long time ago, and the groups history seems to have fallen off the face of the earth. IIRC 'sizeof (T[N]) == N * sizeof (T)' was included in the subject line. If some ambitious web searcher is able to find something about those it would be nice to hear about it. |
| 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