Notices by Alexander Monakov (amonakov@mastodon.gamedev.place)

@wolf480pl apparently so! (better link: https://elixir.bootlin.com/linux/v6.17.1/source/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c#L464 )

fishing out an old HDMI spec should allow to confirm this redditor's claim:

> Interesting note the original HDMI spec had a HDMI-B connector for a HDMI dual link version (think oversized normal HDMI connector). It was never implemented by anyone and i believe abandoned by HDMI 1.3.

https://old.reddit.com/r/Monitors/comments/v3mxme/does_hdmi_to_dvi_dual_link_exist/iazw19w/

@wolf480pl oh, in fact, Wikipedia covers this topic pretty well: https://en.wikipedia.org/wiki/HDMI#Connectors

@wolf480pl I think it shouldn't be that bad? On my old laptop power_save is disabled by default, as I recall, due to known issues, on the new laptop I never noticed any problems (and, as I just checked, it is enabled by default).

@wolf480pl yeah, evidently pinging the access point from the laptop (2-4ms) is not the same as pinging the laptop from the AP (1-200ms) unless I run 'ping -i 0.1 AP' on the laptop (or disable power_save). Which seems to imply the power_save timeout is about 100ms in my case, and I randomly get its extra latency when the response doesn't arrive in that time (e.g. ssh'ing to another continent).

@dalias on my phone? I'm afraid not. But apparently filtering or throttling them on the network infra level is a thing.

Looking at why connecting to WiFi has a bigger battery impact in one office building than another, running tcpdump on the wlan interface, and it's endless mDNS chatter, like dozens of packets per second.

@steve @dalias @regehr however I'm pretty sure LLVM attaches the "const" attribute to memcmp, so there's still a contradiction

@regehr who else wouldn't want big paychecks for incorrect translation (you know it's wrong, right? due to embedded assumption how memcmp's return value is produced)

@regehr imagine %1 computed as the result of memcmp with the same %0 and %2 in arguments, but not inlined, so the return value is produced by the library. since memcmp's return value is not fully specified, it is possible that the library computes it differently than what LLVM has inlined. and then %5 can be non-zero, while it must be zero

@ignaloidas @wolf480pl Language committees never concerned themselves with sockets, and we didn't end up with such explosion. We also do not have a multitude of libraries for a simple TLS-wrapped socket abstraction.

I still think that in C and C++ (additions to) standard libraries should be just for things that cannot be properly implemented without coordination with the compiler.

Likewise, "breadth" of the stdlib is not a strength of the language, nor where the main weak points are.

@wolf480pl I'd say they can be a part of a normal library, not something the language committee needs to be concerned with. And how easy it's to write and maintain _is_ a strength of the language.

@dalias I do not see how this relates to [non-]transitivity. What would be the hypothetical third struct that would be compatible with exactly one of pthread_mutex_t and mtx_t?

Generally speaking, do you have an example that illustrates non-transitivity of compatibility relation that does not involve unprototyped function type?

Let's say a C program comprises two translation units, each of which declares the following type:

struct list {
struct list *next;
void *payload;
};

For deciding whether they are compatible, the following clause of the language standard applies:

"there shall be a one-to-one correspondence between their members such that each pair of corresponding members are declared with compatible types;"

Apparently the implementation may claim that such self-referential types are not compatible! 🙃

Now suppose the program contains not two, but three such translation units. Let's say the instances of the struct type are A, B, and C. Can the implementation choose to A be compatible with B, B with C, but C incompatible with A?

@wolf480pl I'm probably missing what you're hinting at, but to me the most "interesting" (but not really) question is what choice an implementation aiming to detect many instances of UB, such as TIS-interpreter, would make.

@icedquinn @wolf480pl I don't think it's academic, checking decoded data is how you catch unintended bugs; floating-point decoding can be reproducible if you know what you're doing

@wolf480pl @icedquinn I can confirm that, both the ffmpeg decoder and reference library use floats; the reference library can be configured to avoid floating-point arithmetic, but that's not the default.

@wolf480pl @icedquinn but even without floating-point, you can get different decodes if your other version of ffmpeg doesn't know about the clever backward-compatible upgrade:

@wolf480pl @icedquinn hm, but on second thought, that is specifically for streaming over networks, and wouldn't be used in conventional encoding?