Tuesday, June 9, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 3 topics

Bonita Montero <Bonita.Montero@gmail.com>: Jun 09 01:16PM +0200

Am 09.06.2020 um 00:21 schrieb Öö Tiib:
> On Monday, 8 June 2020 21:56:52 UTC+3, Mr Flibble wrote:
>> Scott Newman <scott69@gmail.com>. Who the hell is this guy? Is he for real?
> Seems like younger sister of Bonita.
 
I forbid such insinuations.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 09 11:26AM -0700

On 6/9/2020 4:16 AM, Bonita Montero wrote:
>>> real?
>> Seems like younger sister of Bonita.
 
> I forbid such insinuations.
 
However, Scott seems to act in a eerily similar fashion. Fair enough?
The quoting wrt failing to add attributions and general insulting style
rings a bell?
Bonita Montero <Bonita.Montero@gmail.com>: Jun 09 08:33PM +0200


> However, Scott seems to act in a eerily similar fashion. Fair enough?
> The quoting wrt failing to add attributions and general insulting style
> rings a bell?
 
Sorry, but these are really superficial parallels.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 09 11:38AM -0700

On 6/9/2020 11:33 AM, Bonita Montero wrote:
>> The quoting wrt failing to add attributions and general insulting
>> style rings a bell?
 
> Sorry, but these are really superficial parallels.
 
Indeed. However, they are fairly similar nonetheless. Just enough to
make one ponder... ;^)
Scott Newman <scott69@gmail.com>: Jun 09 01:15PM +0200

> What I would do is search through the machine code for 'main' for the address of the member function and then remove any caching.
The machine-code won't hold the address but just an offset
into the vmt-table
Frederick Gotham <cauldwell.thomas@gmail.com>: Jun 09 04:22AM -0700

On Tuesday, June 9, 2020 at 12:15:37 PM UTC+1, Scott Newman wrote:
> > What I would do is search through the machine code for 'main' for the address of the member function and then remove any caching.
> The machine-code won't hold the address but just an offset
> into the vmt-table
 
Right, I'd need to look for the dereferencing of a pointer whose value is:
 
address_of_vtable <= pointer < (address_of_vtable + 8)
 
8 is just an arbitrary number.
Paavo Helde <eesnimi@osa.pri.ee>: Jun 09 02:30PM +0300

09.06.2020 14:07 David Brown kirjutas:
>>      }
 
> Why make that virtual?  To suit the requirements here, a non-virtual
> function would be fine.
 
OP wanted to modify the behavior of an existing virtual function. It is
not needed for this example indeed.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 09 01:26PM +0100


> Here, that's industrial-strength 100% portable code:
 
I get a segmentation fault (g++ 9.3.0, Linux).
 
<cut code>
--
Ben.
Scott Newman <scott69@gmail.com>: Jun 09 03:11PM +0200

>> Here, that's industrial-strength 100% portable code:
 
> I get a segmentation fault (g++ 9.3.0, Linux).
 
I don't believe you because I've got the same compiler-version and
it works.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 09 10:13AM -0400

On 6/9/20 12:11 AM, Paavo Helde wrote:
>> different vtable.
 
> In that case the objects would belong to different classes. And voila,
> static data members defined in different classes would be different as well!
 
Judging from his recent code sample, he is indeed talking about
effectively changing the class of an existing object by changing which
vtable it's vtable pointer points at. Static member functions would be
called based upon the declared type of the object, which would be the
original type.
 
>> It's the pointer, not the vtable, which is per-object.
 
> OP wanted to modify a slot in a vtable.
 
Which is a different kind of bad idea.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 09 10:21AM -0400

On 6/9/20 6:39 AM, Scott Newman wrote:
>>     cout << s->add(1, 2) << endl;
>> }
 
> That's code full of UB.
 
I'm not saying you're wrong about that - I haven't had time to look yet
- but it would help if you identified precisely which parts of that code
you think have undefined behavior, and why. I didn't notice anything
obvious, which would be odd if it were, as you claim, "full of UB".
However, I'm far more reliable when I say "I see a problem" than when I
say "I see no problems".
Scott Newman <scott69@gmail.com>: Jun 09 04:23PM +0200

> obvious, which would be odd if it were, as you claim, "full of UB".
> However, I'm far more reliable when I say "I see a problem" than when I
> say "I see no problems".
 
You shoudn't be a programmer.
Manfred <noname@add.invalid>: Jun 09 04:57PM +0200

On 6/8/2020 11:00 PM, Vir Campestris wrote:
> you have to understand what it's going to do on your architecture with
> your cache design and a bunch of other features, such as the NUMA
> architecture in place.
 
