| --- Log opened Fri Feb 03 00:00:27 2017 |
| 00:21 | | crystalclaw_ [crystalclaw@Nightstar-12q9ui.xyz] has quit [Ping timeout: 121 seconds] |
| 00:29 | | crystalclaw [crystalclaw@Nightstar-12q9ui.xyz] has joined #code |
| 00:29 | | mode/#code [+o crystalclaw] by ChanServ |
| 00:32 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 00:35 | | catalyst is now known as LadyOfLight |
| 01:01 | | Derakon_ is now known as Derakon |
| 01:01 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 01:05 | | gnolam [quassel@Nightstar-orl01s.cust.bahnhof.se] has quit [[NS] Quit: Z?] |
| 01:14 | | LadyOfLight [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has quit [Connection reset by peer] |
| 01:19 | | LadyOfLight [catalyst@Nightstar-pgi.jtr.132.82.IP] has joined #code |
| 04:40 | | LadyOfLight` [catalyst@Nightstar-85rfu3.dab.02.net] has joined #code |
| 04:42 | | LadyOfLight [catalyst@Nightstar-pgi.jtr.132.82.IP] has quit [Ping timeout: 121 seconds] |
| 05:07 | | Derakon is now known as Derakon[AFK] |
| 06:13 | | LadyOfLight` is now known as LadyOfLight |
| 06:21 | | himi [sjjf@Nightstar-dm0.2ni.203.150.IP] has quit [Connection closed] |
| 06:32 | | celticminstrel is now known as celmin|sleep |
| 07:21 | | Kindamoody[zZz] is now known as Kindamoody |
| --- Log opened Fri Feb 03 08:11:39 2017 |
| 08:11 | | TheWatcher [chris@GlobalOperator.Nightstar.Net] has joined #code |
| 08:11 | | Irssi: #code: Total of 30 nicks [28 ops, 0 halfops, 0 voices, 2 normal] |
| 08:11 | | mode/#code [+o TheWatcher] by ChanServ |
| 08:11 | | Reiver [quassel@Nightstar-ksqup0.co.uk] has joined #code |
| 08:11 | | mode/#code [+ao Reiver Reiver] by ChanServ |
| 08:12 | | Irssi: Join to #code was synced in 56 secs |
| 08:17 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has joined #code |
| 08:18 | | mode/#code [+o himi] by ChanServ |
| 09:00 | | Kindamoody is now known as Kindamoody|afk |
| 09:05 | | macdjord|wurk is now known as macdjord|slep |
| 09:14 | | LadyOfLight [catalyst@Nightstar-85rfu3.dab.02.net] has quit [The TLS connection was non-properly terminated.] |
| 09:14 | | LadyOfLight [catalyst@Nightstar-85rfu3.dab.02.net] has joined #code |
| 11:09 | | LadyOfLight` [catalyst@Nightstar-ee7.jtr.132.82.IP] has joined #code |
| 11:12 | | LadyOfLight [catalyst@Nightstar-85rfu3.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 11:30 | | LadyOfLight` is now known as LadyOfLight |
| 15:42 | <@TheWatcher> | OH HAY |
| 15:43 | <@TheWatcher> | It'd be terrible if a major social media platform had a bunch of completely undocumented parameters for parts of its API, wouldn't it? |
| 15:43 | <@TheWatcher> | Good thing that places like twitter don't do that. |
| 15:46 | < LadyOfLight> | Aye |
| 15:59 | < LadyOfLight> | Fucking programmes |
| 15:59 | < LadyOfLight> | Programmers* |
| 16:18 | <@celmin|sleep> | Oh? |
| 16:18 | | celmin|sleep is now known as celticminstrel |
| 17:07 | <&ToxicFrog> | Hmm. So here's a C++ question. |
| 17:07 | <&ToxicFrog> | I have the following: |
| 17:07 | <&ToxicFrog> | struct Foo { int x; int* x_ptr; }; |
| 17:08 | <&ToxicFrog> | Foo mkFoo() { Foo foo; foo.x = 1; foo.x_ptr = &foo.x; return foo; } |
| 17:08 | <&ToxicFrog> | int main() { Foo foo = mkFoo(); std::cout << *foo.x_ptr; return 0; } |
| 17:09 | <&ToxicFrog> | Is it possible that mkFoo allocates a Foo on the stack, the contents of which are then copied into the caller's Foo, discarding the original and making foo.x_ptr invalid? |
| 17:09 | <&ToxicFrog> | Because I have this code in a unit test here, and it works, but I don't know if it's guaranteed to work. |
| 17:11 | <@celticminstrel> | It does look like x_ptr would be invalid after returning. |
| 17:12 | <&ToxicFrog> | But it clearly is not, even in situations where mkFoo()'s stack frame is not only discarded but known to be overwritten. |
| 17:12 | <&ToxicFrog> | (and it doesn't intuitively look like it has to be to me, but I'm also not terribly comfortable with C++) |
| 17:17 | <&ToxicFrog> | Ok, it looks like the term I wanted to look for was "return value optimization" |
| 17:17 | <&ToxicFrog> | And it is allowed, but not required |
| 17:17 | <&ToxicFrog> | It is even allowed in places where it would change the functional behaviour of the program what the goatshitting fuck |
| 17:28 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 17:28 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 17:40 | | LadyOfLight` [catalyst@Nightstar-bf54ag.dab.02.net] has joined #code |
| 17:43 | | LadyOfLight [catalyst@Nightstar-ee7.jtr.132.82.IP] has quit [Ping timeout: 121 seconds] |
| 18:08 | | LadyOfLight` is now known as LadyOfLight |
| 18:27 | | LadyOfLight [catalyst@Nightstar-bf54ag.dab.02.net] has quit [The TLS connection was non-properly terminated.] |
| 18:27 | | LadyOfLight [catalyst@Nightstar-bf54ag.dab.02.net] has joined #code |
| 18:34 | | LadyOfLight` [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 18:52 | | LadyOfLight [catalyst@Nightstar-bf54ag.dab.02.net] has quit [[NS] Quit: Bye] |
| 18:59 | | LadyOfLight` is now known as LadyOfLight |
| 19:15 | <@celticminstrel> | ...what. |
| 19:17 | | gnolam [lenin@Nightstar-t1tbf0.cust.bahnhof.se] has joined #code |
| 19:17 | | mode/#code [+o gnolam] by ChanServ |
| 19:19 | | * Vornicus gives cslmin a cheese |
| 20:25 | | crystalclaw [crystalclaw@Nightstar-12q9ui.xyz] has quit [Ping timeout: 121 seconds] |
| 20:35 | | crystalclaw [crystalclaw@Nightstar-12q9ui.xyz] has joined #code |
| 20:35 | | mode/#code [+o crystalclaw] by ChanServ |
| 21:48 | <@gnolam> | "The 'S' in 'IoT' stands for 'Security'." |
| 21:48 | <&McMartin> | legit |
| 21:48 | <@Tamber> | "But there is no 'S' in... ...oh." |
| 21:49 | <&McMartin> | 09:17 <&ToxicFrog> It is even allowed in places where it would change the functional behaviour of the program what the goatshitting fuck |
| 21:50 | <&McMartin> | If you intended the code you wrote to actually be safe, you would write a copy constructor to ensure a deep copy, basically |
| 21:50 | <&McMartin> | This kind of thing is what convinced me that Rust is a sensible attack even if mortals cannot write it |
| 21:51 | <&McMartin> | Because C++ basically has all the same issues but no static safety net. |
| 21:51 | <&McMartin> | LoL will be able to correct me if I'm wrong on this... |
| 21:52 | <&McMartin> | ... but I get the impression that certain optimizations, of which the return value optimization is one (and the base class optimization is another, which is the one that has been burning *me*) are acknowledged by the standard in ways that mean certain things that look reasonable are secretly undefined behavior thanks to said optimizations |
| 21:54 | <&McMartin> | TL;DR: Please do not write functions like mkFoo |
| 21:56 | <&ToxicFrog> | What's the base class optimization? |
| 21:56 | <&McMartin> | It has something to do with how objects with inheritance are represented at the binary level |
| 21:57 | <&ToxicFrog> | Also, in C++17 RVO is mandatory wherever it is possible, so that construct will in fact be safe per the standard |
| 21:57 | <&McMartin> | And in particular, its presence or absence means that offsetof() may or may not be compile-time deducible. |
| 21:57 | <&ToxicFrog> | (it is also, in practice, safe in the compiler we use at work, which will always RVO when it can, but if you're using C++ pre '17 it is not guaranteed to be safe) |
| 21:58 | <&McMartin> | There is a template macro named std::is_standard_layout to check whether or not offsetof makes any sense |
| 21:58 | <&McMartin> | I'm a *little* bit unclear as to what the optimization actually *is* |
| 21:58 | <&McMartin> | I think I may be doing it "by accident" in my single-inheritance OO scheme on Bumbershoot |
| 21:59 | <&McMartin> | But I think the reason offsetof may *not* be compile-time comprehensible is because casting a pointer in C++ is permitted to alter its bit pattern |
| 21:59 | <&McMartin> | And this is, AIUI, the standard way multiple inheritance is done |
| 21:59 | <&McMartin> | (That is, objects with multiple inheritance pack multiple vtables, so the pointer is shifted to point at the vtable your cast has indicated you care about) |
| 21:59 | <&ToxicFrog> | (after a bunch of running around at work we concluded "it's safe in our compiler, it's safe in C++17, and it's not in production code, so it's not worth fixing, but the fact that we even had to ask this question is disheartening") |
| 22:01 | <&McMartin> | (It has not escaped my notice that the C++ style guidelines for Google can be succinctly summarized as "please pretend you are writing Java as far as practicable, for God's sake, except for the parts where we'd prefer you pretend you were writing C") |
| 22:01 | <&McMartin> | (It turns out that "pretend you are writing C" neatly solves my is_standard_layout woes, too) |
| 22:05 | | celticminstrel [celticminst@Nightstar-h4m24u.dsl.bell.ca] has quit [Connection reset by peer] |
| 22:06 | | celticminstrel [celticminst@Nightstar-h4m24u.dsl.bell.ca] has joined #code |
| 22:06 | | mode/#code [+o celticminstrel] by ChanServ |
| 22:47 | < LadyOfLight> | Every instance of an allocation in C++ is guaranteed to have a unique memory location. This means that every class must be at least sizeof(char) in size, even if it contains no members. The empty base class optimization is an acknowledgement of the fact that is is valid for something like struct A{}; struct B : A {}; to yield sizeof(A) == 1 and sizeof(B) == 1. |
| 22:48 | < LadyOfLight> | I am confused why this leads to undefined behaviour |
| 22:48 | < LadyOfLight> | McMartin |
| 22:50 | < LadyOfLight> | Also, the RVO is an acknowledgement that you are allowed to elide the copy of a temporary being returned from a function, since you can construct it in place in its return location |
| 22:51 | < LadyOfLight> | Again, I am confused by the idea that this commonly leads to undefined behaviour |
| 22:53 | < LadyOfLight> | I suppose if you're attempting things like reflective behaviour, then this might bite you |
| 22:56 | < LadyOfLight> | I am, however, basically asleep |
| 22:56 | <&[R]> | This means that every class must be at least sizeof(char) in size <-- sizeof(char) or sizeof(uintptr_t)? |
| 22:57 | | * ToxicFrog hugsquishes LadyOfLight |
| 22:58 | < LadyOfLight> | In practise, your heap is likely to enforce an alignment, most likely 16-byte aligned. |
| 22:58 | < LadyOfLight> | But if you allocate multiple (via an array or container or whatnot), they will not be |
| 22:59 | < LadyOfLight> | I would imagine |
| 22:59 | < LadyOfLight> | In practise there is nothing in the standard which mandates a minimum alignment or padding |
| 22:59 | < LadyOfLight> | (I know. I looked.) |
| 23:00 | < LadyOfLight> | sizeof(char) is the minimum size of a uniquely addressable item, though |
| 23:00 | | * LadyOfLight hugs ToxicFrog |
| 23:01 | < LadyOfLight> | I also am so tired that I am unable to check that for sanity, but it feels correct |
| 23:02 | < LadyOfLight> | char arr[10]; char* x = &arr; ++x; // x now points at arr[1]. |
| 23:02 | < LadyOfLight> | yeah |
| 23:02 | < LadyOfLight> | well |
| 23:02 | < LadyOfLight> | no |
| 23:02 | < LadyOfLight> | char* x = arr; |
| 23:02 | < LadyOfLight> | then that works, I think |
| 23:02 | < LadyOfLight> | I err, hope I'm not making a complete fool of myself |
| 23:03 | <&[R]> | Seems sane |
| 23:20 | | celticminstrel [celticminst@Nightstar-h4m24u.dsl.bell.ca] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 23:20 | | celticminstrel [celticminst@Nightstar-h4m24u.dsl.bell.ca] has joined #code |
| 23:20 | | mode/#code [+o celticminstrel] by ChanServ |
| 23:21 | <&McMartin> | LadyOfLight: So, this is C++11, not 17, and I think this was altered slightly |
| 23:22 | <&McMartin> | In C++11, if any of your parent classes are nonempty than you are not standard layout and offsetof() is formally undefined behavior |
| 23:22 | <&McMartin> | IIRC, in C++13 and later it's "if more than one class in the inheritance tree defines fields then you are not standard layout" |
| 23:24 | < LadyOfLight> | plausible |
| 23:25 | < LadyOfLight> | In theory code I have written ought to be dependent on that sort of layout nonsense, but in practise those classes do not have vtables |
| 23:25 | <&McMartin> | C++14, not C++11 |
| 23:26 | | * McMartin checks his summary pages |
| 23:26 | <&McMartin> | Aha, OK |
| 23:26 | <&McMartin> | C++11 furthermore requires that you have no base classes of the same type as the first non-static data member |
| 23:27 | <&McMartin> | Which is to say, it requires that the empty base optimization must not be possible |
| 23:27 | < LadyOfLight> | Hm |
| 23:27 | < LadyOfLight> | for offsetof to work, you mean? |
| 23:27 | <&McMartin> | (I'm going from http://en.cppreference.com/w/cpp/concept/StandardLayoutType which I realize is guttersnipe gossip for you) |
| 23:27 | <&McMartin> | Yeah |
| 23:27 | < LadyOfLight> | I know a lot, but often I know where to look rather than specifics |
| 23:28 | < LadyOfLight> | cppreference.com is actually very good for this sort of thing |
| 23:28 | <&ToxicFrog> | knowing where to look is just as good! |
| 23:28 | < LadyOfLight> | Like, I enjoy being hyped as a know-all wizard, but I do get things wrong :) |
| 23:28 | <&McMartin> | TF: Right, but my answer is usually "cppreference.com" and hers is "the standards documents" |
| 23:29 | <&McMartin> | That's why I'm classifying my sources as "gossip" :) |
| 23:29 | <&ToxicFrog> | I got a lot of praise in grad school for "encyclopedic knowledge" of the platform when it was actually just that I was really fast at looking things up in the reference manual on my laptop~ |
| 23:29 | < LadyOfLight> | I guess in practise StandardLayoutType means 'like wot C does' |
| 23:29 | <&McMartin> | Yeah |
| 23:29 | <&McMartin> | And in particular it means that reinterpret_cast<> and offsetof will have predictable effects and are suitable for FFI |
| 23:30 | | * LadyOfLight nods |
| 23:30 | <&McMartin> | (The code I was working with where this was relevant was a procedural deserializer) |
| 23:30 | < LadyOfLight> | fun fact: still doesn't mandate that there is minimal padding nor alighment |
| 23:30 | < LadyOfLight> | alignment* |
| 23:30 | <&McMartin> | Yup |
| 23:30 | <&McMartin> | "like wot C does" turns out to be terrifyingly broad still, but it's got a handful of useful guarantees |
| 23:31 | < LadyOfLight> | the only thing the standard mandates of layout of members is that members at the same access level are at monotonically increasing addresses |
| 23:32 | < LadyOfLight> | at least, as of C++11 |
| 23:32 | < LadyOfLight> | and possibly 14 |
| 23:32 | <&McMartin> | Standard layout seems to also require consistency of shared prefixes, with C++14 adding the requirement that you get to ignore const/volatile while so doing |
| 23:32 | < LadyOfLight> | That makes some sense |
| 23:32 | <&McMartin> | "offset consistency of shared prefixes" being precisely the "like wot C does" thing that makes stuff make sense |
| 23:33 | <&McMartin> | (And the property I exploit to Hell and gone in https://bumbershootsoft.wordpress.com/2016/06/20/object-oriented-programming-at- the-bare-metal/ ) |
| 23:57 | | LadyOfLight [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has quit [Connection reset by peer] |
| --- Log closed Sat Feb 04 00:00:32 2017 |