> Flex is one of the commonly used tools as a lexical analyzer. [...]
Bison is a syntax analyzer.
A valid choice; one might also find re2c[1] or Ragel [2] + Lemon[3] a friendlier if less well-established implementation of essentially the same theory. Moving further away, there’s also ANTLR[4] or spending a week on a hand-coded lexer and parser.
> CPU’s parallelism is not utilized in the same way as GPU since different threads are not synchronized at all, there is simply nothing like Warp or Wavefront. [...] SIMD optimization would be a fairly bad fit for shaders since there are no four instances of shader executions at the same time.
See, however, ISPC[5,6] for how attempting to use SIMD (also known as “90% of your CPU’s compute”) does yield wavefronts, etc. (If I’m reading between the lines of the second reference correctly, the work on it paved the way for LLVM-based shader backends in AMD and Intel GPU drivers.)
I’d say that has been true since we started using spectrometers (of all kinds). Those things are preposterously sensitive and pretty damn routine. Nowadays of course there are also other, more narrowly scoped detection methods as well, such as PCR.
PCR/amplification is black magic. I'm also amazed by "no the DNA will be too old" keeps turning out not to be entirely true: People getting out of jail from re-testing evidence 20+ years later, Hominid DNA statements being made from archaic bones..
Animal population studies used to be (in my understanding) largely observational. Now, people can do scat tests and identify individuals.
To be honest, at this point I’d take any group at all willing to usefully and non-hypocritically push for free speech (as a general societal value, not just a US-specific legal notion).
It’s not exclusively an IPv6 feature: RFC 3927 defines link-local IPv4 addresses, to be assigned randomly from 169.254.0.0/16 after a bit of ceremony to detect collisions.
Ideally, you’d be able to connect a PC and a printer with an Ethernet cable, they would both (having failed to find a better alternative) allocate a link-local address for themselves, and then the PC would use DNS-SD over mDNS to discover the printer and show it to you. Similar story with PCs exporting their media files over the network, a—say—set-top box, and a switch they’re all plugged into.
And for some combinations of parts this actually works. It’s just that the functionality is not always well-exposed by the OS, that a switch + DHCP server in a box (in practice, a consumer router) can work just as well with no configuration as an unmanaged switch can, and that people are not that interested in local-only wired networks anymore.
There’s also the “having failed to find a better alternative” part: unlike with IPv6, the RFC does not endorse always assigning a link-local address as the second one next to a static or DHCP-provided one, I’m guessing for software compatibility. Thus you really only see 169.254.* in your interface configuration when DHCP is borked, and it’s kind of useless in that case.
The IPv6 feature isn’t link-local addresses, it’s being able to specify the interface to bind to as part of the address specification. This lets you demand that your IPv6-based tool use your wired Ethernet connection, for example.
> The IPv6 feature isn’t link-local addresses, it’s being able to specify the interface to bind to as part of the address specification. This lets you demand that your IPv6-based tool use your wired Ethernet connection, for example.
I don’t think a design goal of IPv6 was to enable users to demand which link the kernel uses or open up some rich new world of link local ip services. I think it’s more like “because IPv6 hosts assign everything an address all at once, there’s a new problem when two interfaces use the same link local addresses since we can’t guarantee uniqueness so we have to invent this stupid zone_id convention to work around poor protocol design and implementation”. Design goals are different than constraints.
Have hosts put a guid in its LL address and print that on the sticker next to the mac address… idk. Actually it’d be nice if we only did link-exclusive things at the link layer, eh?
Yes, but the question is, "what if an address in this range is assigned to _two_ interfaces at the same time?" Now your local routing information base cannot distinguish which interface to use when trying to reach other hosts in that same network. So, it's fair to say, it's not a feature even available in IPv4.
The second difference is IPv6 is almost always going to have link local addresses assigned and machines with multiple network interfaces are the norm rather than the exception.
I literally had to interrogate an LLM to explain what this was about, because to me, indeed, when I see 169.254 I think "Ah, someone unplugged something critical and the network is now completely down." I didn't even know that in ipv6 land there are any reasons to use link-local addresses for anything. I mean, there still basically isn't a reason for 99.99% of people, I think. But it's interesting.
I also didn't realize that part of the idea behind these LL things was one of the rounds of wishful networking ideas of the 90s or 2000s, kind of a cousin of UPnP and mDNS in that way (in increasing order of eventual usefulness).
Considered completely in a vacuum, especially ignoring the WAN, I can see how it seemed silly that if you plugged three computers and a printer into a switch, rolling random IP addresses like this could have allowed things to be discoverable and to function locally (I thought mDNS or "Bonjour"/"Rendezvous" as Apple called it came much later, but I know my PCs could "see" each other with NetBIOS or whatever long before mDNS was invented).
Link-local addresses (LLAs) are needed in IPv6 because IPv6 doesn't have broadcast. IPv6 uses multicast instead.
Broadcasts go to all IPv4 addresses in the subnet, multicasts only go to those who subscribed to a multicast group. To subscribe to a IPv6 multicast group you need an IPv6 address. So all IPv6 interfaces will have at least one LLA self-generated.
One thing that IPv6 uses multicast heavily for is NDP, which is the IPv6 version of ARP. This is how IP addresses on your LAN/WLAN are converted to MAC addresses which is required info for the NIC in your node to talk to another node on your Ethernet LAN/WLAN.
End users don't typically have to use LLAs directly but you can use them if you want to 100% ensure things won't leave your LAN as routers don't forward LLAs.
mDNS on link-locals is what makes the "plug computers and printers into switch" case work. It would have been NetBIOS originally but mDNS is how it's done today.
Pedantically, yes VLAs are a mandatory part of C99 (only). Practically, there has been some resistance so they were reverted to optional in later standards (in C11/17, the whole thing is optional; in C23, variably modified array types are mandatory but the ability to allocate arrays of such types on the stack is not). In any case, MSVC is quite a bad benchmark as far as C (not C++) standards conformance goes—it’s been quite some time since Sutter’s (in)famous post[1] and things have improved, but not to the point that I’d believe C to be a priority for Microsoft.
(Note MSVC has alloca—and Microsoft’s own libraries in the past have done unwise things with it—so the safety argument for the lack of support does not fly.
I’ve thrown all my projects i have written in c for posix systems in the last 15 years against msvc and had only one project which had an issue. Because a dep used VLAs.
As far as I have been told, they were not made optional because of any issues with VLAs (which exist also in many other languages, including Ada) but because adoption of C99 was slow, so some parts were made optional in C11. Later VLAs were criticized for enabling stack clashing attacks that jump the guard page, but this also sometimes possible without VLAs and the real fix for this was compilers implementing stack probing. It is still bad when attacks control the size which should be avoided (and there is -Wvla-larger-than=)
> CPU processing of denormals tends to be extremely slow - I vaguely recall running into something like a 10x slowdown a decade ago
Intel CPU processing, where slowdowns can be as bad as couple hundred cycles. AMD CPUs penalize them much more mildly, usually single-digit cycles. (No idea about ARM.)
On the other hand, they (unexpectedly to the inventor, who intended them to be a debugging tool) underpin a few foundational results in correctly rounded computation, such as https://en.wikipedia.org/wiki/Sterbenz_lemma.
Not quite. As GP mentions, a[i][j] might mean either, depending on what the type of a is:
(a) If the type of a is “array of length N of pointer to (say) char” (declaration: char *a[N]), then a[i][j] means the jth char in the contiguous block pointed to by the ith pointer. In C#, this is what you get with an array of arrays.
(b) If the type of a is “array of length N of array of length M of char” (declaration: char a[N][M] — sic!), then a[i][j] means the jth element of the ith element, aka the (i*M+j)th char in the single contiguous memory block. In C#, this is what you get with a two-dimensional array.
The way this happens is a bit subtle:
(a) The value a, of type “array of size N of pointer to char”, first decays into “pointer to pointer to char”, then a[i] retrieves the ith “pointer to char” starting from it as a base, then in turn a[i][j] retrieves the jth “char” starting from that as a base.
(b) The value a, of type “array of length N of array of length M of char”, first decays into “pointer to array of length M of char” (sic!), then a[i] retrieves the ith “array of length M of char” starting from it as a base, which then decays into “pointer to char”, then a[i][j] retrieves the jth “char” starting from that as a base.
NB: There are no implicit references here, unlike in C#; in part (b), a is an N*M-byte chunk of memory and a[i] is an M-byte piece of it.
A valid choice; one might also find re2c[1] or Ragel [2] + Lemon[3] a friendlier if less well-established implementation of essentially the same theory. Moving further away, there’s also ANTLR[4] or spending a week on a hand-coded lexer and parser.
> CPU’s parallelism is not utilized in the same way as GPU since different threads are not synchronized at all, there is simply nothing like Warp or Wavefront. [...] SIMD optimization would be a fairly bad fit for shaders since there are no four instances of shader executions at the same time.
See, however, ISPC[5,6] for how attempting to use SIMD (also known as “90% of your CPU’s compute”) does yield wavefronts, etc. (If I’m reading between the lines of the second reference correctly, the work on it paved the way for LLVM-based shader backends in AMD and Intel GPU drivers.)
[1] https://re2c.org/
[2] https://www.colm.net/open-source/ragel/
[3] https://sqlite.org/src/doc/trunk/doc/lemon.html
[4] https://www.antlr.org/
[5] https://ispc.github.io/
[6] https://pharr.org/matt/blog/2018/04/18/ispc-origins
reply