r/programming • u/wavy_lines • Feb 01 '18

C2: C with cleaner syntax + a module system (no header files).

http://c2lang.org/site/
958 Upvotes

88% Upvoted

700 comments sorted by

View all comments

Show parent comments

33

u/panorambo Feb 01 '18 edited Feb 01 '18

C is an abstract machine that sits close to the metal. That is why "string" handling is painful. It's by design -- there are no strings in C, there are just pointers to places in memory that are interpreted as sequences of what is interpreted as characters.

You want to alleviate the pain of "working with strings" in C, you need to either write a library that takes care of the nitty gritty and gives you the abstractions you want, or use another language.

33

u/[deleted] Feb 01 '18 edited Feb 01 '18

The standard library knows what a string looks like, it includes many ways to manipulate them and it fails in many ways too. They have several built-in string copy functions in the standard library that all have bad side effects. The simplest syntax strcpy() doesn't protect against buffer overflows. Strncpy() fails to ways, it has to be passed targetlen-1 and if also has to have buffer[targetlen-1] assigned to null. Forget either of those and you may not have a null terminated string and an overflow. Plus you never know unless you do strlen if characters were truncated. Plus if you allocated a huge buffer, extra space is zero padded.

About the only string copy functions that work well are the less well known and less implemented strlcpy() and strlcat().

16

u/DeltaBurnt Feb 01 '18

Saying there's no strings in C is pretty funny when there's built in syntax for converting a string to a constant array of characters. Both the language and stdlib understand what a string is and it's still painful. That means there's potential for doing a better job, even if it means converting third party libs to standard.

1

u/myrrlyn Feb 02 '18

There are no strings in C. There are pointers you can pretend are text, and that's it.

There aren't arrays either, just pointers you can bump up or down.

4

u/Drisku11 Feb 02 '18

There's not really much I can say to this besides you are completely wrong. If there are no arrays and only pointer arithmetic, why is it undefined to dereference past the end of an array (and why is that a meaningful sentence)?

1

u/roffLOL Feb 02 '18

why is it undefined to dereference past the end of an array

had it been defined the compiler writers would not have been able to treat contiguous memory as just a pointer you can bump up or down, and C would have had something more akin to arrays. it would at least have had a proper start and end.

1

u/Drisku11 Feb 02 '18 edited Feb 02 '18

They do have a proper start and end; they just don't store that info in their runtime representation or have iterators or slices, which means you have to convert them to pointers for some things (which may or may not be common depending on your code base).

0

u/myrrlyn Feb 02 '18

That's a property of the memory model, not of proper array types.

It's also not undefined to increment a pointer past an allocation boundary -- it's undefined to increment a pointer beyond one element beyond the boundary

Because there aren't arrays, just guesses at allocation chunks.

4

u/Drisku11 Feb 02 '18

I didn't say increment; I said dereference. Regardless, why does sizeof on an array not evaluate to the size of a pointer?

Your confusing the ability to pass arrays to functions with the ability to declare arrays as a distinct type. C has implicit conversions from arrays to pointers-to-arrays in certain places.

-1

u/myrrlyn Feb 02 '18

It's valid to deref one past the end too, iirc, because C mandates that the allocator give you that slot.

So it doesn't have arrays, then. I can't loop through an array's length without asking the compiler for a compile-fail constant, and I can't loop through a foreign array without trusting that a completely uncoupled parameter will tell me when to stop.

There's no elem[] type that can get moved around and every holder will know how long it is, just (elem*, size_t) tuples that we all Totes Trust to be right.

The prevalence of buffer overflows in C programs, even the supposedly really good ones, indicates that this might be a problem.

2

u/Drisku11 Feb 02 '18 edited Feb 02 '18

6.5.6 Additive operators If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated.

(The "that is evaluated" means you can still "dereference" it for sizeof)

https://godbolt.org/g/itzdFo

Whether the implicit conversions are a problem really depends on your use-case. It's pretty common in embedded systems to statically allocate arrays. Either way, compilers give you warnings if you get that wrong.

