abainbridge

Gas-fired central heating became affordable and was much nicer.

A few fairly large economies are planning to ban sales of new fossil fuel powered cars by 2030 and a bunch more by 2040. https://en.wikipedia.org/wiki/Phase-out_of_fossil_fuel_vehic...

> but it's impossible to argue that not trying to prevent UAF is somehow safer.

It might be possible. Someone might prove that preventing UAF necessarily increases complexity somewhere else. Like one of those laws of thermodynamics, but for software.

> Haha, I was actually the attacker in this instance :)

I need more sleep.

Er, really, wow. I didn't know that. Can you point me at some more info for that? Surely the GPIOs don't go via the GPU.

@StavrosK Thanks for wading in in my defence, but I had actually mis-understood the situation :-)

Although, if my theory that the IO buffers are different sizes is true, then that could perturb memory layout enough to expose/hide the bug in either direction.

5GHz WiFi has more bandwidth than 2.4GHz, so typically will involve larger IO buffers in the driver, which could easily be enough to expose a memory scribbler (I imagine there's a bunch of other features that are enabled/disabled by the frequency band switch too). However, I think asdfasgasdgasdg's answer is the correct reason not to suspect a memory scribbler - ie a memory scribbler would cause the driver to crash/fail and the kernel would log a message.

> Why not use -march=native?

The conditional jump remains even with -march=native.

https://godbolt.org/z/2p7uAB

Isn't the correct way to write this loop actually:

  void toupper_cmov(char* buf, size_t size) {
      for (size_t i = 0; i < size; i++) {
          char c = buf[i];
          buf[i] = c - 32 * (c >= 'a' && c <= 'z');
      }
   }

Because that persuades gcc and clang to transform the conditional branch into a conditional move which avoids the branch mispredict penalty and removes the need for a lookup table.

See https://godbolt.org/z/xHYKft

Disclaimer: I haven't actually run this function. That would be too much like work.

Interesting. It looks like the sea level has also risen by about 17.5cm in the last century - https://www.epa.gov/climate-indicators/climate-change-indica...

Interesting link. I'm not sure how to interpret these numbers though. It says Amazon gets $752 per user per year. But this seems like it is nothing to do with how much my eyeballs are worth - people give Amazon money in return for stuff. The only other brand on that list I use is Google. I'm outside the US, so it appears my eyeballs are worth $137 per year. That is an amount I'd be prepared to pay if it made adverts go away and the money was split between the content providers I do use. But it isn't really clear (to me) how the old guy on YouTube who restores the antique furniture would collect his 75% share due to my eyeball time.

I wasn't trying to claim that middle mouse canvas movement didn't work in Lucidchart. The mechanism is just different, and IMO worse, than the one in draw.io. I think if you ask ten users to try both, you'll find a clear preference for the draw.io mechanism. I think it is important because it is an exceedingly commonly used feature.

Dragging the canvas around with the middle mouse button seems much more intuitive in draw.io to me.

Good point. Thanks for the patient explanation.

To partly redeem myself, I followed the links to the first two articles prefixed by "P". They were https://www.ncbi.nlm.nih.gov/pubmed/29725476 and https://www.ncbi.nlm.nih.gov/pubmed/29268055

The first didn't have a conclusion and the results were just the measured RF power in an apartment.

The conclusion of the second is, "A total of 900-MHz EMF applied in middle and late adolescence may cause changes in the morphology and biochemistry of the rat ovarium.", which makes no sense. "A total of 900-MHz EMF" is gibberish. The complete text is not freely available.

The article says, "more than 500 studies, have found harmful biologic or health effects from exposure to RFR at intensities too low to cause significant heating." The link to the 500 articles is https://drive.google.com/file/d/19CbWmdGTnnW1iZ9pxlxq1ssAdYl....

I checked the "conclusions" of the first two: https://www.ncbi.nlm.nih.gov/pubmed/29996112 and https://www.ncbi.nlm.nih.gov/pubmed/29709736

Conclusion of 1) Despite the improved exposure assessment approach used in this study, no clear associations were identified. However, the results obtained for recent exposure to RF electric and magnetic fields are suggestive of a potential role in brain tumor promotion/progression and should be further investigated.

Conclusion of 2) Ever use of wireless phones was not significantly associated with risk of adult glioma, but there could be increased risk in long-term users.

They both read as, "we found no significant effect".

Is there a reason none of these replacement libcs are available for Windows?

Exactly this. I see this as "Simplest possible C code beats carefully hand optimized Haskell".

You could open your own socket to the xclient and speak xprotocol yourself.

How would I create the pointer to int in the unique_ptr case without initializing the int? I tried this: https://gcc.godbolt.org/z/SfVxzU

I expect there is a way, just I don't know it.

> A cursory look at the CVE list for any C software in the wild

How can I see that list? I'm interested in comparing languages this way.

Looks reasonable to me. I've been programming C daily for 25 years. Cosmetic but it is nice to see "int const foo;" being preferred to "const int foo". And "We define variables as close to their first use as possible". Less cosmetically, section 5.6 on named constants is great. That's a fiddly area of C from which to pull out reliable advice.

The dis- prefix just means "not". https://www.etymonline.com/word/dis-

Ha, nice one! So if the Amazon is like lungs in this sense, where is it bringing the oxygen in from?

Not least because lungs take in oxygen and output carbon dioxide. I guess while the Amazon is on fire it acts a bit like lungs.

The offices in Cambridge didn't shutdown. Approximately Samsung bought one building (WiFi), and a year later Qualcomm bought the other (BT + audio). Both Samsung and Qualcomm had rounds of redundancies but have also both hired lots of people. My guess is both offices are about the same fullness as they were ten years ago.

> But you also left developers with really hard to use dev tools based on a fork of gcc

Yep. Sorry about that. Not that it was my fault. Anyhow, I guess my belief is that a similar company to CSR could put RISCV cores in their chips now, which would avoid the problem you describe and some of the problems I described with using ARM.

This argument used to come up when I worked at Cambridge Silicon Radio, where we made ASICs. We made our own CPU designs for those ASICs.

Some of the engineers thought making our own CPU designs was a stupid idea and some thought that switching to ARM designs was a stupid idea. The only fact I have is that our CPU designs were not the main cause of bugs in our chips. If you asked the digital designers, they'd say things like, "Why are software engineers so interested in CPU designs. The kinds of embedded CPUs we need are easy to design. Implementing a correct power management state machine is hard. Implementing an efficient WiFi PHY is hard. Get off my lawn..."

Some problems with putting ARM CPUs in our chips were: a) integration engineering costs (ie find a way to multiplex some existing pins on the package with the jtag debug port), b) having to do price and contract negotiation with ARM (that part of the company was less efficient than the digital engineering team), c) finding that the change you wanted to make to the chip was incompatible with the ARM contract you'd just spent 6 months negotiating.

I really liked the article. I think the idea is fundamental. It sheds light on the value of things like trying to retain staff and allowing them to become experts on a piece of code. It explains why Brook's Law ("adding human resources to a late software project makes it later") is true.

> in the prototyping phaze

I'd go further than that. I'd say in production too. If the simple thing is fast enough even when you test on a slow machine, then implementing the faster but more complicated data structure is a form of premature optimization.

In my text editor, I just use a doubly linked list of lines, instead of a rope. It doesn't limit the performance in any situation I've found. A performance problem I do have is large column mode edits. eg if I want to delete the first columns of the entire file (typically some log file with timestamps at the start). I suspect the rope data structure would make that worse.

I like the simplicity of the doubly linked list of lines. I'm not sure what advantage the rope data structure would bring.