HNHacker News
TopNewBestAskShowJobs

pikhq

47 karma · joined August 19, 2012

submissionscomments
pikhq··on iOS 26.3 and macOS 26.3 Fix Dozens of Vulnerabilities, Including Zero-Day
I hope they release a version of these fixes on iOS 18 in a form installable on an iPhone 14; I've been trying to stay away from Liquid Glass until it's actually usable. I really don't want to be forced to upgrade, since Apple seems to have replaced UX testing with "just ship it," as has become standard in the industry.
pikhq··on Stack size invisibility in C and the effects on "portability"
This article is a bit strange. It's referring to the thread stack size but acting as though it's the main stack size. It's true there's no portable C API for doing anything with the main stack size, but musl libc doesn't behave any differently than glibc here -- the main stack is allocated by the kernel. The thread stack size on musl is small, yes, but the only way to even end up in a thread involves using the pthread API. The pthread API exposes an API for configuring the stack size for a thread; it's called pthread_attr_setstacksize. You can find it here: https://pubs.opengroup.org/onlinepubs/9699919799/functions/p...

Granted, it is maddening that C does not offer any great ways to reason about what stack size is needed, but it is simply nonsense to imply (as people seem to be inferring here) that there's no way for an application to handle running into musl's stack size limits.

pikhq··on 2016 Retina MacBook Pro Caveats
A given USB Type C cable can be a "USB 2.0" cable, which is only good for USB @ 480 Mbps and power, or a "USB 3.1" cable, which can handle USB @ 10 Gbps and power, as well as alternate data modes like DisplayPort or Thunderbolt. Additionally, it can be only good for 3 A, or it can have a chip in it to indicate it's good for more power (up to 5A).

The Apple-supplied cable is probably a USB 2.0 cable, with a chip indicating it can handle 5A.

pikhq··on Refu: a collection of cross platform programming libraries written in C
The existence of two separate implementations of bubblesort (one for char, one for uint16_t), in and of it self, says everything that needs to be said about this. This was written by someone who refuses to use even the meager facilities C offers programmers, and doesn't know enough about them to even NIH things well. Moreover, he seems to like overtly complex, specialized code over simple, generic code.

(if the author of this library is reading this: qsort is a libc function that can sort an array of any type, in any way, and does so much more efficiently than bubblesort could ever dream, while not being very complex.)