The FISA court only handles warrants, not prosecutions. Generally the only parties involved in a warrant request to a court (FISA or any other), are the judge and the government representative(s) seeking the warrant, though the court can pull in third-parties if it wants, e.g. for advice on legal questions.
A secret criminal prosecution trial would be unconstitutional under the Sixth Amendment ("In all criminal prosecutions, the accused shall enjoy the right to a speedy and public trial"). Though SCOTUS has unfortunately allowed for some classified material to be kept secret, sometimes (IIRC) even from the defendant and the jury, though usually this is ancillary stuff, not the direct evidence that would secure a conviction.
Warrants are what's at issue when the 4th amendment is in play. The thing you can't do when FISA issues a warrant is get the details about that warrant, who issued it, why it was issued. You can't even know that a FISA warrant was deployed against yourself.
The US was a net exporter for most of the time it was a de jure and de facto reserve currency, up until the dollar was floated (i.e. end of gold convertibility). IOW, it was arguably the reserve currency status that drove the trade deficits, not the other way around. The effect was muted by the artificial constraint of gold convertibility, but the pressures from that restraint manifested in other problems, culminating in a currency crisis and Nixon's decision to end convertibility. That unleashed the deflationary pressures caused by reserved status, accelerating the shift to goods imports.
> The US was a net exporter for most of the time it was a de jure and de facto reserve currency, up until the dollar was floated (i.e. end of gold convertibility).
No, the US ran a goods surplus but a current account deficit.
If we look at US history, we can divide it into a few periods:
revolution to civil war: US is a net debtor, running goods deficits and borrowing from europe.
1870 - Great Depression/start of WW2: US is running goods surpluses (of about 1% of GDP) but continues to heavily borrow from Europe.
Post WW2 - Bretton woods. US is suddenly the world's biggest creditor, and it's good surplus rapidly declines to a deficit, forcing the US off the gold standard.
That middle period puzzled a lot of economists, because the balance of payments identity says that the current account plus capital account must sum to zero, so if the capital account is positive (continues to borrow from Europe) then the current account must be negative. But here we have reports of the US running a goods surplus! Well, the problem is that even though there was a goods surplus, the current account was negative. The US owed so much money in dividend and interest payments that the money earned from the goods surplus wasn't enough and the US kept getting deeper in debt to Europe throughout this period, which meant that Europe was a net accumulator of US liabilities even though the US ran a goods surplus.
And it was the fact that Europe kept accumulating US liabilities that allowed the these liabilities to be traded as an effective reserve currency. If the US was not getting its liabilities into the hands of the europeans, then there is no way US liabilities could possibly be used to settle international trade. This should be a no brainer.
Now a lot of crazy stuff happened during the stock market crash and capital flight during WW1 and WW2 that turned the table on the Europe, so the US ended up in a situation where, very suddenly -- as in, over the course of just a few days -- it became a net creditor to Europe, but that necessitated the Marshall plan, where the US needed to flood Europe with dollar claims -- which were gifts, not investments -- in order to prevent the European economies from grinding to a halt in the immediate aftermath of WW2, and then the US goods trade deteriorated so that we had to go off the gold standard. Thus the period from the end of WW2 to the end of Bretton woods should be viewed as an anomalous disequilibrium period of adjustment, and if you look at US current account data, you see a fairly rapid decline because the US goods surplus during the WW2 period was artificially inflated by counting munitions and war material as exports, but these exports were "paid" for by loans that were forgiven, and this, together with the Marshall plan, is what screws with traditional readings of the balance of payments identity in that WW2-end of Bretton woods period.
Bottom line, if you want to run trade surpluses and be a reserve currency, you need to be giving away more claims than are necessary to buy your goods, because at the end of the day, the rest of the world has to be a net accumulator of claims on you in order for those claims to be a reserve currency.
Huh, interesting. During the ZIRP period (~2016-2017), I remember suggesting somewhat tongue-in-cheek here that the rational response to negative interest rates is to borrow as much money as possible, use it to raise an army, and then go conquer the people who loaned you the money. It sounds like that is actually what the U.S. did, except with a dose of diplomacy that got them to exhaust themselves fighting each other first.
It's kind of the historical embodiment of "Owe the bank $100, and you have a problem. Owe the bankers $100T, and they have a problem."
Which is what you'd expect if you're exporting more than importing. Perhaps you meant by some other accounting, which is what I was alluding to regarding the distortion caused by gold convertibility. Ceteris paribus, the trade & account balance will zero out over time in the absence of some kind of regulatory or similar distortion. China doesn't need to be a net importer to become a reserve currency, but if they became one (deliberately or otherwise) and allowed their currency to float than in time their exports would tend to fall and they'd likely become a net importer, at least if they became the dominant reserve like the US. (If they didn't float, you'd get a mess like the US had.) The reserve status can drive the balance of trade toward net importing. Which is precisely why China doesn't really want to become a global reserve currency. They'd certainly like the soft power that would bring, but they don't want the domestic employment disruption the US suffers from. That doesn't stop them from wanting their cake and eating it, too; they can try, but nobody really believes they could, so nobody takes it seriously. Though it's not necessarily an all or nothing deal. I'm not sure the world needs a single reserve currency as dominant as the dollar. We have markets to arbitrage and balance currency valuations, including future expected valuations. A singular dominant reserve currency is helpful to reduce friction, but less so when you have huge, global currency and currency derivatives markets constantly trading.
> When both conditions are met, the loop body is replaced with a call to std::this_thread::yield(). This gives execution of the loop the forward-progress semantics it previously lacked.
That's the epitome of the hidden code downside that Linus and many others dislike about C++. For constructors and destructors it's somewhat unavoidable and not so random, though Rust does better at limiting the blast radius of non-local code, at least in the drop case.
If they didn't want to adopt the C11 rule, the C++ committee should've explored a rule that required the compiler to emit a diagnostic or error for trivial loops (whether as defined by C11 or otherwise), requiring the programmer to explicitly insert ::yield or similar. No hidden code, and less opportunity for the compiler to do surprising things.
The C committee has been rigorously enumerating UB cases in the standard and addressing each case in turn, often by requiring a diagnostic, error, or by turning it into implemention defined behavior. But inserting code like that would be unthinkable.
The C++ committee has a habit of thumbing its nose at standard practice. They intentionally broke bitwise operators on volatiles because they wanted to be impose their atomic religion everywhere. Then they had to walk that back after they broke every embedded library directly manipulating hardware registers.
Empty infinite loops are also commonplace in embedded C once main is done with init and within exception handlers. They don't care about anything beyond their narrow systems programming worldview.
By narrow luck compiler writers so far have been the sane bunch, and have ignored C++ committee on many important points. Thus we still have explicitly non-conformant things like -fno-exceptions that lets one use C++ compiler on embedded.
But I wonder how long that can last, with the way C++ is going.
At one point, it will make practical sense to update codebase to some other language, rather than keep fighting this one
"broke" is arguably an overstatement. C++20 deprecated some (most?) operations on volatile variables [0] in part because they can misleadingly imply an atomic operation:
> volatile external modifications are only truly meaningful for loads and stores. Other read-modify-write operations imply touching the volatile object more than once per byte because that’s fundamentally how hardware works. Even atomic instructions (remember: volatile isn’t atomic) need to read and write a memory location []. These RMW operations are therefore misleading and should be spelled out as separate read ; modify ; write, or use volatile atomic operations which we discuss below.
This was not received particularly well in the embedded community (e.g., [1]) due to said deprecation affecting compound bitwise operations on volatile variables, which are extremely widely used to interact with hardware registers. This pushback eventually resulted in C++23 un-deprecating compound bitwise operators on volatile variables [2].
And memcpy is kind of special to C/C++ compilers. Sure, it exists as a function, but it will often have special purpose code generated for that particular location.
It’s obvious why you want to inline memcpy, but the specialization is more interesting. For example, I’ve seen the compiler optimize a memcpy with a static number of bytes and then use SIMD registers to do the copying with no loop at all. It can even be smart enough to take advantage of memory alignment for this.
> should've explored a rule that required the compiler to emit a diagnostic or error for trivial loops (whether as defined by C11 or otherwise), requiring the programmer to explicitly insert ::yield or similar
It wouldn't work when this kind of loop is generated by macros/templates in some unreachable case left after const folding.
If it's truly unreachable then it's not likely to be a problem. If it is reachable and it's emerging from some macros and templates then I would be more inclined want a warning for it.
As the only observable behaviour of this_thread::yield is forward progress, because of the as-if rule, the compiler doesn't actually need to replace the loop, when running on a runtime that guarantees preemption. That's the case when std::threads are backed by kernel threads. On a M:N implementation, then yes, a yield would need to be added, but that would be desirable.
Interestingly, posix realtime FIFO scheduling doesn't preempt even on kernel thread based implementations, so one reading of the standard would require yield on this case. But that can actually be potentially catastrophic as FIFO scheduling is expected to be deterministic. But realtime scheduling is already beyond the standard: I doubt gcc and clang will do the transformation by default.
In practice the equivalence is necessary to make some obscure corner of the memory model work and prevent some undesirable optimizations; I expect that in practice the compilers, if they implement this at all, will provide an opt-in flag, but they will optimize as-if the call was there.
It's catastrophic actually. Like disastrously catastrophic. It started with C++20 mostly, and has only kept getting worse from then. See zero initializing variables by default (WHY?) compare/meta including half the STL and HARDCODING those symbols, std::initializer_list being in the std namespace (if you don't include <initializer_list> you literally can't use it, and there is no such thing as a __initializer_list or some internal symbol), the entire coroutine library where you MUST provide coroutine_handle, noop_coroutine, suspends et al (coroutines aren't that bad because they're not necessarily spaghetti).
<meta> is the single WORST OFFENDER, where they hardcode std::vector (literally std::vector in the std namespace) std::ranges std::allocator.
I can't find anything saying variables are zero initialized by default in C++20. But the reason to do so is obvious: many bugs are caused by the lack of this, and as long as you can opt out with "= void" or something, it's not violating C++ core principles.
They were saying the problematic philosophy started in C++ 20, not the variable initialization rule.
Yes the reason is obvious, but it’s neither simple nor black and white. One huge problem is that this can cause serious performance regressions, and you have to change your code to opt out, e.g. add “[[indeterminate]]”. There are many, many cases in high performance computing where the intended & desired behavior is don’t touch my variables until I fill them.
This is changing C++ core principles, there’s a new designation for the state of a variable: erroneous. It’s also subtle and weird, because you can still have well-defined behavior even with erroneous state. It does seem like this might be an experiment though, I don’t think this is the end of the story. (It seems they’re already talking some redesign of this idea.)
Uninitialized variables were already UB to read, because some architectures have trap representations, even for integers. Every register on Itanium has one.
What I'm most annoyed at with the variable initialization change is that:
- It's potentially a performance change in every single function, especially ones that have sizable fixed-size buffers
- If you have regressions you have to spray [[indeterminate]] everywhere, because there is no coarser way of suppressing it.
- While the language says unrecognized attributes are ignored, compilers frequently warn on unrecognized attributes. Clang, for instance, currently warns on [[indeterminate]].
- There is no defined macro name for backwards compatibility.
Which means that libraries are going have to all declare their own macros for [[indeterminate]] and pepper their code with it.
Strictly speaking the standard only requires some pattern that is not tied to program state. Zero works for that, but so do other static patterns like 0xABAB... or the like.
> (WHY?)
The motivation section of the corresponding paper [0] might be interesting. tl;dr: it lets wrong code be wrong without suffering from (all) the consequences of full-blown UB.
I’d guess the concern is performance, not what initializer value is used. And performance is a valid concern that is discussed in the proposal, and a reason there’s an escape hatch. Still, it might cause some confusion.
> For constructors and destructors it's somewhat unavoidable and not so random, though Rust does better at limiting the blast radius of non-local code, at least in the drop case.
Unlike C++, Rust does not manage exceptions at all; in C++, you must consider situations where exceptions arise.
If panics are set to unwind, you do need to consider it, and the UnwindSafe auto trait is there to help with memory safety, but logical issues can still arise.
In the context of that particular complaint, yes. From what I understand the gist of it is basically that you should be able to tell what is going on by looking at the code locally (i.e., the code is "explicit").
> I think Linus's complain was before there was a c++ standard.
These emails [0]? IIRC those are the most well-known ones and they are from the mid-2000s
An empty loop, under some non-obvious conditions, on some compiler flags but not others, silently transforms into a system call. In a systems programming language.
Destructors run predictably at list, and are pervasive everywhere. You know that when you exit a scope, be that a function or whatever it may, the destructors of variables in that scope are called. That is clear and consistent. The transformation mentioned above is not.
Understanding the code requires understanding the destructors of the objects you're using. Since they are invisibly inserted, they are a source difficulty in entirely understanding the code.
I do wonder if any of the language servers that insert implied type annotations would ever also show things like destructor calls in a similar manner. It seems like it would be quite useful.
Both Monal and Conversations support XEP-0357. Each project runs their own XMPP-to-Apple/Google gateway for push notifications. It has to be that way because the gateway server and client phone application have to be signed by the same developer account.
The client phone app tells your XMPP server which gateway to use (or maybe it's vice-versa, the gateway contacts your server. I forget). In any event XMPP servers like Prosody support this out-of-the-box.
That's true for states like California and perhaps the US generally, but in states like Texas industry uses half of all energy. (
https://www.eia.gov/todayinenergy/detail.php?id=66224) Likewise for South Korea and China where over half is for industry. This is precisely because most states exported their heavy industry, both overseas and to states like Texas, which has many chemical plants and similar energy-intensive industry.
A strict liability crime is something of an oxymoron. Crimes always require intent, the mens rea element. The question is intent for what. If somebody drugged you without your knowledge and you were charged with a DUI, you would have a defense--no intent to become intoxicated.
The strict liability means once you choose to become intoxicated, you're liable for driving intoxicated, even if in some other context your intoxication would mean you couldn't form the requisite intent for something, e.g. have sex.
If there's too much distance between the act you intend to do and the strict liability acts that complete the crime, then the crime would be considered unconstitutional.
Criminal law in common law systems emerged from tort law, so there are many parallels, including the notion of strict liability. (Thus the old axiom about crimes being an offense to the king, specifically an injury to the peaceful society he's ostensibly trying to maintain.) But criminal law has a moral dimension that is absent or muted in other areas, so strict liability could never be as expansive as in tort law or regulatory law.
That is just not true. You can be held liable for DUI even if you did not intend to become intoxicated (though this may vary somewhat state-by-state). Speeding is another example - you do not need to intend to go over the speed limit, it just matters that you did it. The only possible exception would be duress or necessity, but those are affirmative defenses, which are separate from the elements of the offense.
As a summary of American criminal jurisprudence I'm willing to stand by what I said. But I'll admit some caveats:
1) Traffic-related laws straddle the boundary between civil/regulatory law and criminal law. Someone losing their driver's license or even paying a penalty for involuntary intoxication would still be consonant with criminal law principles. However, a criminal punishment would be aberrational. (Distinction between a civil penalty and criminal punishment usually turns on whether there's a moral purpose to the sanction. Jail time is usually but not always--cf civil contempt incarceration--considered a criminal punishment.)
2) Background principles notwithstanding, in theory a state could completely dispense with any morality-colored mens rea requirement, just as the UK Parliament could do whatever it wants to. The backstop would be Federal constitutional [substantive] due process guarantees.
2.a) Some quick searching shows that Texas nominally seems to have dispensed with this requirement for DWIs. See e.g. Farmer v. State, 411 S.W.3d 901 (Tex. Crim. App. 2013) and some discussion at https://www.ncdd.com/top-dui-attorneys-blog/involuntary-into... Without having fully read the case law, though (but some summaries of that and other cases), I suspect there might be some nuance that has allowed this to stand without a full majority accepting that the traditional principles have been completely thrown out. For example, even if someone didn't know they were taking Ambien, the simple act of voluntarily taking any pill without careful examination can be construed as a sufficiently culpable act. Still, it's a pretty big caveat.
2.b) Statutory rape is a classic strict liability crime. But most states will permit a mistake-of-fact defense. Some don't, but even there there's sometimes some nuance and rationalizing going on and the literature is crazy complex. Because this is a "think of the children" situation, most case will just have horrible facts.
3) A few states have nominally dispensed with insanity defenses, though Kansas stands out the most. SCOTUS upheld Kansas' law in Kahler v. Kansas, but in the majority opinion Kagan characterized the Kansas law as not abolishing the insanity defense but rather changing its shape, and she showed that there still remained elements for which a defendant could plea lacked the requisite intent. Also, regarding the Federal constitution acting as backstop, she reiterated that SCOTUS was reticent to establish strict metes & bounds about the general principles of criminal law that states could not stray beyond. Nonetheless, those principles clearly exist.
I had some other points, but now I've forgotten them. Also, minor pedantic point, but like "strict liability crime", some scholars consider "affirmative defense" to be oxymoronic. As a substantive matter there's not a strong distinction. It's a procedural distinction about initial burdens of proof, but in most if not all cases you can interpret an affirmative defense as simply placing a very weak initial burden on the prosecution that is implicitly met.
(Note, I'm not a practicing lawyer but do have a law degree.)
EDIT: Ah, point 4) Intent was a big sticking point in the Obamacare penalty case, Sebelius. Both the dissent and Roberts (the swing vote) reiterated that you couldn't have a penalty or punishment for doing nothing. (IIRC some of the majority opinions also echoed this.) That is, even in a civil context there has some to be some voluntary act, however remote, that puts someone in a position to be subject to legal liability. But as Roberts pointed out, the taxing power is the great exception, where you can be required to do something merely for existing, and thus penalized for not doing nothing properly. (And Roberts was the critical swing vote.)
EDIT EDIT: Also see, "Solving General and Specific Intent: A Mapping on the MPC and Applications to the Categorical Approach", https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4754469 In describing the distinctions between general and specific intent in criminal law, it also delves into the definitions of strict criminal liability (which can be construed as either very similar or identical to general intent crimes), and notes that SCOTUS generally inserts an implicit mens rea requirement when considering strict liability criminal statutes.
> A strict liability crime is something of an oxymoron. Crimes always require intent, the mens rea element.
This is wrong.
In criminal and civil law, strict liability is a standard of liability under which a person is legally responsible for the consequences flowing from an activity even in the absence of fault or criminal intent on the part of the defendant.
Fairly certain that the entire point of strict liability is that mens rea is not required for certain crimes. As in, if I meant to travel at 70 and was instead doing 100 it doesn’t matter that I sincerely meant not to speed and did not know I was speeding, I can still be convicted even if the judge believes I had no intent.
The way we use mens rea in our legal system is more like "mind of the criminal," not outright literal intent.
Negligence can be "unintentional" but still land you in the realm of having a guilty criminal mind.
I find it to be a reasonable take. If you're accidentally going 100 in a 70 (which is a misdemeanor in california), you're not being a careful enough driver, and we deem that lack of care criminal.
Strict liability literally is crimes that don't require a guilty mind.
That's different (sometimes) when, for example, you're found guilty of criminal negligence leading to someone being injured.
Prosecutors don't have to demonstrate that you intended for someone to get hurt for that, your mens rea is that you should have perceived the danger of what you were doing but didn't.
edit: reading your other comments in this thread, maybe I missed your point, in which case, whoosh.
> As in, if I meant to travel at 70 and was instead doing 100 it doesn’t matter that I sincerely meant not to speed and did not know I was speeding, I can still be convicted even if the judge believes I had no intent.
IANAL but from what I've looked up in the last there's at least willfulness that matters for these things. For example if you could prove that happened because your car accelerator pedal broke and you had no opportunity to react, I'm pretty sure you would not be guilty, strict liability or not.
Don't forget GCJ. It wasn't removed from GCC until about 2016, a nearly 20-year long run, though interest had waned many years prior.
I don't remember if GCJ supported loading and running code dynamically with a built-in JIT or interpreter. I think it was just pure AOT, which caused some compatibility headaches.
GCJ was great - I wrote a handset UI entirely in java for a startup in the early 2000's, basically android before android existed, using GCJ. I remember their native interface was somewhat more convenient to use than JNI.
I wish we had GCJ resurrected, now that the java libraries are GPL'd.
I worked on this years ago. Gcj did support loading and interpreting bytecode alongside the AOT-compiled code. libffi's closures were originally implemented to support calling interpreted methods from AOT-compiled code, because a class's vtable could include a mix of AOT-compiled and interpreted methods. You could also compile jar files directly into .so files, which would get loaded and used at runtime if a classloader ever loaded the corresponding jar.
Not sure if you meant to imply it, but you don't need to remove driver liability to incentivize the inebriated to use autonomous mode. That's a calculation even someone who's blackout drunk can easily make.
Removing liability might incentivize more people to, e.g., drive their car to a bar. I'm not sure that's a good thing. Maybe great for bars and restaurants, or possibly quality of life, but removing liability probably has other unintended consequences.
It's maybe too early tell whether criminal liability should be changed, or at least how it should be changed. If criminal liability had been removed when Tesla started making their extravagant self-driving claims, surely you'd agree it would have been too soon, and potentially resulted in more accidents. Few if any consumer autonomous driving modes are as reliable as Waymo
Absent statutory changes, common law tort will probably evolve in some states to take into consideration new incentives and norms, and that might help point the way for changes in criminal law. Those policy changes are typically driven by courts wrestling with real world cases, whereas de novo legislative changes are often driven by imaginations and lobbying.
Criminal liability aside, if I am in a wheelchair all my life, requiring expensive medical care, someone will need to pay for that. So civil liability will need to be sonewhere.
Is that not precisely the point of the current discussion? Currently, the manufacturer is not liable. The liability can not be delegated by the driver.
The manufacturers of a self-driving car can be held and are held liable today, same as if the brakes were defective (strict product liability) or improperly marketed (negligence). That doesn't mean the driver might not also be liable. It all depends on why an accident occurred and a host of other factors. There's really nothing special about self-driving cars in this respect, except that litigation can be much more factually complicated. For failing breaks, it's relatively clear given X speed and Y distance, and assuming they were engaged, whether they worked. Then you work backwards from there. Negligent driving? Poor maintenance (driver or mechanic)? Defective design? But in driver assistance and automation systems there are many more questions about what was actually expected to happen, or what was reasonable to expect to happen.
A secret criminal prosecution trial would be unconstitutional under the Sixth Amendment ("In all criminal prosecutions, the accused shall enjoy the right to a speedy and public trial"). Though SCOTUS has unfortunately allowed for some classified material to be kept secret, sometimes (IIRC) even from the defendant and the jury, though usually this is ancillary stuff, not the direct evidence that would secure a conviction.
reply