4 ms·
Up until the early '90s, almost all the different Pascals had a (byte counter, character) string, which meant that if your string was longer than 255 bytes you
by beagle3 8y ago
Up until the early '90s, almost all the different Pascals had a (byte counter, character) string, which meant that if your string was longer than 255 bytes you had to do exactly the same kind of acrobatics that C did, and then some (for various reasons related to Pascal's type system).
Then they added 16-bit strings. And eventually 32-bit strings. Which are useless to keep that 5GB file in memory you process these days. I'm not up-to-date - does pascal have a 64-bit string type?
C, on the other hand, still uses the same error-prone and exploit inducing strcpy, strcat and friends - and the work for those 12GB gene texts and .csv files.
C never looked elegant, but it was extremely effective in the limited memory / limited CPU days of yore, and that's why it won against e.g. Pascal.
- zerr 8y ago> that's why it won against e.g. Pascal. More like AT&T and Unix monopoly?
- pjmlp 8y agoC won because it came with an OS free of charge, with source code.
- tntn 8y agoUnix was neither open source nor free of charge. C won long before Linux came around.
- pjmlp 8y agoSure it was, just not with the FOSS licenses of today, apparently you are too young to remember. AT&T was forbidden to sell UNIX, so they provided the source code to universities at the symbolic price of $100, which was basically free when compared at how much something like VMS or z/OS would cost in licensing. When Linux came into the scene, C was already on its way out, being slowly replaced by C++ on OS/2, Windows, Mac OS, Symbian, BeOS, NewtonOS as the way to go for writing applications. The later three were even written in C++ (Newton also had NewtonScript). In 1994 we were already teaching C++ to first year CS students at my university. Proper C++, following Bjarne's ARM book, already talking about RAII and stronger type checking. It was UNIX FOSS with the assertion that portable software had to be written in C that eventually pushed C everywhere, even to the platforms that were already getting cosy with C++.
- tntn 8y agoThe price may have been symbolic for universities, but AT&T licensed Unix commercially for many tens of thousands of dollars.
- pjmlp 8y agoLearn the history of UNIX, that was almost a decade later, which was when they decided to sue BSD. https://www.johndcook.com/blog/2010/11/16/why-att-licensed-unix-to-universities/ https://www.johndcook.com/blog/2010/11/16/why-att-licensed-u... https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc._v._Berkeley_Software_Design,_Inc https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
- scruffyherder 8y agoIndeed, it was quite fun to see that in order to bootstrap Research Unix v8, you needed 4.1BSD https://virtuallyfun.com/wordpress/2017/03/30/research-unix-v8/ https://virtuallyfun.com/wordpress/2017/03/30/research-unix-...
- dpark 8y agoIs a 5 billion character string really the way you want to read a 5GB file?
- beagle3 8y agoNo, but some people do; And some C programs written 30 years ago do support it, but no Pascal program does (not from 30 years ago, not those written 20 years ago, not those written 10 years ago, and not those written yesterday unless Pascal now has 64-bit length strings). Furthermore, using mmap (which was always the right way to do it), it doesn't matter if it's 512KB or 1GB or 5GB or 20GB, and is supported by C string practices but none of the Pascal strings (or those suggested on this thread).
- dpark 8y agoOn the other hand, the Pascal code that can't handle 5GB strings also doesn't have the same pervasive security risk from buggy string manipulation that C code does. Not a bad tradeoff, especially given that you probably want to work on substrings within that 5GB and slicing in C essentially doesn't work because null termination either doesn't exist for your substrings (making them incorrect and potentially unsafe, depending on what you're doing) or the substring null termination breaks your larger string and prevents it from actually behaving like a 5GB string. Safe string manipulation in C devolves into always passing a char array and a count anyway, which is not coincidentally exactly what Pascal strings look like.
- beagle3 8y agoIndeed safe strings in C are hard to do, but the nul termination is not the end-all-be-all of C strings; indeed, there is often a way to specify maximum string length (e.g. %.#s format in the prints family, strncpy). So mmapped strings are actually useful. The bigger problems is embedded nuls, which can’t easily be sidestepped in the C strong framework. Regardless, C won when the world was not yet well connected, and vulnerabilities mattered much less. It might not have won if the match was held today. The wake up calls were the Morris worm (intentional) and the AT&T outage (unintentional, and more of a logic error iirc) but by then it was too late.
- cornholio 8y ago> I'm not up-to-date - does pascal have a 64-bit string type? Seems like an easy fix is a single type of string with dynamic size depending on the first byte, like UTF-8: 0bbbbbbb : 1 byte header for a string up to 127 bytes long 10bbbbbb + hh : 2 byte header for a string up to 16384 bytes long 110bbbbb + hhhhhh: 4 byte header for a string up to 512 MB long 1110bbbb + hhhhhhhhhhhhhh: 8 byte header for a string up 1.15 EB long ... etc. (so as not to repeat the mistakes of Pascal, who knows how long will 1.15 EB be enough for everybody) You would optimize the functions for the fast path with a single bit test for short <128 byte strings, and end up with a sane, safe string until the end of time. With minimal memory impact and much faster than testing for nul terminators, strlen() all over the place etc.
- samatman 8y agoThis is the intuitively right answer, and has always been my favorite. It's so puzzling that this is a data structure I can't recall ever seeing in the wild.