> An object of dynamic type Tobj is type-accessible through a glvalue of type Tref if Tref is similar ([conv.qual]) to: Tobj, a type that is the signed or unsigned type corresponding to Tobj, or a char, unsigned char, or std :: byte type. If a program attempts to access ([defns.access]) the stored value of an object through a glvalue through which it is not type-accessible, the behavior is undefined.
The dynamic type of a char buffer is, well, a char buffer, and can only be accessed via things that are the same type as a char buffer up to signedness and cv-qualification. The actual strict aliasing rules are not commutative!
If the type is an implicit-lifetime type, then you can legally create an unsigned char array, and then reinterpret_cast a pointer to that to a pointer to the type.
https://eel.is/c++draft/intro.object#15 is an example showing this with malloc; the subsequent paragraph further permits it to work with an unsigned char array.
This gets to the heart of effective type rules, which are complex, confusing, and not properly implemented by compilers. C and C++ definitely diverge here, because C is less ambitious in its object model (which mean it just simply leaves so many details about it undiscussed).
Malloc returns memory that is uninitialized and has no type. The effective type of that memory is initialized on first use by C, whereas C++ relies on angelic nondeterminism to magically initialize the type at return type to whatever will work in the future.
> Malloc returns a buffer and then you cast it to the type you want.
You can’t cast the buffer — you’re casting the pointer.
One might argue (I’m not sure whether this is correct) that malloc allocated an array of ints and the language merely has no way to state that directly. Then you write to those ints using a char pointer, and then you access them as ints, but they’ve been ints ever since allocation.
If you have 29 arguments, I assure that you some of them are on the stack in nearly every architecture in use. Also, certain types as parameters also get passed on the stack (usually types larger than a register, or in C++ code, objects with nontrivial constructors or destructors).
Sure, but he still came up with a 2005 blog post, and attached a 2026 to it. No optimizing C compiler cares for the 2nd arg, when it's a register anyway. And if the 1st is constant, the dead branch is folded away. So the 2nd arg is dead
The markets are definitely underestimating the impact of the Strait of Hormuz closure. I've heard a couple of different theories why, but the best one seems to be that too many traders were burned by overestimating the impact of COVID on the markets, and so now they're overcompensating by underestimating the impact of the energy sector's worst nightmare. And I don't think the markets are going to properly react to the situation until everything goes absolutely haywire.
The closure of the strait has cut off 10-20% of global crude oil supply. We're at the point in the shutdown where all of the transit before the closure has arrived, which means the effect of the supply shock is now that refineries are draining all of their inventories. That means that 10-20% of demand for refined petroleum products will have to pretty sharpish be destroyed. And while people are definitely prepared to understand the impact on things like gasoline for cars or jet fuel for planes, the reality will also include scenarios like "sorry, can't buy milk anymore because no more plastic for milk jugs." COVID-induced supply shortages broke many people; the coming oil-starved supply shortages are probably going to be at least as bad.
And the real kicker is that, even if you wave a magic wand and reopened the Strait of Hormuz tomorrow, mothballed wells and refineries will take many months to spin back up to full production, just from mothballing. And some of them have been struck as military targets, which will take years to get back to full capacity. I think around 10% of world total LNG capacity is offline until 2027 if not 2028 for that reason alone.
About 20% of the crude oil and natural gas used to come via the Strait of Hormuz. That's out now, and some oil drills will need to be shut down, and it will take 3 months to 2 years to restart them.
But about half of that could be redirected via some pipelines in Saudi Arabia and the UAE.
So, only about 10% of the oil supply is missing.
But was the entire supply in the rest of the world completely without any slack? Everything was running at capacity, with zero capacity to increase deliveries? I doubt that. Let's split the 10% supply reduction into 5% that the rest of the world can provide, incentivized by the higher prices, and 5% demand destruction, incentivized by the same higher prices.
The rule of thumb in the oil markets is that a 1% reduction in supply results in a 10% increase in price. So a 5% reduction in supply should result in a 50% increase in price. We are there, actually a bit higher. Brent was trading at about $65 until February 2026, and now it's at $120. That's more than 80% higher. All these numbers have high uncertainly bars, of course, but so far it looks to me that the market is not reacting in a patently irrational way to the events.
> About 20% of the crude oil and natural gas used to come via the Strait of Hormuz.
20% of the world's oil production. But only half is sold on the international market, the rest is used domestically. So roughly 40% of the world's purchasable oil comes through the Strait.
And now we're much less reliant on oil, and more countries produce it and have reserves. The flip side is the economy and financial system already felt creaky anyway (tariffs, inflation, job market, government shutdowns, private credit, AI, etc.), so net net things may be just as bad or worse.
Even 10% is a massive number. Most oil demand is fairly inelastic. You have to get to work no matter the price of gasoline. You might turn your furnastat down a degree, but that's about it. Groceries need to get delivered no matter the price of diesel. Farmers need to fill their tractors no matter the cost. Plastic and industrial demand is fairly inelastic. The price doesn't need to go up by much to reduce demand by 1%. But to reduce demand by 10% involves massive price increases. Only a fraction of gasoline demand is truly elastic. So that 10% reduction in supply might require halving the elastic demand for oil.
Yes but the point was that supply is very elastic since what happens to old fields is that they get priced out. When an oilfield gets older it's production cost creeps up, slowly. Since most of the oilfields that can produce at $current_price + 5$ aren't even properly shutdown yet, they can be rapidly brought online if prices rise, and there's a large supply of such fields. A very large supply of them.
Nobody's going without oil, it's just pushing up inflation. Not saying that's not a problem, but the problem isn't that people are being forced to go without.
Of course EU countries are complaining to high heaven since increased inflation will push their borrowing cost up further, and given the state of their public finances this means more sacrifices. If I lived in Paris, I'd park my car indoors for a month or two. Or 100km outside of Paris.
> But was the entire supply in the rest of the world completely without any slack? Everything was running at capacity, with zero capacity to increase deliveries?
I'm trying to find some numbers here and failing utterly (thanks AI for utterly ruining search). But my recollection from when I've seen it discussed in the past is that the vast majority of slack oil production is in the OPEC countries--essentially everybody not in OPEC produces every drop they can--and even of that, the really big source of slack is Saudi Arabia. You know, all of the places that are currently unable to ship any oil because of the closure of the Strait of Hormuz.
aiui most plastics in the US for this comes from the ethylene byproducts of natural gas/fracking.
Although it would be unironically fantastic if we could hard wean ourselves off plastics and go back to reusable glass jugs. If I could bring my growler to Kroger for milk and cream I'd be a happy camper
The cruel irony here is that this really won't affect the US at all. Europe and Asia will feel the brunt of it, and they seem completely uninterested in working toward a solution.
Why wouldn’t that affect the US? Isn’t the price of oil global? It’s not like US oil will be sold for cheaper to the local population, if that would be the case the incentive would be to export at the higher price instead, no?
If you look at gas prices in Saudi Arabia, some of it is subsidised to be lower but clearly its much cheaper to be consuming your own energy vs purchasing it internationally for a variety of reasons. The size of the effect is a messy economics question, not a black and white thing.
Weird that this was flagged dead in 2 hours? HN is really on a propaganda narrative shaping kick with the flagged dead.
ramesh31 2 hours ago [dead] | root | parent | prev | next [–]
>"Why wouldn’t that affect the US? Isn’t the price of oil global? It’s not like US oil will be sold for cheaper to the local population, if that would be the case the incentive would be to export at the higher price instead, no?"
Sure, oil is a global commodity, but "global price" doesn't mean uniform impact. The US has been a net petroleum exporter since 2020 and produces ~13M bpd domestically. WTI consistently trades at a discount to Brent, often 10%+. Gulf Coast refineries are configured for the heavy/sour crude we get from Canada and our own shale, not the Gulf-state light/sweet that's at risk here. We also produce all of our own natural gas, have some of the lowest domestic prices in the world (Permian gas has literally gone negative in the past due to oversupply), and a huge amount of our energy infrastructure is set up for it (LNG is a whole other category that is far more expensive than regular gas delivery).
Compare that to Europe, which lost its Russian pipeline supply, has minimal domestic production, and is heavily dependent on LNG and Middle East crude routed through exactly the chokepoints in question. Or Japan/South Korea, which import ~90%+ of their oil and a huge chunk transits Hormuz.
Yes, the US sees secondary inflation effects, diesel feeds into everything, jet fuel into airfares, etc. I'm not saying zero impact. But "large scale inflation" comparable to what the EU is about to eat? No. The structural insulation is real, and it's why the US can posture militarily without the same domestic economic gun to its head that Europeans are faced with.
I'm not American. But couldn't this being held due to the mid terms? It already looks bad as is, but if inflation started escalating immediately with the conflict (or more than it is) wouldn't it make it for for electoral purposes?
There's a limit to what we can do. Things were kind of stable before Trump went in bombing everything and I guess we a hoping he'll calm down and things can go on. There isn't an easy military solution to opening the straits it's hard to do diplomatic stuff with Trump issuing some new threat every 24 hours or so.
The thing is that change tracking and sometimes even full-on version control are actually integrated with a lot of the tools that people use, like your document editor. The incremental benefit of git then would largely not be automatic version tracking but only the interactive history browsing which git itself is kinda meh at (and is of questionable value for a lot of workflows). And the cost of this transition is forcing people to use a different tool from their regular workflow, one that wants to be used in an environment they're not comfortable in, and also one that is not conducive to handling anything other than plain text.
Rather, programmers should learn from how other software handles version control and incorporate those ideas into git instead. For example, perhaps we should automatically create a commit every time we build the project so that we can roll back or forward to previous builds and not rely on the programmer to remember to make commits so frequently.
> every operation that has a NaN as an operand produces a NaN as a result.
That's not true. The minimum/maximum functions (fmin and fminimum_num variants, but not the fminimum one) treat NaN inputs as not-present, so return the non-NaN value if there is one. Similarly, hypot also treats NaN inputs as not-present. pow and compoundn will ignore NaN exponents if the base is 1.
I may be misremembering my source (an interview with the 8087 architect lead), but I want to say the die yield on the 8087 was like 30%... just barely feasible for Intel to actually make.
The original 8087 had low yields not only because it had a greater area, but also because it was made with a special technology that was used in few other devices (VMOS), so it was more complex and there was less manufacturing experience with it than with the technology used to make 8086 (HMOS).
Later revisions of 8087 used a standard technology and a shrunk die, with improved yields.
> I am sure people said the same 100 years back when they probably thought living beyond say 60 was too much.
At least in Western cultures, 70 was long considered the "natural" lifespan for humans. E.g., Dante's Divine Comedy takes place when the main character is at the literal midpoint of his life, 35.
> Great, have they increased by as much as inflation?
Yes, real wages have been on the rise for the past few years. With the exception of the somewhat artificial COVID peak, median real wages are the highest on record: https://fred.stlouisfed.org/series/LES1252881600Q
> Yes, it's nice that computers and phones are super cheap and powerful.
It was nice, but that's quickly changing now that the consumer market is being ignored by chip makers who'd rather sell to companies building data centers
Necessary stuff (houses, healthcare, education) have outpaced CPI, and generally it is becoming more expensive.
Unnecessary stuff (electronics, appliances, other tech) did not, and generally it is becoming cheaper (Planned obsolescence is another topic though...)
Unfortunately this is using BLS data that captures largely urban areas and fails to account for a large and quickly growing segment of the workforce that also tend to be lower earners - self-employment (eg uber drivers, doordash, gig working, contractors). This is definitely an over-estimate of real wages, a best case scenario of sorts.
With the backdrop of it coming from the organization that is supposedly supposed to be managing inflation... :P
Wow wages barely rising after 60 years of wage suppression, the wealth is truly trickling down now! Just ignore that the top 1% stole $50 trillion from the bottom 90%:
> the driver has enough expertise to know what his personal limit ought to be
It is actually somewhat amusing that you worded this as "ought to be" rather than "is". Because one of the big problems with most drivers is they have an overly inflated idea of how competent they are at driving (I am not so churlish as to exclude myself from the category). And our system does nothing to bring drivers' beliefs about their capabilities in line with their actual capabilities--drivers are tested generally once on their competence [1], and that pass result then gets to hold for several decades, physical or mental decline notwithstanding.
> I settle for a middle position, which is that the speed limit should be no less than 35 mph on most streets
Most residential streets are not safe to travel at 25 mph, let alone 35 mph. There's a line of parked cars in the shoulders, children playing in the driveways, sidewalks, and street? Yeah, if you're traveling 35 mph, you've got no hope of stopping in time (recall that stopping distance goes to the square of speed).
> Moreover, I think that all pedestrian collisions, no matter how small, must be investigated thoroughly, with a hard action taken to minimize such an incident.
We already know how to minimize collisions. The top 3 actions to take are a) reduce speed limits, b) redesign roads to be narrower to make drivers less comfortable traveling at speed, and c) ban right turns on red.
> Bicyclists must be mandated to wear light-colored high-visibility clothing, reflective gear, and a helmet, otherwise their bicycle should be confiscated.
Why? It's not like wildlife like bears, moose, or deer that wander onto the roads wear such gear, and a "mature highly-attentive driver" should be equally aware of such dangers.
[1] And to be honest, even that is somewhat generous a statement.
Speed limits below 30 are lazy copouts by lazy people that have for decades come in the way of instituting proper safety systems that don't require lowering the speed. Making roads narrow is worse; it is simply horrific. Extending your depraved logic, disallowing cars on the road would work even better. Your metric is one-sided in that it accounts for wanting pedestrian safety but not driver utility.
If you actually begin to use your head, there are other ways to lower collisions:
1. Make roads and lanes substantially wider. This allows pedestrians to be seen from the edges before they come in the front of a car.
2. Shoulder parking is a pathetic substitute for a absence of multilevel parking lots, so these lots should be constructed and used. The shoulder parking should be eliminated as it is very detrimental to pedestrian visibility.
3. There should be well-maintened painted crosswalks, with a walk button that actually works, also with dynamic traffic lights to go with them. These exist at some places in NYC. No-stair bridges also work if they stay maintained.
WebPKI is derived from X.509, but I don't think X.509 lives on anymore. X.500 was stripped down to form LDAP, which is still in very heavy use today. There's still some X.400 systems in existence. I think some of the early cellphone generations may have used the ITU standards in the physical layer?
Of course, the biggest--and weirdest--success of the ITU standards is that the OSI model is still frequently the way networking stacks are described in educational materials, despite the fact that it bears no relation to how any of the networking stack was developed or is used. If you really dig into how the OSI model is supposed to work, one of the layers described only matters for teletypes--which were are a dying, if not dead, technology when the model was developed in the first place.
X.509 absolutely lives on -- https://www.itu.int/rec/t-rec-x.509 last update was October 2024. However WebPKI uses PKIX which is fairly stubbornly stuck on RFC5280.
On the ITU side, they have made improvements including allowing a plain fully qualified domain name as the subject of a certificate, as an alternative to sequence of set of attributes.
No, LDAP was a student project from UMich that somehow gained mindshare because (a) it wasn't ISO, and (b) it cleverly had an 'L' in front of it. It's now more complex and heavyweight than the original DAP, but people think it isn't because of that original clever bit of marketing.
That's certainly possible, you can get a basic implementation that uses it as a database lookup, "search" with baseObject/scope fixed, filter is your search string, return the attribute you want, done without too much effort. In fact a number of early LDAP databases were actually DBMSes underneath, so you take your SQL-style query (select emailAddress where name = "John Doe"), convert it into baseObject/scope/filter/attributes and send it over the wire, the other side converts it back into an SQL query and queries the Ingres database that's doing the actual work, and everyone gets to pat themselves on the back over how well "a bunch of networking types reinventing 1960s database technology" (Marshall Rose, I think) works.
However when you need to implement the whole HDAP protocol, that's when you wish you'd taken up some easier job, like maintaining the bank's COBOL accounting code.
If you mean the presentation layer, hard disagree. Not thinking about presentation creates problems. For example, Go treating ASCII headers as UTF-8 caused trouble. Only slightly not worrying about an HTTP/2 vs HTTP/1.1 mismatch caused trouble for reverse proxies.
Now I'm young enough not to have seen teletypes in an actual production use setting, but I've never heard anyone suggesting the presentation layer was for teletypes. That's just Google-level FUD.
You're allowed to access any type via a char buffer. But the converse is not true (quoting https://eel.is/c++draft/expr#basic.lval-11):
> An object of dynamic type Tobj is type-accessible through a glvalue of type Tref if Tref is similar ([conv.qual]) to: Tobj, a type that is the signed or unsigned type corresponding to Tobj, or a char, unsigned char, or std :: byte type. If a program attempts to access ([defns.access]) the stored value of an object through a glvalue through which it is not type-accessible, the behavior is undefined.
The dynamic type of a char buffer is, well, a char buffer, and can only be accessed via things that are the same type as a char buffer up to signedness and cv-qualification. The actual strict aliasing rules are not commutative!
reply