[dead]
The Development of the C Language (1993)
521–530 of 536 posts
Re: The Development of the C Language (1993)
#522[dead]
Re: The Development of the C Language (1993)
#523[dead]
Re: The Development of the C Language (1993)
#524[dead]
Re: The Development of the C Language (1993)
#525Earlier quoted context omitted.
The issue to me is not the generation of code. It's that the person using it is inexperienced with the given language. We will never be able to place 100% faith in AI. At least in my lifetime. Given that, I think it's a relative danger that is washed away in all the hype. A junior dev copy-pasting code from chatgpt. I couldn't imagine a more dangerous combination.
Junior dev copy-pasting from stack overflow: this is already happening! Whatever bad thing AI tools can do, this is already reality all over the world.
That's not even close to the same thing. Stack overflow posters don't hallucinate solutions, and in all but the most obscure questions, the selected answer will have been reviewed dozens of times over.
With ChatGPT you get exactly what it gives you which must be trusted as a source of truth. That's bad.
Re: The Development of the C Language (1993)
#526Earlier quoted context omitted.
It is not, because they use C++. I avoid whatever I feel like.
Atmel and Xtensa have libraries in C. It's almost like I have some domain knowledge that you don't. Imagine coming in here with examples that aren't even microcontrollers as if that "debunks" what I said above. Like somehow magically I can just switch to a whole different platform. No problem, just crank out a new board spin and swap my whole toolchain over so I can... what... use a non-standard version of C in the a…
"1. Yes they are microcontrollers.
2. Yes they use C/C++"
So how it is?
Re: The Development of the C Language (1993)
#527Earlier quoted context omitted.
Atmel and Xtensa have libraries in C. It's almost like I have some domain knowledge that you don't. Imagine coming in here with examples that aren't even microcontrollers as if that "debunks" what I said above. Like somehow magically I can just switch to a whole different platform. No problem, just crank out a new board spin and swap my whole toolchain over so I can... what... use a non-standard version of C in the a…
"1. Yes they are microcontrollers. 2. Yes they use C/C++" So how it is?
The things you mentioned aren't both microcontrollers, and they use C.
Why continue to double down when you clearly have no idea what you're talking about?
Re: The Development of the C Language (1993)
#528Earlier quoted context omitted.
"1. Yes they are microcontrollers. 2. Yes they use C/C++" So how it is?
The things you mentioned aren't both microcontrollers, and they use C. Why continue to double down when you clearly have no idea what you're talking about?
So are you taking back the original answer?
Those are not my words.
Re: The Development of the C Language (1993)
#529"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for…
You don't need a separate linter for this stuff today, proper compilers (anything but MSVC basically) have the most important type-related warnings in the default warning set, and it always makes sense to bump warnings to the highest level (both in C and C++ btw) - also (because I know this will be brought up): implicit conversion of a void* to other pointer types is a feature, not a bug ;)
Even enabling -Wall is a debatable point of view in some circles.
VC++ is actually quite good, has SAL, /analyse and SFIR. Also much better than many other compilers, when looking beyond the big three.
Implicit conversations is a common source of errors. Certainly a nice feature for pentesting.
Re: The Development of the C Language (1993)
#530People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…
1. It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. 2. Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow. These statements are not true in languages which support operator o…
> If a line of code doesn't look like a function call, it's not calling anything.
except maybe allocating dynamic arrays, floating point ops if those don't exist in hardware. Then you have signal handlers that can be called on math errors, segmentation faults, ... . So basically every line in your code can implicitly call a function.
> If I give a Linux user the source of a C program, they can probably compile it with the tools they already have.
What is win32.h and why is it missing?
> This will most likely be the case 20 years from now too
What is Xlib.h and what do you mean I have to rewrite the apps front end from scratch?