The limitations were brutal. Initially you could only have 255 bytes in a string. The length of a string and the size of the allocation are now separate and you may need to think about that unused memory in your design. The problem now doubles with the introduction of UTF-8. Your string size is in bytes and you need to track characters separately.
If you want to create an array of strings you either need to specify the length of all strings and accept the memory overhead or have an array of pointers to strings. If you use an array of pointers you may end up choosing to use the 'nil' value as a sentinel that means "end of list." So we're right back where we started.
--
Because someone decided to downvote this HN has limited the speed at which I can reply. This site is tragic and I'm fully done with it now. You can spread propaganda and poorly sourced zeitgeist and be among friends but if you try to have a genuine conversation about programming languages you are made to be unwelcome immediately. Screw this.
--
> No other data structure works like this.
The linked list.
> You can't mess this up in an array
C happily decomposes arrays into pointers. You can erase your length information from the type. This was an intentional decision.
> Strings are the only data structure that assume there will be a NULL at end.
Which is why almost every string API has a version that allows you to specify the maximum length. The fact that you can use a NUL doesn't mean you have to. Which is why the concept of "sentinel values" is broadly used in many types of applications you haven't considered here.
> You can spread propaganda and poorly sourced zeitgeist and be among friends but if you try to have a genuine conversation about programming languages you are made to be unwelcome immediately.
Indeed. And the ignorance of computing history in this discussion is particularly disturbing.
The context of this particular thread is "zero terminated string is ... computing's biggest mistake". This completely ignores the situation on the ground when C was developed. At the time, people were striving for a system programming language that sat above the level of assembly but was compact enough to run within the limited resources of the then emerging mini-computer systems. The PDP-11 on which C was developed was certainly not the first mini-computer, but it was among the earliest to have a regular enough instruction set and addressing model to make a general purpose, high-level system's language possible. These systems were extremely limited in memory; the PDP-11's instruction set is limited to directly addressing at most 64KiB (code and data) and many systems of the era were hardware limited to less than that. (Indeed, I regularly run an early version of Unix, including an early C compiler, on my PDP-11/05 which is maxed out at 56KiB [of actual core]). There was no way that even a brilliant engineer like Dennis Richie was going to be able to shoe-horn in "optional" types, or the mechanics of length-value strings into a compiler that has to run in such limited space, and produce code (e.g. the Unix kernel) that has to run in even less. The fact that strings and arrays are thin abstractions on top of pointers is both a brilliant compromise in design as well as a nod to then-prevalent assembly practice. It was the exactly kind of pragmatic decision that was needed to move computing along at the time. Of course the designs from this era are antiquated now. But they were not mistakes.
> This completely ignores the situation on the ground when C was developed.
A great many of those replying are many years short of having experienced anything like "the situation on the ground when C was developed". They simply have never known a day without hundreds of gigabytes or more of disk storage and 8G or more of RAM available for user processes after the OS consumes what it needs for its own work. They are "ignoring" because they simply have no basis for understanding.
All those limitations were sorted out in 1978 with Modula-2 and open arrays, aka spans.
What about the UNIX and C folks propaganda of C being the first systems language, or always focusing on the original Pascal used for teaching and not everything else that followed up with Mesa, Modula-2, Ada, Object Pascal and friends, none of them with said limitations.
Successful systems languages trace back all the way to JOVIAL in 1958.
You missed quite a few between JOVIAL, and C being adopted outside Bell Labs.
Modula-2 was as widely available as C was outside UNIX and universities with access to UNIX source code.
It took a while for proper C to actually be "used for everything else", until the early 1990s actually, and by then anyone sensible would be much better with Typescript for C, aka C++.
I dunno, I was starting my career around 1980-81, and the choices were 6502/6509/Z80/8088 asm, C, UCSD-Pascal, and BASIC at the micro level, C/asm was the rule for RT-11/RSX-11 and then the VAX OSs at the "minicomputer" level.
I had a friend that tried to get everyone using Modula-2 but the "ecosystem" wasn't as great around the uni/ex-uni environments where I was.
C was pretty entrenched by the end of the 1980s, although I did use a weird embedded Pascal that was on HP-UX cross-compiling for Z80/8086 at the end of the decade, but they were the exception rather than the rule.
C++ was just a preprocessor for C and a "better C" at the time, people were still bitching about header files with function type signatures of "ANSI C" vs "good old-fashioned K&R".
Alone the fact that you mention RT-11/RSX-11 and VAX OSs shows we were not on the same bubble.
Anyway on VMS most folks would be found using the VMS BASIC compiler, VMS Pascal or Bliss, until Open VMS made it yet another UNIX clone.
My first C compiler used the RatC dialect, let alone having access to a proper K&R C compiler.
By 1992, I already had access to a proper C++ compiler on MS-DOS, and C was history to me, other than scenarios were work was expected to be done in C like some university assignments, even here we were blessed with a plethora of languages between Lisp, Prolog, Smalltalk, ML, C, C++,....
My bubble was obviously technically superior to your bubble. :)
And maybe it was 5/10 years earlier? Not sure. My uni days were the very early 1980s. Our university literally still made 1st years use marked sense (not even punch) cards.
I never ever liked C++, it always seemed to be tacked on to the side of C (literally at the start).
I liked the "better C" bits, but the "++" bits and the magic under the covers and then later the added layer of templates just seemed ridiculously complicated especially because we were still in the days of inheritance and "is-a" instead of "has-a" objects.
I loathed all the overloading that suddenly << meant something completely different when doing I/O and weird multiple function definitions to provide the generics.
Much preferred the Objective C idea of messages, was much more what I understood OOP to be after Smalltalk.
But by then I'd made the leap to being an "architect" and got to pontificate from on high and languages became semi-irrelevant.
You mean "C with Classes", later to be replaced by "C++" (Stroustrup pick this as favorite from a list of candidate names he crowdsourced) as implemented by Cfront.
>The problem now doubles with the introduction of UTF-8. Your string size is in bytes and you need to track characters separately.
That isn't really a problem.
The problem with null-terminated strings is specifically what happens when you reach the end of the allocated array and there ISN'T a NULL character.
Every string function is designed to keep going until it finds the NULL character, so if a hacker gets rid of the NULL character, he can exploit pretty much any standard string manipulation function being used elsewhere in the program to manipulate whatever memory comes AFTER the string data structure.
No other data structure works like this. You can't mess this up in an array, because no function that manipulates arrays is just going to keep going until there is a null. That would be stupid because it would require users of the function to add a NULL to the end of their arrays before passing it to the function, so instead we just pass the size of the array to everything. Strings are the only data structure that assume there will be a NULL at end.
By the way, I read once that if you use UTF-32 every code point will be 4 bytes, constantly, but even then a single code point isn't necessarily a single character. Text is just complicated.
In C most data structures work like this, you keep going until you find NUL (character) or NULL (pointer). E.g. Strings, array of pointers, linked lists, etc. Of course you can add length to most of those, but it isn't the canonical/traditional way of doing things.
That can't be true. If you have an array of pointers it can be terminated in NULL. But an array of integers can't have a NULL value, since NULL would probably be just 0 which is a normal integer.
The null in a linked list is the null in the .next field, right? That's the way you would implemented linked lists independent of language. It's not the .value that is null.
A string is an array of characters (well, for characters representable in one byte at least) that has a specific value to represent the end of string.
It would be like if Int::MAX was reduced by 1 to make space for an Int:NUL constant that represented the end of an integer array. Or if you were creating your own ENUM, let's say for NORTH, SOUTH, EAST, WEST, and you added a fifth enumeration called Direction.NUL for use in arrays.
With an variable length array of structs, you can set all the fields all to 0 at the cost of an extra member at the end. In the cases where this is, the structures are such that (either intentionally or by consequence) something with all fields zero is outside of the function's domain
> No other data structure works like this. You can't mess this up in an array, because no function that manipulates arrays is just going to keep going until there is a null.
This is patently false. Sentinel markers are used widely in array types. Consider GNU's getopt_long() function, a mainstay in GNU tools:
The argument longopts must be an array of [struct option] structures, one for each long option. Terminate the array with an element containing all zeros.
> Every string function is designed to keep going until it finds the NULL character, so if a hacker gets rid of the NULL character,
What sort of situation are you envisioning where a hacker can remove the sentinel (in the case of nul-termination) but not modify the length bytes (in the case of fat pointers)?
A situation in which a string is manipulated with buggy code that can remove the sentinel, e.g. the program uses strncpy, there is a bug in how it uses it, the hacker exploits the bug.
By contrast it's pretty unlikely for buggy code to mess the length. Add an element? +1. Remove an element? -1. Number of elements larger than capacity? Allocate a new array. Not much room for error.
If I zero out the destination buffer of a strcpy, and the string is longer than the destination buffer I will run into a buffer overflow problem despite every byte being a zero byte. The absence or presence of the zero byte doesn't seem to be the deciding factor.
That's one of the problems with the lack of diplomacy in the US's position for the past 40 years. We have pushed the envelope beyond our own control:
"The U.S. military reverse-engineered Iran’s Shahed-136 loitering munition to create a low-cost, one-way attack drone squadron in the Middle East called LUCAS (Low-Cost Unmanned Combat Attack System)."
Necessity is the mother of invention. We spent billions in exchange for making our "enemies" stronger. We really are a ridiculous nation.
They're falling back to the C/A (coarse, civilian) signal. Part of the attack is to drown out the frequency where the P (fine, military) signal is so they can more easily attack the civilian signal.
There's another frequency they could be using that is higher power but hasn't been put into production yet.
I don't understand how "spoof-to" works. If you have to mimic a satellite then isn't everyone going to get a different location? Unless you're tracking a specific target how can you intentionally spoof them to a desired location? I'd assume the best you could do is create a fixed offset.
> The military wants to go mostly inertial and is working on better inertial systems.
Given the drift rate this is an idea for munitions but exceptionally difficult to actually operate in a vehicle.
Because the clocks internal to GNSS receivers are not that accurate, if they're not at the "targeted" location they'll see that all satellites are off by a given time offset, and think that their clock is just off by that much.
The problem with that is if you turn off power to the aircraft then the IMU no longer maintains state and you will need to realign it on startup. The procedures for this are broadly incompatible with military missions.
> that you can't actually reproduce with the software
If the vendors of that software are not aware of the failure mode then they may accidentally introduce it by later code changes. Systems evolve. Blind evolution leads to pernicious and widespread failures.
You should possibly spend some time reading what people used to say about the invention of Radio and Television.
> It is quite extraordinary and breath-taking at times to see the agents in action;
So is any magic trick. The unsettling notion that it may all just be an illusion that you've failed to correctly understand doesn't seem to weigh on people.
> its almost hard-drug like in its potential long-term psychological effects.
That might have more to do with how the owners of these products choose to market and deploy them. Perhaps if they peeled back the covers just slightly your euphoria would change to dread. There's an Upton Sinclair moment coming.
"They will cease to exercise memory because they rely on that which is written, calling things to remembrance no longer from within themselves, but by means of external marks"
And he was right, that is why we don't let people bring their textbooks to most tests. That rule wasn't made because we hate students, its because it improves the outcomes if we force people to commit things to memory instead of just looking them up.
You would need similar restrictions during the learning phase to get people to learn things in an LLM world.
So writing and LLM are still a net positive, but only if you acknowledge the problem and add fixes so people still learn rather than just rely on this crutch.
> Or are AIs fundamentally different, and if so, why?
Literally: the context window.
With the human you have a window that possibly extends up to _years_. With your language model you have maybe a few megabytes which is always preceded by instructions from the model maker.
That's a misconception. Context window of humans is measured in seconds and limited to single-digit amount of entities. Human attention is truly ephemeral, with a ridiculously short span. What you're talking about cannot be emulated by putting everything into the context, you need models with deeper cognitive capabilities, and the longer your context the smarter it needs to be. It can be done by increasing the depth and the size of the model, and by training it better. Test-time scaling does work (longer reasoning, agentic compression, ICL, etc), but hits the wall rather quickly if not assisted by better cognition.
That's a simple neurologic fact, there's nothing to believe. You can use a trivial experiment to verify that you can't keep details in your sliding attention window for more than a few seconds or focus on more than a few things simultaneously. Human memory and cognition is layered and this immediate layer is what resembles the model's context the most.
You're possibly mixing it up with long-term memory which doesn't keep immediate facts and details, it's for heavily processed and compressed summaries, for the lack of a better analogy from the LLM world. You aren't keeping the entire codebase in your memory, just its highly processed and conceptualized version. This conceptualization can be somewhat emulated as an agentic loop, but it can only go so far, current models quickly lose coherency and aren't good enough to predict what's important.
Models don't need to remember more details, they need stronger processing of what they already remember.
>"Oh yea, just do it _better_. That's your problem."
I think we're talking about different things. Models can be trained better to cram more intelligence into the same amount of parameters, that's what I mean. Similarly to how your ability to learn (and perform) math depends on your prior math training.
> You can use a trivial experiment to verify that you can't keep details in your sliding attention window for more than a few seconds or focus on more than a few things simultaneously.
I said "context window" not "attention window." Of course spans of attention are limited. Knowledge is not. Knowledge is often highly specific.
> You're possibly mixing it up
Not really. You've simply failed to verify your understanding of my argument and instead created something of a strawman.
> You aren't keeping the entire codebase in your memory, just its highly processed and conceptualized version
And what is your basis for this claim? Why a codebase? You don't think I can't remember an entire function? Yet actors can remember entire sets of lines for a scene? Is that just a highly processed and abstracted version in their minds? And they just run some cognitive loop to recreate dialog in real time?
> they need stronger processing of what they already remember.
What is "stronger?" More time? More memory? More compute? And how is that put to use? Why is it, when given certain prompts, that LLMs reproduce 100s of pages of directly copied and copyrighted work?
> Models can be trained better to cram more intelligence into the same amount of parameters, that's what I mean.
Cool. _How_? What is the limit of this training? How efficient is it? How many resources do you need on the input for a given increase in output? Otherwise it's just a ton of hand waving going on here.
If there's an actual neurological attention window that you're referring to, that's as ephemeral as you say, it is not analogous to the context window of an LLM.
When I'm working on a problem, I can explicitly apply knowledge I gained decades ago to that problem. Not just "oh, it's somehow encoded in the training data"; not "oh, it's all mixed in there somewhere"; I can call up the memories, understand how to apply that knowledge to the problem at hand, and do so.
Except in certain very superficial ways, and despite many misguided LLM proponents' strident insistence to the contrary, LLMs do not work much like human brains.
Yes, that's my entire point and I'm well aware about LLM internals. Reread the comment above, I'm responding to a person who suggested to increase the context window of an LLM to make it less different, saying it will never work.
Is this true, though? AIs already interact with way more data than their context window, they can make queries to external data sources, and they can make context references to external data that can be pulled in as needed.
The context window is the working memory, which is not ‘years’ for humans either.
https://en.wikipedia.org/wiki/Teratoma