u/CosmicExplorer

I get your point but arbitrary prints are a bad example since Haskell has Debug.Trace!

Interesting. I never really learned about how the GC works, though I've seen the nursery mentioned before. Still, it is far from ideal if I may go by the last time I benchmarked the algorithm.

My "favorite" one of this genre is that the mergesort is memory inefficient (about n log(n) more nodes allocated than necessary), because the runtime allocates new nodes when you swap them, rather than just altering the pointers in the existing nodes. (This is exactly the kind of impure trickery that is supposed to happen behind the scenes in a functional language.) The result is that the quintessential functional sort is worse in the quintessential functional language than in C.

At my job in the early 1980s the fortran guys decided to learn C. To keep table columns nicely aligned, one guy put leading zeros in front of his decimal constants. He was shocked to see what a statement like int a = 0000123 did.

In the MS-DOS era, non-Unix systems that used a bare carriage return as a newline were more common than non-Unix systems that treated a linefeed in such fashion. Consequently, many programs including Turbo C would accept text files where newlines were indicated as bare carriage returns, but choke on files where they were indicated with bare linefeeds. It should be simple to write a program that will open a file in binary mode for reading and another for writing, reach each byte of the former, and implement a simple state machine that would ignore any carriage return that followed a linefeed that was not ignored, or any line feed that followed a carriage return that was not ignored, output a CR+LF pair for any linefeed or carriage return that was not ignored, gobble any byte 0x1A and ignore everything after it, and otherwise pass input data through unmodified. Such a program would convert all of the line endings in a file to MS-DOS format.

If you run HLS I believe it will create a codelens for top-level bindings without a signature that creates a signature with the inferred type

So, maybe I was going to fast with my thoughts/explanations. You just malloc a large amount(essentially an upper limit) of memory a) Quite often, you won't be able to guarantee a upper limit that always hold for all users, therefore there still needs to be some reallocation logic b) Even with with you call "on-demand paging" (mmu page table stub entries, or whatever name fits better), you can't just allocate a few huge arrays that you maybe won't fully use, because the OS prevents it. Linux has some config knobs regarding that matter, but unless you change it yourself you won't find a no-limits environment. c) And even then, there's still the question how the allocators (kernel and glibc) decides on a virtual memory layout etc.

If we think for a moment about writing assembly and calling syscalls directly: With functions like mmap (mremap etc., the whole group), madvise, faultfd/signalfd, ebpf, etc., ... you're right, actual reallocations (that might include moving the data etc.) can mostly be avoided, and there are many other nice things possible. Where it gets problematic are the language specs of C and C++, that are much more limiting and ambiguous. Like, in a simple case and ignoring the ideas above, surely you know that you can't allocate 10 ints with malloc and the access [12] in that array - it's past the end of the allocation, therefore UB. This is true even if, right after that first array, another allocated array happens to be, with no gap between them. Ie. C happens to define that one malloc call will always give you a single array, that you can legally access from the first to last element (independent of what happens within malloc), but you can't really view two mallocs as mergeable even if the addresses it gave you would make this possible. If you now start doing some syscall magic to make your self-allocated array larger, you're a) firmly outside the C standard (it doesn't even know mmap), b) you have to know how much your C implementation (compiler optimizations, glibc allocator system, ...) will forgive you, or if you're introducing code that might cause problems in some way.

I'm pretty certain that by the time the evolving derivative of B was called C, it recognized "pointer to character" and "pointer to integer" as distinct types, along with "pointer to X" (in which case the symbol identified to a container holding the address of something" versus "array of X" (where a symbol itself would identify the starting address of the array).

If the 1972 compiler is like the 1974 one, structure members behave as though all structure types are in a union with each other. The compiler would need to remember the total size of items for each structure tag, but if the compiler encountered struct foo x; it would need to associate x with the current value of the "next object location", and bump the "next object location" by the size of a struct foo, but once the compiler had reserved space for x it wouldn't need to care about what kind of structure x identified.

This is terrifying.

My city just put up a bunch of these. No public notice, nothing. Just suddenly there's these new poles with weird boxes on them. You just *know* it's some sort of surveillance tech. Super unsettling.

Is this mostly related to their aging population and the costs associated with it, or something else specific? I remember reading about a few demographic time bombs ticking in Europe, Finland often comes up.

It's a 'rare' event, not unprecedented. Weather patterns can get weird. We had a freak snow in May back in '96 here in Romania. Nothing new under the sun.

Honestly, it's not super surprising if you know the history. Bulgaria has strong historical and cultural ties to Russia, going way back. Not everyone there sees Russia as purely antagonistic, despite the war.

It's less about *inviting* them and more about acknowledging their existing and growing economic/geopolitical weight, whether we like it or not. The world's already multipolar, Spain's just pointing out a key player.

Probably just fancy cameras. Relax.