| matth <matthewcoan1976@gmail.com>: Oct 10 05:17PM -0500 [BITS 32] [SEGMENT .text] global _alloca extern __chkstk _alloca: pop ecx pop eax ;sub esp,eax call __chkstk mov eax,esp sub esp,4 jmp ecx |
| "Öö Tiib" <ootiib@hot.ee>: Oct 09 05:27PM -0700 On Wednesday, 9 October 2019 22:48:42 UTC+3, Bonita Montero wrote: > > Technically compiler is permitted to crash or to hang on case of > > undefined behavior in code that it compiles. > There is no undefined behaviour with what I do. Such an assertion without minimal reproducible example provided (despite others asked for it) is clearly groundless. Also it is suspicious since on some other cases you have posted code quite happily. That makes it to seem from side that you already discovered yourself what you did wrong and now try to hide it with empty claims. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 08:05AM +0200 > It's fairly clear from your posting history that you're not a particularly good judge of that. I've shown you that my access ia non-odr-access. And there coudn't be any other code that changes this behaviour. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 08:07AM +0200 > code quite happily. That makes it to seem from side that you > already discovered yourself what you did wrong and now try to > hide it with empty claims. Other identical non-odr-accesses don't produce that result. And if I cast the non-odr-access which the compiler considers as an odr-access to its own type, the problem vanishes. So this is a compiler-bug. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 08:09AM +0200 > The compiler cannot know, a priori, that there is only one translation > unit. And for most real-world code, that's indeed the case. That doesn't matter if there is a definition or not. The static const integral declaration says the compiler what's the constant and if I have a non-odr-access to it the compiler is never allowed to change it into a odr-access. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 09 11:52PM -0700 On Thursday, 10 October 2019 09:07:35 UTC+3, Bonita Montero wrote: > And if I cast the non-odr-access which the compiler considers > as an odr-access to its own type, the problem vanishes. So > this is a compiler-bug. What is the space of those "other identical"? Removing other parts of program until nothing can be removed without the problem vanishing too is typical technique of manufacturing minimal reproducible examples. Is it now so that you can remove nothing from your whole program without it becoming such "other identical" that does not produce that result? You must see how that is unbelievable claim and how it makes the whole story doubtful. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 09:08AM +0200 > parts of program until nothing can be removed without the > problem vanishing too is typical technique of manufacturing > minimal reproducible examples. I don't heve to do that since I know where the poblem comes from. When I cast the static sonst uint32_t member to const uint32_t, thereby yielding a temporary, the problem vanishes. So I don't have to remove other code. But the thing is simply that even with the cast the type of access to FREE_NODE remains the same. And there is no logigal reason why other code could influence the type of access. |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 10 11:21AM +0300 On 10.10.2019 9:09, Bonita Montero wrote: > integral declaration says the compiler what's the constant and if I > have a non-odr-access to it the compiler is never allowed to change > it into a odr-access. That's why we are suspecting you have odr-access somewhere in your code, possibly in some other place or file. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 11:22AM +0200 > That's why we are suspecting you have odr-access somewhere in your code, > possibly in some other place or file. The access I "suspect" is the one the linker complains about because when I cast it to its own type, the problem vanishes. Also when I comment out this line. There are several semantically identic non -odr-accesses which the linker doesn't complain about. |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 10 12:41PM +0300 On 10.10.2019 12:22, Bonita Montero wrote: > when I cast it to its own type, the problem vanishes. Also when I > comment out this line. There are several semantically identic non > -odr-accesses which the linker doesn't complain about. This shows they are not identic. They might be in other translation units where the templates are instantiated for different types, for example. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 11:49AM +0200 > This shows they are not identic. They might be in other translation > units where the templates are instantiated for different types, for > example. They are identic. "The access is nd->pinCounter = FREE_NODE;". nd is always the same type (Node *), pinCounter is always a uint32_t and FREE_NODE is always the same static sonst uint32_t member. If they're in different translation units or not wouldn't matter (they're not) and the template-parameters are the same. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 10 06:22AM -0700 On Thursday, 10 October 2019 10:08:14 UTC+3, Bonita Montero wrote: > that even with the cast the type of access to FREE_NODE remains > the same. And there is no logigal reason why other code could > influence the type of access. Knowledge about from where problem comes is non-compatible with incapability of making minimal reproducible examples. So each detail you tell about it makes the the whole claim about issue to sound more and more doubtful. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 03:56PM +0200 > with incapability of making minimal reproducible examples. > So each detail you tell about it makes the the whole claim > about issue to sound more and more doubtful. I told everything to understand the issue. There's no logical reason why other code should change a non-odr-access into a odr-access. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 10 07:05AM -0700 On Thursday, 10 October 2019 16:56:35 UTC+3, Bonita Montero wrote: > I told everything to understand the issue. There's no logical > reason why other code should change a non-odr-access into a > odr-access. No. *You* have told these things that do not logically fit together with your behavior and being dodgy about producing minimal reproducible examples. So it sounds like you are lying at least about something and it can very well be that about everything. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 04:47PM +0200 > No. *You* have told these things that do not logically fit > together with your behavior and being dodgy about producing > minimal reproducible examples. ... So tell me why absolutely identical accesses to the static const integral don't induce a odr-access whereas the line I quoted does. There's no logical reason why other code could change that behaviour. And with the cast the problem vanished and this cast was only necessary in one place. |
| Mel <mel@zzzzz.com>: Oct 10 05:41PM +0200 On Wed, 9 Oct 2019 21:48:32 +0200, Bonita Montero > > Technically compiler is permitted to crash or to hang on case of > > undefined behavior in code that it compiles. > There is no undefined behaviour with what I do. There is no sense in what you do... -- Press any key to continue or any other to quit |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 05:44PM +0200 >> There is no undefined behaviour with what I do. > There is no sense in what you do... I'm taking the value of a static const integral member without taking its address or a reference on that. The behaviour of that is defined and there's no code that should affect that behaviour. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 10 08:55AM -0700 On Thursday, 10 October 2019 17:47:13 UTC+3, Bonita Montero wrote: > I quoted does. There's no logical reason why other code > could change that behaviour. And with the cast the problem > vanished and this cast was only necessary in one place. When I do not understand why particular change makes an issue that I can't reproduce not to manifest then I don't consider that change to be a fix at all but "voodoo wizardry". I will never do it nor accept it in code-review when done by others. You being evasive about figuring out the reason what is wrong with excuse that you have voodoo that fixes it therefore "knowledge" is even less understandable to me than outright lying about something of it. |
| scott@slp53.sl.home (Scott Lurndal): Oct 10 04:14PM >> > undefined behavior in code that it compiles. >> There is no undefined behaviour with what I do. >There is no sense in what you do... Don't feed the troll. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Oct 10 10:10PM > I'm taking the value of a static const integral member without > taking its address or a reference on that. The behaviour of that > is defined and there's no code that should affect that behaviour. How compiler can know that? Only way compiler can know that is to enforce rule that address can't be taken... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Melzzzzz <Melzzzzz@zzzzz.com>: Oct 10 10:11PM >>> There is no undefined behaviour with what I do. >>There is no sense in what you do... > Don't feed the troll. I think she thinks that she is genius ;) -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Juha Nieminen <nospam@thanks.invalid>: Oct 10 09:32AM > "back in the day" women would have been discouraged from STEM fields, but > even 40 years ago this was not the case and it is certainly not the > case now. It's especially ludicrous to claim that there's some kind of "conspiracy" to keep women out of STEM given the fact that in many universities (perhaps even the majority of them, especially in certain countries) female students in STEM fields have actually become the sizeable *majority*. I believe that in certain universities the numbers go as high as 60% or more. Yet, still, the number of women *working* in STEM fields remains the minority. Why is that? I think that the answer lies in the dropout rates in those universities in those STEM courses. The explanation is rather simple: When you induce people to take advanced courses that they aren't really interested in, they will get quickly disinterested and bored of it, and will start failing exams and dropping out. In many universities many STEM departments are suffering because of high dropout rates, which lowers their yearly budgets. And the reason is this massive campaign to get disinterested people into their courses. |
| 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