Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux eliminates the strncpy API after six years of work, 360 patches

phoronix.com

Post reply on HN
Print view View original

311–320 of 340 posts

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#311

Post by canucker2016 »

rswail wrote: post #209
flohofwoe wrote: post #199

Earlier quoted context omitted.

> non UTF-8 encoded strings on input/output UTF-8 on stdin/stdout works perfectly fine (unless you are on Windows of course, which is stuck in in the early 90s when it comes to international text encoding). > Using LF or CR or CRLF as line terminators This is also an operating system convention, and it would be better if programming languages wouldn't try to "guess" the correct line endings, since this causes more pr…

No, it was an Apple, Unix, and Microsoft problem. Unix used LF, Apple used CR, Microsoft used CRLF. They are all ASCII carriage movement codes, which is about driving the paper feed and print head of an ASR-33 or equivalent. So they all made the "wrong" decision about what to store in a file. They just chose different wrong characters.

I think PCDOS/MSDOS copied CP/M's use of CRLF for line separator.

Some believe Gary Kildall picked CRLF for CP/M since he used DEC TOPS-10 to develop CP/M. see https://www.quora.com/Why-did-CP-M-stick-with-the-CR-LF-stan...

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#312

Post by rswail »

pjmlp wrote: post #310
rswail wrote: post #205

Earlier quoted context omitted.

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, alt…

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, o…

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 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.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#313

Post by rswail »

pjmlp wrote: post #308
rswail wrote: post #210

Earlier quoted context omitted.

I preferred "P" because of the BCPL ancestor. If BCPL begat "B" and "B" begat "C", then "C" should have begatten "P". Not sure if begatten is a word :)

BCPL is short of Bootstrap CPL, given its initial purpose, the fact it took off on its own was not planned.

Most good ideas never are.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#314

Post by rswail »

lelanthran wrote: post #211
rswail wrote: post #208

Earlier quoted context omitted.

Except that nearly all ISAs treat zero as a special value, with a Z-flag or equivalent for the last ALU result, and conditional branches around that result. PDP-11s, 68Ks, nearly all ISAs that I know about treat zero as special. It falls naturally out of the ALU operations. So why would people writing assembler code use another value unless they had to?

That's my point - they didn't, and used the zero as a sentinel when designing their HLL. If, OTOH, the ISA had additional variants of those instructions that allowed usage of anything as a sentinel, HLL implementations of array would never have needed a fat pointer (length + memory).

Except that the ISA has a perfectly good ALU there that can detect zero really easily, so no one was going to waste silicon on an instruction that required comparison to yet another value (which essentially would be an additional subtraction or OR or equivalent) added to the loop.

The fat pointers are much more efficient in that you don't need to scan memory to get the length or find the end to append or take slices etc.

Especially for vectors that don't have any value that can be used as a sentinel.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#315

Post by rswail »

ptx wrote: post #234
EvanAnderson wrote: post #206

Earlier quoted context omitted.

I did a project to translate data framed in the ASCII field/record separator characters and it was gloriously easy. All the ugly escaping considerations with comma-delimited data went away and it became much easier.

What happens when the data contains the record or field separator characters? I suppose you could document that it's unsupported, and just drop or reject such values, but then the system couldn't be used to handle test data for such systems, for example.

If it's purely binary data, then you can't.

Otherwise you need to have some sort of escape mechanism, exactly like quoting strings in CSV. In fact, there's an ASCII code "ESC" for entirely that purpose. :)

The problem is that those characters are non-printable, which means if you're just dumping the file out somewhere, you can't see them.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#316

Post by rswail »

flohofwoe wrote: post #212
rswail wrote: post #209

Earlier quoted context omitted.

No, it was an Apple, Unix, and Microsoft problem. Unix used LF, Apple used CR, Microsoft used CRLF. They are all ASCII carriage movement codes, which is about driving the paper feed and print head of an ASR-33 or equivalent. So they all made the "wrong" decision about what to store in a file. They just chose different wrong characters.

> Apple used CR Apple hasn't been using CR since the release of OSX (26 years ago). Microsoft could have made the switch at any time too (just as they could have switched to UTF-8 as universal text encoding on Windows), they just choose not to. In the end it's not the job of programming languages to clean up Microsoft's mess ;)

We're literally talking about two decades before that.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#317

Post by rswail »

codedokode wrote: post #228
rswail wrote: post #160

Things that have bugged me for 40 years... * NUL terminated strings (and now, non UTF-8 encoded strings on input/output) * Using LF or CR or CRLF as line terminators, and pipe/comma-delimited fields when there were other unambiguous ASCII characters that could have been used (eg, GS, FS, RS) that would have made the encoding/decoding of line termination an I/O thing keeping HT/VT/CR/LF/FF as literally print related c…

> non UTF-8 encoded strings on input/output I would just use UTF-8 everywhere.

Storing them as 32 bits wide in memory means you can at least index by a codepoint (if not a glyph).

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#318

Post by rswail »

kps wrote: post #275
rswail wrote: post #209

Earlier quoted context omitted.

No, it was an Apple, Unix, and Microsoft problem. Unix used LF, Apple used CR, Microsoft used CRLF. They are all ASCII carriage movement codes, which is about driving the paper feed and print head of an ASR-33 or equivalent. So they all made the "wrong" decision about what to store in a file. They just chose different wrong characters.

> They just chose different wrong characters. Unix followed Multics. Multics chose right. ASCII/EMCA-6/ISO646 drafts discussed this at least as early as 1963¹: “For equipment which uses a single combination (called New Line) [...] NL will be coded at FE₂ [Field Effector 2 = 0x0A].” ¹ doi/10.1093/comjnl/7.3.197

For an OS that was being created specifically to process text, having the equivalent of CR being separate to LF to allow for overprinting would/should have been a requirement.

I'd say Multics/Unix was technically correct, except this was still the wrong decision for I/O ever since.

The Record Separator is the logical character code to use to indicate the end of a line of text and print position characters, assuming that a line of text is a "record".

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#319

Post by pjmlp »

layer8 wrote: post #171
mrlonglong wrote: post #2

the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer.

There is a middle ground that Visual Basic (and then COM) took, with the BSTR type: It’s still a pointer to a zero-terminated char array, but there is a length field immediately preceding the first pointed-to byte. This is still compatible with a C string (assuming no embedded null characters), but BSTR-typed functions can take advantage of the length value.

Nowadays replaced with HSTRING.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#320

Post by saagarjha »

smackeyacky wrote: post #80
mrlonglong wrote: post #2

the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer.

Zero terminated strings were the basis for an awful lot of useful software. Calling them the biggest mistake in computing is a bit OTT. I haven’t programmed anything Pascal related for 30+ years but I dimly remember thinking at the time that I wished the string system wasn’t so hard to use.

zero terminated strings may cause a lot of bugs, but it also ends up in a lot of useful software, so, it;s impossible to say if its bad or not,
Post reply on HN