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

C Strings and my slow descent to madness

deusinmachina.net

Post reply on HN
Print view View original

291–300 of 329 posts

Re: C Strings and my slow descent to madness

#291

Post by marssaxman »

athenot wrote: post #103
marssaxman wrote: post #90

Earlier quoted context omitted.

> the C std lib is the weakest part of the C language and it should only be used as a fallback. I've been musing for a while now: what would it look like if we were to discard the C library and design a new one, leaving the language itself intact?

The old MacOS (pre-X) did just that. Strings were all "Pascal strings", ie. with the first byte containing the length of the actual string. Building blocks for memory were also very different from stdlib, notably the use of Handles, which were pointers of pointers, so that the OS could move a block of data around to defragment the heap behind your back without breaking the memory addressing.

I remember that era well! During the first few years I used C, I never touched its standard library at all, using the Mac Toolbox instead. This was a common practice, which later carried over into C++.

Re: C Strings and my slow descent to madness

#292

Post by anthomtb »

saagarjha wrote: post #220
jandrese wrote: post #73

Earlier quoted context omitted.

The thing that annoys me the most about strlcpy is that it is supposed to be safer, but what happens in the case where the source string is not properly NULL terminated? You might think that it will stop at the character limit you specified, but that's not what it does. It just blows on past the end of the buffer looking for a \0 until it either finds one or causes a segmentation violation. IMHO I would like it much…

> what happens in the case where the source string is not properly NULL terminated That’s not a string.

None of strlcpy, strncpy, and strcpy will know that you have not provided a string. They will assume the source pointer is a string and as such, will read (and write, in the case of strcpy) bytes until they find that NUL.

This is the upside of strlcpy. Whatever is in your output buffer is guaranteed to be a NUL terminated and have your desired length. strncpy does not make that guarantee. strcpy will give you something with a NUL terminator but it could be well past the end of the output buffer. Hello, CVE.

The more I write here, the more I realize how silly it would be to write anything dealing with human-readable text in C in 2023. I had been working on a C webserver a while back but I think I'm going to purge that from my local git server and start over with something else.

Re: C Strings and my slow descent to madness

#293

Post by vkou »

scoutt wrote: post #258
vkou wrote: post #225

Earlier quoted context omitted.

You've grown to love the footguns and hundreds of thousands of security holes that null-terminated strings have introduced over the decades? It's not so much a question of different is bad, it's that having one of the six positions for your car's stick shift be marked 'Self-destruct' is... Sub-optimal. I'm sure you're smart enough to operate that car safely, but the ditches seem to be filled with burnt-out husks. Tab…

On a Python car, the car won't even start if you don't have your cosmetics right, and they have to be of a specific color.

I'm pretty sure that my C program either won't compile, or won't do what I want if I treat curly braces and semicolons as you are treating python indentation.

They serve the exact same purpose, and are both necessary, but the choice of braces versus whitespace is purely aesthetical.

Re: C Strings and my slow descent to madness

#294

Post by alxmdev »

fractalb wrote: post #235
nneonneo wrote: post #202

