C, Fortran, and single-character strings

Posted Jun 22, 2019 21:04 UTC (Sat) by ncm (guest, #165)
In reply to: C, Fortran, and single-character strings by marcH
Parent article: C, Fortran, and single-character strings

If C strings are evidence if cargo-cultish programming, so are all other string implementations, without exception. Nobody gets a pass, or a diploma.

Null termination is an example of a venerable programming practice, the use of sentinel elements, lately fallen from favor now that memory and cycles are thousands, millions, or even billions of times cheaper than they once were.

If we sneer at choices made then, under the constraints of the time, how much more derision do we deserve for unfortunate choices made without such constraints? 'Cause I could list such, all day long, about any system, language, or technology you can think of.

C, Fortran, and single-character strings

Posted Jun 22, 2019 21:37 UTC (Sat) by marcH (subscriber, #57642) [Link] (4 responses)

Yes, some of C' unsafe choices were made in a completely different context and yes of course many of these choices were required to perform anything in a reasonable time on 50 years older hardware (and not under constant attack). For this particular question however - if we can stop digressing for a minute - I can't see any massive performance advantage for having a marker at the end of an array compared to storing its length somewhere near the start. Maybe for some operations but clearly not for others. By the way Fortran is older than C and is still in use today too because of its... performance. LISP is even older; it's now renown for its performance yet it was somehow getting some work done at the time too.

> 'Cause I could list such, all day long, about any system, language, or technology you can think of.

Sure, let's start by looking at some CVE statistics. Wait, I said no digression sorry.

C, Fortran, and single-character strings

Posted Jun 23, 2019 4:04 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

C-style strings are really the only choice for a language like C. Since your primitive is a (regular) pointer you can't pass length naturally.

C strings allow you to pass substrings as a pair of pointers (or just one pointer for tail substrings), for example.

C, Fortran, and single-character strings

Posted Jun 23, 2019 18:02 UTC (Sun) by marcH (subscriber, #57642) [Link] (2 responses)

> Since your primitive is a (regular) pointer you can't pass length naturally.

Yes the type of (safer) arrays would have been one step above "primitive".

Looking at string.h on opengroup.org, it's interesting to see almost half the functions there already have some size_t argument.

> C strings allow you to pass substrings as a pair of pointers (or just one pointer for tail substrings), for example.

This is indeed a performance optimization. It's also a dangerous one if the array is not const (who owns it now?) and I don't see how "higher level" arrays would stop you from still doing that, I would just discourage you from doing it routinely in non-critical paths.

C, Fortran, and single-character strings

Posted Jun 23, 2019 21:07 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Yes the type of (safer) arrays would have been one step above "primitive".
Sure, but C was designed without such arrays. And a language with safe arrays won't be C.

I'm not saying that it's a good idea now, but null-terminated strings certainly make sense in C.

C, Fortran, and single-character strings

Posted Jun 25, 2019 16:41 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

Sure, but C was designed without such arrays. And a language with safe arrays won't be C.

No. A language with only safe arrays won't be C. C is supposed to provide access to low-level functions and that includes unsafe pointers and arrays. But C is also supposed to allow programmers to build higher-level abstractions, including things like safe arrays and strings, and there's excellent reason to use those safe arrays and strings in place of the unsafe alternatives when performance is not critical.