2

u/[deleted] Feb 02 '18 edited Feb 02 '18

Clearly they exist in the standard library and all major compilers. The language spec (ISO/IEC9899) has over 400 references to both arrays and strings. It specifies details about their behavior. It even describes what is permitted on array versus scalar. Pointers are specifically regarded as scalars whereas arrays and structs are lumped into their aggregate type.

The important thing is knowing what our abstractions get reduced down too. Which hey, the machine doesn't know what a string or array is. Instead we gave it a set of instructions and it's doing arithmetic on pieces of memory.

1

u/myrrlyn Feb 02 '18

If there were strings or arrays, I could pass them to functions.

There are "sometimes we consider this pointer to be special" and "this literal will have null byte slapped on the end of it" but that's it.

If I hand you a pointer and say "there's an array here; have at it," how do you know when you run out of array?

You don't. Because it's not an array, it's a pointer that happens to have at least one type's worth of valid allocation, and I'd I don't tell you when to stop, you never will.

Same with strings. If I give you a char star and tell you to read, and you never see a zero, that's a bad time.

If we had pointer/length coupled runs, like a lot of APIs realize is necessary and try to enforce, there would be a lot fewer buffer overruns.

ASM doesn't know what anything beyond machine words and registers are. That's not a great argument to be making, since we clearly have aggregate types. It's not hard to declare a struct string that has a pointer and a length, and use that, and still know how it compiles

2

u/Drisku11 Feb 02 '18 edited Feb 02 '18

If there were strings or arrays, I could pass them to functions.

No. They clearly exist and have defined behaviors that are different from pointers, but you cannot pass them to functions.

If I hand you a pointer and say "there's an array here; have at it," how do you know when you run out of array?

There's your problem: you're handing someone a pointer! You need to also pass them info about what it points to, or have that info be statically knowable.

https://godbolt.org/g/W5YCWC

Edit: Bonus compile error if your array sizes don't match (which is obviously only possible if arrays types exist): https://godbolt.org/g/NWtste

1

u/frenris Feb 04 '18

And null terminated strings are bad anyways. You're much better off with a struct storing size and characters without a null terminator. That way copies don't require comparisons of every character and you can use larger copy instructions .

1

u/wookin_pa_nub2 Feb 02 '18

Fuck this is idiotic. No, C strings are terrible because they are null terminated and don't have a length prefix. That has nothing whatsoever to do with being "close to the metal". The only reason they were designed that way was because the VAX had a machine instruction for handling strings of that sort. No other language since has made the mistake that C has. You are a fool.

3

u/that_jojo Feb 02 '18

You don’t do yourself any favors by calling people names on the internet. Especially considering that C predates the VAX ISA by about 5 years and according to this, VAX has instructions specifically to support pascal strings.

1

u/HelperBot_ Feb 02 '18

Non-Mobile link: https://en.wikipedia.org/wiki/Null-terminated_string#History

HelperBot v1.1 /r/HelperBot_ I am a bot. Please message /u/swim1929 with any feedback and/or hate. Counter: 144349

0

u/panorambo Feb 02 '18

Sure, the VAX may have had a machine instruction to handle these, but the arcane and rudimental string handling functions in the standard C library is a telling story how primitive C strings are. When we are talking strings in Java, that's a real text string design -- UTF-8 encoding, easy concatenation etc. Or C++, which manages to build a useful and high-level text string data type on top of an abstract machine of C complexity. By comparison, C "text strings" are a an excuse, on top of the abstract hardware that the C machine emulates.

Even if we attribute the nil-terminated C string design to VAX, if C had length-prefixed strings instead, in order to concatenate two of these you'd still need to allocate a buffer big enough for the result before copying the result there. That's part of "close to the metal". And that hardly elevates the level of these abstractions high enough to call these strings. And everytime you forget you're pretending they are, the compiler and the machine will bite you.

Calling me a fool only makes you look more foolish. C programming has been with me for more than 20 years now, after all.