planede

A lot of legal constructs are defined by intent, and intent is always something that is potentially hard to prove.

At most the obviousness should the burden of discovery on them, and if they have no records or witnesses that would demonstrate the intent, then they should be in the clear.

I would start to collect a LOT of paperwork documenting that the casting selection was done without a hint of bias towards a celebrity's impression.

IMO having records that explicitly mention SJ or Her in any way would be suspicious.

IANAL

I think that reaches too far. Intent should be a defining part of impersonation. IANAL and I don't know what the law says.

which in this case would simply be appending the namespace name to the identifier

surely not. How do you differentiate these two functions?

  void fooN(void);
  
  namespace N { void foo(void); }

How do you define a buffer overflow?

I don't doubt that general heat tolerance isn't real for the healthy part of the population. However the hottest days could hit elderly and unhealthy people especially hard (or even the healthy, if it's especially hot).

Many people live without AC, and even those with it often won’t use it except for the hottest few days of the year.

That can still make a lot of difference.

I speculate, but there might also be a part where simply more people suffered from heat strokes in the past when extreme temperatures occurred. So part of the answer of "how did people live before ACs were invented?" is that some didn't.

It's only really about the intent of the voice to sound like the original. Reaching out to the originals first implies intent, so it makes the case easier.

It would be harder to find a case if they simply just hired someone that sounds similar, but if they did that with the intention to sound like the original that's still impersonation, only it's harder to prove.

If they just happened to hire someone that sounded like the original, then that's fair game IMO.

IANAL

Impersonating is defined by intent. "Just find someone who sounds like her" implies intent.

Nitpick: it's not copyright, it's personality rights and likeness. It's a violation of it nonetheless.

Love the data driven approach through graph clustering, instead of jumping into opinionated refactoring.

Right. But you also get a recent one if you just use the Mozilla PPA, without snap. Debian sid also ships 126, and I assume the fix should be backported to Firefox LTS, which is used by stable.

I don't see the relevance of snap here.

Yes, that's the philosophy around the declaration syntax.

The declaration of the pointer ip,

  int *ip;

K&R C

  return '⊥'

Well of course, I assume that's what my ISP is using.

Well, camera placement matters in the obvious way: it has to be on the finish "line". Where "line" is really a plane extending vertically from the line drawn on the surface.

I vaguely remember an article about a bike race photo finish that showed that this is not a given and reverse engineered where the camera was pointing (based on background) and who the likely winner was.

edit: found it https://www.tglyn.ch/blog/amstel_gold/

I recently learned that too. Does that survive OTA updates?

MicroG has a LineageOS distribution, they build for all the supported devices by upstream Lineage: https://lineage.microg.org/

That should cover at least the notification side. If I can't bank on a mostly open-source mobile OS than I would rather just not bank on mobile at all. Banking on stock ROM is not an option for me.

Google Play is not installed by default, you need to additionally flash it before first booting it.

I think the idea is that email scraper bots typically don't bother downloading images referenced by <img> tags.

BTW. Use the AddressSanitizer. Please! The toolchain improved the usage and safety of the language so much.

In general I agree with the sentiment, use AddressSanitizer in testing/debugging. However it's not meant to be a hardening option, AFAIK, so I advise against using it in production (along with other sanitizers), even if you can live with the performance hit.

It's obviously a lossy compression then.

Is there a JSON parser library that is not under active development?

The problem isn't really about handling local time. UTC is an offset from TAI and time zones are offsets from UTC, it's overall really just an offset from TAI. Coordinating the TAI-UTC offset is not any worse than coordinating time zone offsets.

The complications are around clocks, UNIX timestamp and NTP, where a steadily and monotonously increasing number would make the most sense, and that's not UTC.

Maybe anything so simple that it can be considered "done" shouldn't really be an external dependency in the first place.

That's what TAI is for. Too bad nobody got the memo and everybody stores and communicates UTC, including computer clocks, UNIX time and NTP.

There will be no more leap seconds after 2035, AFAIK.

At least leap seconds will be eliminated by 2035, so there is that. Computers were never good at dealing with it. Keeping computer clocks in UTC instead of TAI and rewinding it for leap seconds was always insane. The same goes for UNIX time and NTP.

I don't think that lines of code is a good metric here. A few lines of code can fix a major security issue in parts of a dependency that you actually use, while thousands of lines of code can just add new features that you are not using anyway, otherwise you would have upgraded already.

Agreed. If the dependency is under active development then it should be only counted as being behind if there is a newer version released for that dependency. The libyear should be calculated as "latest version's release date" - "currently used version's release date".

What complicates this is deciding whether the dependency is under active development or not. If its EOL'd then you still want libyear to accumulate, even if you use the latest released version. I guess comparing to an end-of-life date then would make sense, but it's probably harder keep track of.

yeah, thanks! I added an edit.

Technically the array subscript example is UB even before the dereference. a[1][7] is equivalent to `*(a[1] + 7)` and a[1] + 7 itself is UB.

(6.5.7) Additive operators

If the pointer operand and the result do not point to elements of the same array object or one past the last element of the array object, the behavior is undefined.

Interestingly a[1][5] is also UB, but for the dereferencing a past-the-end pointer, not for the arithmetic.