>In the latter case, even when the compiler chooses to inline the function, it also emits code for an independent instance of the function, because the function is public and it may be called from another file.
Not in standard C. "inline" function provides implementation for usage iff compiler decides to inline the call. If it does decide not to inline, it will emit call to external symbol that needs to be defined in different TU (otherwise you will get errors at link time).
The meaning of "inline" differs between C and C++.
Quote from the gcc manual:
"GCC implements three different semantics of declaring a function inline. One is available with -std=gnu89 or -fgnu89-inline or when gnu_inline attribute is present on all inline declarations, another when -std=c99, -std=gnu99 or an option for a later C version is used (without -fgnu89-inline), and the third is used when compiling C++."
Nevertheless, "static inline" means the same thing in all 3 standards, unlike "inline" alone.
This can be a reason to always prefer "static inline", because then it does not matter whether the program is compiled as C or as C++.
Oh, it's really percentage of all produced. Weird that they worded it in a way that makes their argument weaker.
>Based on available studies, an estimated 4-9% of all textile products put on the market in Europe are destroyed before use, amounting to between 264,000 and 594,000 tonnes of textiles destroyed each year.
If you allow contraction after inlining, whether or not an FMA will get contracted becomes subject to the vicissitudes of inlining and other compiler decisions that can be hard-to-predict. It turns out to be a lot harder of a problem to solve than it appears at first glance.
First, the insurance company incurs costs just processing the claim. If things escalate with the other party, they may even incur legal and court costs.
Additionally, there are some costs that are incurred regardless of fault -- like personal injury protection.
Even defining "who was at fault" is a complicated situation. A lot of people presume that it is as simple as: whoever the police issues a citation to at the scene is 100% at fault. But that's not the way things actually work. The way liability is assigned depends on the state, but in a comparative negligence state you could be proportionately liable for as little as one percent of the fault of the accident. Maybe someone else ran a red light, you entered the intersection on green, and hit them. You could end up sharing some of the cost for that, if it is found that you could have avoided the accident but decided not to.
And even after all of this, if the other party runs out of money, doesn't have insurance, or runs away at the scene, your insurance company is stuck paying the costs under their uninsured/underinsurred motorist coverage.
It does cost them just to process the claim because the other guys side is unlikely to completely roll over if there is any chance to reduce the payout. Obviously its not as much as the claims themselves but it also isn't free.
Yep. I have a friend that was plowed into from behind while waiting at a red light, twice within a few months time. Two separate intersections. Totaled her car both times. Her insurance rates went up, even though she was clearly not at fault.
"Not at fault" as far as the law is concerned, is a low bar. If you're one of the last cars in a queue, you should be checking your mirrors for exactly this scenario. Throwing your hands up in the air saying "well the law says I did no wrong!" isn't the way. Unless you like getting into accidents.
Also, having two of the same type of accident twice in such a short time is so improbable, that I'm seriously doubting your friend. I'd say it's way more likely she braked too suddenly or has other bad driving habits that make such accidents more likely than that she got this unlucky.
It's not even that. The main reason is probably that attackers are going to be writing code to automate their attacks, and desktops are easier to develop on than phones, so that's what they use with no reason to do otherwise.
Even if you stopped supporting desktops, then they would just reverse engineer the mobile app instead of the web app and extract the attestation keys from any unpatched model of phone and still run their code on a server, and then it would show up as "mobile fraud" because they're pretending to be a phone instead of a desktop, when in reality it was always a server rather than a phone or a desktop.
And even if attestation actually worked (which it doesn't), that still wouldn't prevent fraud, because it only tries to prove that the person requesting the transfer is using a commercial device. If the user's device is compromised then it doesn't matter if it can pass attestation because the attacker is only running the fake, credential stealing "bank app" on the user's device, not the real bank app. Then they can run the official bank app on an official device and use the stolen credentials to transfer the money. The attestation buys you nothing.
All this theatre is turning out to be nothing more than giving up the agency we have today (nice things), for a risk averse kneejerk runaround with glaring ulterior motives...just like the scan your face+id push for services.
Would YOU be willing to use a bank that refused to use TLS? I didn't think so. How is you refusing to accept remote attestation and the bank refusing to connect to you any different?
Because Banking has existed and operated fine for countless decades without it(attestation).
Also, as there is ample discussion elsewhere, having attestation does NOT eliminate the ability for your account to become compromised.
As restated.
"If the user's device isn't compromised then everything is fine regardless of whether or not it can pass attestation. If the user's device is compromised, the device doesn't need to pass attestation to run a fake bank app and steal the user's credentials. Once the attacker has the user's credentials they can use them to transfer money regardless of whether or not they have to use a different device that can pass attestation.
It doesn't really provide any security."
IT DOES however completely rewrite the paradigm of general purpose computing in very asymmetrical ways.
Stop ignoring my question. If it is OK for YOU to refuse to use a bank that doesn't use TLS then why isn't it OK for a bank to refuse you as a customer if you refuse to agree to remote attestation? Both parties have the right to specify reasonable security postures and either mutually agree or not.
Not OP, and also not sure where I actually stand on this debate because I think your point has a lot of validity to it, but...
I think there's also an argument in favor of a person having the right to access their money (and I'd argue that accessing your bank's website/app is accessing your money) however they want, and that access to their money is more of an important right than the bank's right to control how that access happens.
I think we can all agree to some "within reason" clauses on both sides (eg not allowing HTTP only access seems reasonable), and I guess a lot of this debate is "is requiring attestation within reason?"
To me, any asymmetry between the rights of the consumer and the rights of the bank should be in the favor of the consumer.
Not in standard C. "inline" function provides implementation for usage iff compiler decides to inline the call. If it does decide not to inline, it will emit call to external symbol that needs to be defined in different TU (otherwise you will get errors at link time).
reply