Pop quiz, which of these is safe, given "char buf[80]" and arbitrary user input in argv[1]? gets(buf); scanf("%s", buf); strcpy(buf, argv[1]); scanf("%80s", buf); strncpy(buf, argv[1], 80); snprintf(buf, 80, argv[1]); ---- The delightful answer is none of them . The first three have no bounds checking at all, meaning that they will happily overflow the buffer to an arbitrary extent (gets, at least, will usually trigg…

snprintf(buf, 80, “%s”, argv[1]); Should work.

Bingo, you should never pass arbitrary strings where they could be used as format specifiers, it's like running arbitrary code. Some compilers even issue warnings when you pass non-literal format strings to the printf family.

Re: C Strings and my slow descent to madness

#295

Post by uecker »

colejohnson66 wrote: post #286
uecker wrote: post #275

Earlier quoted context omitted.

How would you express a 2D memory layout with only pointers?

An array of pointers to arrays? Basically, a `T**` C#'s "jagged" arrays are like this, and to get a "true" 2D array, you use different syntax (a comma in the indexer): int[][] jagged; // an array of `int[]` (i.e. each element is a pointer to a `int[]`) int[,] multidimensional; // a "true" 2D array laid out in memory sequentially // allocate the jagged array; each `int[]` will be null until allocated separately jagged…

Yes, this is people with pre-C99 compilers that do not support variably modified types sometimes do. It is horrible (although there are some use cases).

Re: C Strings and my slow descent to madness

#296

Post by robomartin »

jiggawatts wrote: post #265
robomartin wrote: post #237

Earlier quoted context omitted.

> The delightful answer is none of them. No. Sorry. This is bad programming. C'mon. I started programming back in the 8080, 8085, 6502, etc. days. I had to program some prototype computers using a hex keypad while entering raw machine code (not even assembler). I still own a couple of these: https://i.imgur.com/ZsIJj1p.png In a couple of cases I had to take this approach to bootstrap Forth on a 6502, then write a ful…

> A knowledgeable software developer, among other things, stays clear of these issues. This is the "no true scotsman" fallacy. Languages can be designed so that less than perfectly knowledgeable programmers fall into the pit of success, or they can be designed so that they fall into the pit of failure. For people making your argument, I like to provide this challenge: Go take a flight on a 737 MAX that hasn't had its…

> This is the "no true scotsman" fallacy.

Sorry. Not even close. Source: I actually studied Phisolophy/Logic at Uni. Good try though.

Also, your aircraft example is absolutely ridiculous.

This isn't an appeal to purity at all. This is about domain knowledge and experience.

A more appropriate example might be the contrast between someone who has only done 3D printing now deciding to design and make parts meant for CNC machining. The lack of expertise and understanding will result in some pretty serious problem.

Another example, this time about software development. I have over ten years of professional software development using Forth. Someone coming to Forth from, say, Python, is likely to make an mess until they understand how to approach problems in Forth. I also have about ten years professional coding experience using APL. Same thing. Someone coming to APL from other languages is going to run into problems until they gain enough knowledge to write APL.

Re: C Strings and my slow descent to madness

#297

Post by robomartin »

KyeRussell wrote: post #287
robomartin wrote: post #237

Earlier quoted context omitted.

> The delightful answer is none of them. No. Sorry. This is bad programming. C'mon. I started programming back in the 8080, 8085, 6502, etc. days. I had to program some prototype computers using a hex keypad while entering raw machine code (not even assembler). I still own a couple of these: https://i.imgur.com/ZsIJj1p.png In a couple of cases I had to take this approach to bootstrap Forth on a 6502, then write a ful…

God, this attitude reeeallllyy grinds my gears. This is precisely why C has outstayed its welcome in so many areas of software development. Every time some kid looking for a self-confidence boost buys into the idea that using a language with a minefield of archaically-named string manipulation functions somehow makes them a ‘real’, ‘smart’, developer, we are all left a little worse off. No, it’s not the fault of the…

> God, this attitude reeeallllyy grinds my gears.

> ‘real’, ‘smart’, developer

It should not. And you are taking my comment completely out of context. 100% out of context. Violently out of context.

I have not even implied that this is about "real" or "smart" developers. C'mon!

This is about TWO things: Knowledge and experience. And that is IT. That's what I said.

So, pretty please, don't put words in my mouth and get all self-righteous about something you invented.

> Why can’t they be as smart as us C developers!

They can! All they have to do is learn and develop the experience base to use the tool correctly. Nobody is saying it can't be done. Again, don't put words where I did not use them.

Do you drive a car every day?

Yes?

Do you think you would do well if you got in the seat of a Formula 1 car?

Of course you would not. Because you lack knowledge and experience in the domain. You can learn. Of course you can learn. And that requires work and dedication.

Blaming the Formula 1 car for the lack of knowledge and experience of the driver is nothing less than ridiculous.

Re: C Strings and my slow descent to madness

#298

Post by robomartin »

imtringued wrote: post #259
robomartin wrote: post #237

Earlier quoted context omitted.

> The delightful answer is none of them. No. Sorry. This is bad programming. C'mon. I started programming back in the 8080, 8085, 6502, etc. days. I had to program some prototype computers using a hex keypad while entering raw machine code (not even assembler). I still own a couple of these: https://i.imgur.com/ZsIJj1p.png In a couple of cases I had to take this approach to bootstrap Forth on a 6502, then write a ful…

>Do not confuse bad programming or lack of knowledge with something attributable to a language, any language. In C everyone starts out as a "bad programmer". In other languages people are merely inexperienced. >however, someone with deep-rooted experience in these languages who jumps into C is very likely to do some truly horrific things. The language isn't the problem, at all. You are contradicting yourself.

> In C everyone starts out as a "bad programmer"

In everything in life one starts out as a "bad ". I would be a bad free diver (I'd probably kill myself).

People inexperienced in lack knowledge in . That is not an insult. That's just reality. One can do some pretty serious mistakes as an inexperienced Python programmer (example: async/await) or downhill skier.

It's not the language, it's lack of knowledge and experience.

It's not the ski's, it's lack of knowledge and experience.

Are we now in a culture where saying that someone is doing badly because they don't have experience is an insult? OK, great. Let's blame everything else, except for lack of experience. C is the problem. Please don't use it.

It will be very interesting to watch as the "not my fault/blame everyone but me" crowd faces having justify their lack of skills with what tools like ChatGPT will evolve into. Very interesting. I guess we'll blame LLM's for not knowing well enough to be hired.

Re: C Strings and my slow descent to madness

#299

Post by shrimp_emoji »

robomartin wrote: post #298
imtringued wrote: post #259

Earlier quoted context omitted.

>Do not confuse bad programming or lack of knowledge with something attributable to a language, any language. In C everyone starts out as a "bad programmer". In other languages people are merely inexperienced. >however, someone with deep-rooted experience in these languages who jumps into C is very likely to do some truly horrific things. The language isn't the problem, at all. You are contradicting yourself.

> In C everyone starts out as a "bad programmer" In everything in life one starts out as a "bad ". I would be a bad free diver (I'd probably kill myself). People inexperienced in lack knowledge in . That is not an insult. That's just reality. One can do some pretty serious mistakes as an inexperienced Python programmer (example: async/await) or downhill skier. It's not the language, it's lack of knowledge and experie…

Funnily, GPT-4 seems like it generates pretty bad C code but pretty good Python code.

The C code will have silly things, like bad style or `double d = malloc(sizeof(double))` (instead of `double*`), which makes it evident that its training data was full of pretty bad C code. Which makes sense since most C code out there, like on StackOverflow, is bad. Same with Bash code.

The worse quality of code available in these langs suggest to me that these langs are inherently more difficult, which means people are more likely to be bad at them.

Whether they deserve blame for that, or whether it disqualifies them as legitimate technologies, is subjective. Objectively, though, you're accepting a higher rate of failure by using them over less difficult alternatives. If "good " colloquially means " with high likelihood of generating desired outcomes" and "bad " means " with high likelihood of generating undesired outcomes", I think it's fair to call both "bad langs". ;p

Re: C Strings and my slow descent to madness

#300

Post by robomartin »

skribanto wrote: post #243
robomartin wrote: post #237

Earlier quoted context omitted.

> The delightful answer is none of them. No. Sorry. This is bad programming. C'mon. I started programming back in the 8080, 8085, 6502, etc. days. I had to program some prototype computers using a hex keypad while entering raw machine code (not even assembler). I still own a couple of these: https://i.imgur.com/ZsIJj1p.png In a couple of cases I had to take this approach to bootstrap Forth on a 6502, then write a ful…

One could take a glance at these and easily believe that they do the right thing. I don’t think that no one would accidentally miss such a small error from time to time.

Of course, and the more experience you have the less of this will happen.

I've been writing software in over a dozen languages for over 30 years. Generally speaking, when I write code, even complex code, in any language, it just works. Not because I am something special. I have done a lot of of work across a wide range of application domains and have made my share of mistakes over the years.

Of course I make mistakes. Everyone does. Yet these mistakes. They have nothing to do with lack of domain knowledge. People who approach C without having a clue as to how memory, registers and the internals of a processor and memory system work are going to create bad code.

Blaming the language, the tools, is irrational. You can write perfectly good, safe and performant code in assembler. And boy, can assembler be a minefield in the hands of someone without experience!

Are we going to blame the processor microcode then? No, of course not.

Post reply on HN