I'll admit that I am a bit rusty on the subject, it has been a long time
since my last interrupt handler, however:
 
Both the main program and the interrupt handler run at the CPU level, so
caching and friends are transparent to both (DMA would obviously be a
different matter, even if often used in combination with IRQs)
 
> platforms in that context. And it's all in the platform dependent code.
 
> Flibble is right here; volatile is not the right mechanism for passing
> data between threads; and in this context ISRs count as threads.
 
This is the more interesting part.
Strictly speaking, by definition and interrupt handler /interrupts/ the
current process and executes while such process is on hold. In other
words, the ISR is not allocated on a separate thread, it uses the time
slot of the current process.
 
If you are programming an interrupt handler yourself, chances are you
are working on some small CPU without multitasking capabilities (or your
time zone is in the '80s and you are programming under MS-DOS). In this
scenario the current process is the /only/ process being executed, so
there is no thread concurrency with the ISR, and 'volatile' is the right
tool for the job.
 
More to the point, the OP referred to a physical signal that "will cause
an interrupt to fire and so the main program will be frozen"; this
suggests such a single-task scenario.
 
However, if you are using multitasking (multi core) CPU(s) as nowadays
common, the "main" process is not likely to be the "current" process,
and then you are right in the sense that synchronization against thread
concurrency is generally required; std::atomic will give you both
synchronized and volatile access (volatile in the sense that the mov
instruction will not be reordered)
 
However still, it is common that the main program (or rather the second
level interrupt handler) does not freely access data shared with the ISR
(or the first level handler), but manipulates such data as a response to
a trigger received by the ISR instead. In this scenario, the full
picture may include other synchronization means that may render
std::atomic on the single variable redundant.
 
 
> std::atomic is designed for that, and will do the right thing in a
> portable manner.
 
> volatile is largely obsolete.
 
Am I wrong?
 
David Brown <david.brown@hesbynett.no>: Jun 09 05:32PM +0200

On 09/06/2020 16:21, James Kuyper wrote:
> obvious, which would be odd if it were, as you claim, "full of UB".
> However, I'm far more reliable when I say "I see a problem" than when I
> say "I see no problems".
 
The guy is trolling - he is just making bogus statements and bad advice
to annoy people. All we can sensibly do is make it clear to innocent
bystanders (like the OP) that his suggestions are terrible ideas and are
not "industrial strength" or "100% portable". It is pointless asking
him for an explanation here.
 
(If it helps, I can't see any UB here either. Scott's code was full of
obvious UB, as expected.)
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 09 04:41PM +0100


>> I get a segmentation fault (g++ 9.3.0, Linux).
 
> I don't believe you because I've got the same compiler-version and
> it works.
 
Probably a compiler option. The sanitzer maybe?
 
g++ -std=c++17 -pedantic -fno-common -fno-diagnostics-show-option \
-fsanitize=undefined -Wall -Wextra -Wformat-nonliteral -Wcast-align \
-Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store -o vtab \
vtab.cc
 
I'd say that industrial strength 100% portable code should work with
-fsanitize=undefined but I am sure opinions vary on that. (Of course it
may be a bug in the sanitizer, but I don't think so.)
 
--
Ben.
Scott Newman <scott69@gmail.com>: Jun 09 05:44PM +0200

> -fsanitize=undefined -Wall -Wextra -Wformat-nonliteral -Wcast-align \
> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store -o vtab \
> vtab.cc
 
Your additional warnings are for idiots.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 09 11:48AM -0400

On 6/9/20 4:21 AM, Scott Newman wrote:
> Here, that's industrial-strength 100% portable code:
...
> {
> // volatile to prevent any caching> virtual int CC add( int a, int b );
> };
...
> void inject( S *s )
> {
...
 
Scott - don't bother reading any further - just go ahead and insult my
intelligence, as is your wont. The following comments are only intended
for the benefit of people who are interested in what the standard
actually says, and you've made it abundantly clear that you aren't one
of those people.
 
The key problem with your code is right here:
 
> *(void **)s = vtable;
 
Conversion from "S *" to "void**" is permitted only if *s is
pointer-inter-convertible with some object of type void*. (8.2.9p13)
 
"Two objects a and b are pointer-interconvertible if:
(4.1) — they are the same object, or
(4.2) — one is a standard-layout union object and the other is a
non-static data member of that object (12.3),
or
(4.3) — one is a standard-layout class object and the other is the first
non-static data member of that object,
or, if the object has no non-static data members, the first base class
subobject of that object (12.2), or
(4.4) — there exists an object c such that a and c are
pointer-interconvertible, and c and b are pointer-
interconvertible." (6.9.2p4)
 
Paragraph 4.1 doesn't apply because *s and the vtable pointer are not
the same object.
S has a virtual member function, it is therefore not a standard-layout
class (12p7.2), so neither 4.2 nor 4.3 can apply.
Additionally, 4.2 doesn't apply because neither S nor the vtable pointer
is a union object, and 4.3 doesn't apply because S doesn't have any
non-static data members.
In any context where 4.3 did apply, that conversion would produce a
pointer pointing at the first non-static data member of the struct,
which is not a vtable pointer.
4.4 doesn't apply because there isn't any other object c that you could
use for the intermediate step in the logic chain - all of the reasons I
gave why 4.1 through 4.3 don't apply for the vtable pointer are equally
valid for any other objects that you could nominate to serve the role of
'c' in paragraph 4.4.
 
...
> S *volatile s2 = s;
The key consequence of using the volatile key word is that "Accesses
through volatile glvalues are evaluated strictly according to the rules
of the abstract machine." (4.6p7.1). In other words, it disables
optimizations - but not all such optimizations, only the ones involving
short-cuts around the rules of the abstract machine.
 
The standard doesn't say anything anywhere about vtable pointers
themselves - it only describes the polymorphic behavior that an
implementation is required to support. vtable pointers are just a detail
in how those requirements are implemented. What you're trying to do
would make it violate those requirements. An implementation is under no
obligation to make it easy, or even possible, for you to do what you
want to do.
 
Therefore, declaring it volatile does not protect your code from
optimizations based upon the assumption that the vtable pointer has not
been modified. An implementation is always allowed to make that
assumption, regardless of whether or not you use "volatile".
Scott Newman <scott69@gmail.com>: Jun 09 05:52PM +0200

> I'd say that industrial strength 100% portable code should work with
> -fsanitize=undefined but I am sure opinions vary on that. (Of course it
> may be a bug in the sanitizer, but I don't think so.)
 
My code is optimized for performance. So compile it with -O3.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 09 11:59AM -0400

On 6/8/20 5:35 PM, Scott Newman wrote:
>> the end of the object.[3]"
 
> That's not possible because the object's derived classes are growing
> at the end. So this is nonsense.
 
Why should that matter? As it says in the part I quoted, which you
dropped, this was only done for classes with no polymorphic base
classes. If Base is such a class, and Derived is a class derived from
Base, then it would be done for Base, but not for Derived. The layout
for an object of class Derived was therefore something like:
 
1. Base non-static data members
2. vtable pointer
3. Derived non-static data members
 
In other words, for any object type Base or of a class derived from
Base, the vtable pointer could be found at a fixed offset known to the
compiler from the start of the object, immediately after the Base
sub-object.
 
There are reasons why they changed this, but infeasibility wasn't one of
them.
Scott Newman <scott69@gmail.com>: Jun 09 06:38PM +0200

> ... and memory leaks. ...
That's not a memory-leak. There's a new programming-stlye
where memory that isn't used anymore isn't freed but swapped
out. That's faster since deallocation is synchronous whereas
swapping out is asynchronous.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 09 06:41PM +0100

On 09/06/2020 11:53, Scott Newman wrote:
 
> It specified in the compiler documentation.
> And it is usually not like in Java.
> For the purpose of what I said it is as good as a atomic<bool>.
 
EVERYTHING YOU SAY IS WRONG.
 
/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."
Scott Newman <scott69@gmail.com>: Jun 09 08:17PM +0200

>> And it is usually not like in Java.
>> For the purpose of what I said it is as good as a atomic<bool>.
 
> EVERYTHING YOU SAY IS WRONG.
 
That's what I already know from you - _just_because_you_say_it_.
But a volatile bool is as suitable a a stop-flag for a thread
as an atomic<bool>.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 09 07:19PM +0100

On 09/06/2020 19:17, Scott Newman wrote:
 
> That's what I already know from you - _just_because_you_say_it_.
> But a volatile bool is as suitable a a stop-flag for a thread
> as an atomic<bool>.
 
EVERYTHING YOU SAY IS WRONG.
 
/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."
Scott Newman <scott69@gmail.com>: Jun 09 08:20PM +0200

>> But a volatile bool is as suitable a a stop-flag for a thread
>> as an atomic<bool>.
 
> EVERYTHING YOU SAY IS WRONG.
 
Wrong.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 09 06:29PM +0100


> The findings are becoming more and more frequent. The myth of millions
> of years is not holding up to field research and paleontological
> findings.
 
MUMMIFICATION *BEFORE* FOSSILISATION. LEARN TO FUCKING READ THEN LEARN FUCKING SCIENCE.
 
NOW FUCK OFF.
 
/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."
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)