Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 419 420 421 422 423 424 425 426 427 428 429 .. 5022
— 502,152 events total
2020-10-05 03:36:03 <SirClueless> When you write a load from a memory address provided by an IO device's driver with a volatile keyword qualifier, the standard defines what kinds of bytes you will and will not access, and the ordering of that load with respect to the other statements in your program. In that sense the standard defines reading a DMA buffer.
2020-10-05 03:36:42 <c_wraith> The standard tells you that you can read from a pointer. It doesn't say anything about DMA
2020-10-05 03:36:47 × constR quits (uid58205@gateway/web/irccloud.com/x-tksgpowcrsjwxjgo) (Quit: Connection closed for inactivity)
2020-10-05 03:37:14 <c_wraith> (of course, you can only read from *some* pointers. It's not clear how the driver generates that pointer and whether it's valid according to the spec)
2020-10-05 03:38:59 <SirClueless> It tells you it will read exactly once and with well-defined ordering with respect to reading any other volatile memory addresses. That's enough to implement interoperating with a DMA buffer.
2020-10-05 03:39:58 <c_wraith> You seem to have ignored the provenance of the pointer. the standard says a lot about when reading from a pointer is defined and when it isn't. I sincerely doubt that the way the pointer is acquired is standard-compliant.
2020-10-05 03:40:17 <c_wraith> (The OS may guarantee it's fine, but that's not the same as the spec)
2020-10-05 03:40:27 <koz_> I'm also unsure that you get a well-defined ordering across multiple volatile variables this way.
2020-10-05 03:40:40 <koz_> (I'm open to being proved wrong here, but I don't think the standard goes quite that far)
2020-10-05 03:40:43 <koz_> (at least not in C)
2020-10-05 03:41:16 <SirClueless> I'm not sure I follow. If it's implementation-defined by the standard, and the OS guarantees certain behavior, then it's well-defined access.
2020-10-05 03:41:54 <koz_> SirClueless: 'Implementation-defined' translates to 'read your compiler docs'.
2020-10-05 03:42:02 <dolio> You mean like how the Haskell specification has implementation defined behavior, so you need to ask about the implementation you're using?
2020-10-05 03:42:03 <koz_> The OS's guarantees may or may not matter.
2020-10-05 03:42:23 <SirClueless> And it does provide some number of guarantees of ordering. Basically using the concept of "sequence points" as defined in the C abstract machine and the ability (or inability) of a compliant implementation to reorder certain loads and stores over sequence points.
2020-10-05 03:42:25 × blasius quits (~blasius@4e69b241.skybroadband.com) (Ping timeout: 240 seconds)
2020-10-05 03:42:56 <koz_> SirClueless: So I guess we're talking C11, since before that, there's no memory model.
2020-10-05 03:44:53 <SirClueless> Well, technically even before that there were guarantees about some kinds of ordering. And compilers would in practice make guarantees like "we won't reorder around inline assembly" giving you a non-portable backdoor into your ISA's memory barrier instructions to try and do the right thing (inasmuch as that was possible).
2020-10-05 03:44:57 <koz_> "What constitutes an access to an object thathas volatile-qualified type is implementation-defined." bodes well...
2020-10-05 03:46:01 <SirClueless> Yeah, it was a crappy landscape for a long time. Recently things have gotten better (in C++ especially) with various flavors of standard-defined atomic data types.
2020-10-05 03:46:08 × vicfred quits (~vicfred@unaffiliated/vicfred) (Quit: Leaving)
2020-10-05 03:46:37 × kupi quits (uid212005@gateway/web/irccloud.com/x-dndtziltoquslpzk) (Quit: Connection closed for inactivity)
2020-10-05 03:48:23 × kreyren_ quits (~kreyren@fsf/member/kreyren) (Ping timeout: 240 seconds)
2020-10-05 03:49:35 × miguicho quits (~miguel@host-186-101-215-54.netlife.ec) (Quit: Leaving)
2020-10-05 03:50:57 × falafel quits (~falafel@2605:e000:1527:d491:706d:90a5:67aa:1cd9) (Ping timeout: 272 seconds)
2020-10-05 03:52:02 <SirClueless> Anyways, I think it's interesting to discuss these things. Thanks for taking the time to go back and forth with me! I think there are a lot of interesting tradeoffs to make: In C you can write a type-checking program that blows up because you wrote a[n] for too large n. In Haskell you can write a type-checking program that blows up because you
2020-10-05 03:52:02 <SirClueless> wrote `rfold` when you meant `lfold`. Ain't software fun.
2020-10-05 03:52:54 × wei2912 quits (~wei2912@unaffiliated/wei2912) (Quit: Lost terminal)
2020-10-05 03:53:06 <koz_> SirClueless: Those are different notions of 'blowing up' though.
2020-10-05 03:53:15 <koz_> Former is 'the compiler can emit code that erases your hard drive'.
2020-10-05 03:53:18 × conal quits (~conal@209.58.132.107) (Quit: Computer has gone to sleep.)
2020-10-05 03:53:24 <koz_> Latter is 'if you don't have hilarious RAM you'll OOM'.
2020-10-05 03:53:34 <koz_> Those aren't even in the same _universe_.
2020-10-05 03:56:16 <SirClueless> That's where we disagree at a philosophical level, I suppose. Both of them could equally bring down a server.
2020-10-05 03:57:41 <koz_> ... you're seriously saying that 'your server now lost all its data forever' is in the same ballpark as 'one program on said server crashed to OOM'?
2020-10-05 03:58:24 <SirClueless> There are some differences to be sure: the former is much more likely than the latter to end in an attacker having control of your network. But both are stop-the-world disasters in the right context.
2020-10-05 03:58:45 <koz_> 'In the right context' almost anything is anything.
2020-10-05 03:59:05 <koz_> I'd say, in general, UB creates issues of far worse gore than laziness will ever afflict you with.
2020-10-05 03:59:14 <SirClueless> Sure, the context for me is writing high-availability network services.
2020-10-05 03:59:46 <koz_> It sure is great for availability when you've had your entire non-volatile storage nuked.
2020-10-05 03:59:50 <koz_> Or your passwords dumped.
2020-10-05 04:00:28 × ryansmccoy quits (~ryansmcco@193.37.254.27) (Ping timeout: 265 seconds)
2020-10-05 04:00:32 <SirClueless> Yeah, that's a memory-safety problem. Utterly terrifying for C programs, a non-issue for Haskell programs.
2020-10-05 04:00:42 <SirClueless> But DoS vectors are problems for both.
2020-10-05 04:00:47 → drbean joins (~drbean@TC210-63-209-50.static.apol.com.tw)
2020-10-05 04:01:17 → ryansmccoy joins (~ryansmcco@156.96.151.132)
2020-10-05 04:02:15 → conal joins (~conal@209.58.132.107)
2020-10-05 04:02:25 × polyphem quits (~p0lyph3m@2a02:810d:640:776c:76d7:55f6:f85b:c889) (Ping timeout: 240 seconds)
2020-10-05 04:02:26 × xelxebar quits (~xelxebar@gateway/tor-sasl/xelxebar) (Remote host closed the connection)
2020-10-05 04:02:30 <koz_> Denial-of-service can also be done by attacking the hosting architecture, irrespective of what you wrote in or with.
2020-10-05 04:02:46 <koz_> (in fact, I believe that's where it commonly arises, unless we're talking like, hash flooding or something)
2020-10-05 04:02:55 → xelxebar joins (~xelxebar@gateway/tor-sasl/xelxebar)
2020-10-05 04:02:57 → zacts joins (~zacts@dragora/developer/zacts)
2020-10-05 04:04:53 → vicfred joins (~vicfred@unaffiliated/vicfred)
2020-10-05 04:05:53 × vicfred quits (~vicfred@unaffiliated/vicfred) (Max SendQ exceeded)
2020-10-05 04:06:22 → vicfred joins (~vicfred@unaffiliated/vicfred)
2020-10-05 04:07:39 → falafel joins (~falafel@2605:e000:1527:d491:706d:90a5:67aa:1cd9)
2020-10-05 04:07:49 <SirClueless> The malicious kinds, yeah, probably. The kinds that are more like "2% of our RPC calls timeout because the host dies" and you go and investigate the machines where it happens and it turns out there's a legitimate use case for requesting 10000 records at a time from your service and somewhere in the network stack someone wrote an O(n^2) linear scan
2020-10-05 04:07:49 <SirClueless> routine that they never expected to be exercised like this and now needs to be rearchitected
2020-10-05 04:09:10 <koz_> But this isn't really unique to Haskell. No language will prevent you writing a quadratic scan.
2020-10-05 04:09:18 <koz_> I don't think laziness makes it any more likely.
2020-10-05 04:11:51 <SirClueless> So far I'm not experienced enough to say. Having made multiple "d'oh" style performance flubs like that in my limited time trying out Haskell it does seem somewhat more likely. Less to do with lazy evaluation I think and more to do with super concise ways of abstracting control flow. But I admit I'm not really giving Haskell a fair shot due to my
2020-10-05 04:11:51 <SirClueless> inexperience.
2020-10-05 04:23:00 × polyrain quits (~polyrain@2001:8003:e501:6901:a41a:145a:3fce:c107) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2020-10-05 04:30:30 → sz0 joins (uid110435@gateway/web/irccloud.com/x-ghthpnxjfhyoidss)
2020-10-05 04:39:39 → day_ joins (~Unknown@unaffiliated/day)
2020-10-05 04:41:10 → todda7 joins (~torstein@athedsl-238951.home.otenet.gr)
2020-10-05 04:41:58 × zacts quits (~zacts@dragora/developer/zacts) (Quit: leaving)
2020-10-05 04:43:05 × day quits (~Unknown@unaffiliated/day) (Ping timeout: 256 seconds)
2020-10-05 04:43:06 day_ is now known as day
2020-10-05 04:44:26 × Sheilong quits (uid293653@gateway/web/irccloud.com/x-bxwmidpkndksabez) ()
2020-10-05 04:44:37 → thir joins (~thir@p200300f27f0fc60038c1b16891cbfa03.dip0.t-ipconnect.de)
2020-10-05 04:49:51 × aweinstock quits (~aweinstoc@cpe-67-248-65-250.nycap.res.rr.com) (Ping timeout: 272 seconds)
2020-10-05 04:49:55 × thir quits (~thir@p200300f27f0fc60038c1b16891cbfa03.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2020-10-05 04:50:09 × GyroW quits (~GyroW@unaffiliated/gyrow) (Quit: Someone ate my pie)
2020-10-05 04:50:47 → GyroW joins (~GyroW@d54C03E98.access.telenet.be)
2020-10-05 04:50:47 × GyroW quits (~GyroW@d54C03E98.access.telenet.be) (Changing host)
2020-10-05 04:50:47 → GyroW joins (~GyroW@unaffiliated/gyrow)
2020-10-05 04:51:28 <koz_> Yeah, there's things to watch out for there, definitely.
2020-10-05 05:00:48 × falafel quits (~falafel@2605:e000:1527:d491:706d:90a5:67aa:1cd9) (Remote host closed the connection)
2020-10-05 05:02:21 → thir joins (~thir@p200300f27f0fc60038c1b16891cbfa03.dip0.t-ipconnect.de)
2020-10-05 05:02:37 → aweinstock joins (~aweinstoc@cpe-67-248-65-250.nycap.res.rr.com)
2020-10-05 05:04:07 <dsal> In practice, I write more correct and useful code in haskell than I ever did in C, even though (and likely because) I can't pay huge attention to all the implementation details all the time.
2020-10-05 05:07:17 × thir quits (~thir@p200300f27f0fc60038c1b16891cbfa03.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2020-10-05 05:08:16 → falafel joins (~falafel@2605:e000:1527:d491:99fe:5613:f0a7:56f0)
2020-10-05 05:09:19 <dsal> optparse-applicative started doing this useful thing recently, it seems. https://www.irccloud.com/pastebin/CTguX34u/
2020-10-05 05:16:35 × tomku quits (~tomku@unaffiliated/tomku) (Ping timeout: 240 seconds)
2020-10-05 05:18:50 → idhugo joins (~idhugo@563472ae.rev.stofanet.dk)
2020-10-05 05:21:24 → ym555 joins (~ym@41.42.210.219)
2020-10-05 05:22:39 → takuan joins (~takuan@178-116-218-225.access.telenet.be)
2020-10-05 05:22:51 → shafox joins (~shafox@106.51.234.111)
2020-10-05 05:23:27 × ericsagnes quits (~ericsagne@2405:6580:0:5100:97e:4c35:feee:3de8) (Ping timeout: 240 seconds)
2020-10-05 05:24:23 → snakemasterflex joins (~snakemast@213.100.206.23)
2020-10-05 05:25:36 → coot joins (~coot@37.30.49.218.nat.umts.dynamic.t-mobile.pl)
2020-10-05 05:26:44 × hyiltiz quits (~quassel@unaffiliated/hyiltiz) (Ping timeout: 258 seconds)
2020-10-05 05:26:59 × wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 265 seconds)
2020-10-05 05:28:23 → shatriff joins (~vitaliish@217.27.153.240)
2020-10-05 05:33:35 → tomku joins (~tomku@unaffiliated/tomku)
2020-10-05 05:36:17 → ericsagnes joins (~ericsagne@2405:6580:0:5100:97e:4c35:feee:3de8)
2020-10-05 05:37:20 × idhugo quits (~idhugo@563472ae.rev.stofanet.dk) (Ping timeout: 256 seconds)
←Prev  Next→
Page 1 .. 419 420 421 422 423 424 425 426 427 428 429 .. 5022

All times are in UTC.