Hacker News Reader

Comment by annowiki | Hacker News Reader

I think you're right. I'm by no measure a C programmer, but I've always regarded it as something that people don't like coding in because it's difficult, not because it's a bad language. Most people complaining about C are like guitar players complaining about the piano. It's more complex, but it has to be given its role.

That said, the fact that K&R didn't specify the size of an int or long complicated matters, but it seems to be an accident of history, not a mistake in design. They had no choice.

View on HN

I'm a C programmer. I don't know if I'd say it's a bad language, but I definitely hate it. I agree wholeheartedly with OP about the quality of life stuff.

I'm constantly amazed by what C will let you do. The footguns and lack of type checking. C compilers will link a function to a variable for instance. Don't forward declare your functions, and you might not even get a warning (yes some compilers don't give warnings by default for implicit functions). The linker will then go to the symbol table find anything that matches and place a function call. That's just one example, but they're many. C builds erroneous code.

>yes some compilers don't give warnings by default for implicit functions

Broken or ancient compilers. That's as much C's fault as it's Intel's fault that Windows 10 doesn't run on Pentium MMX. Implicit functions are not part of C; they were gotten rid of back in 1999!

I agree to some extent (I'd also add that undisciplined and apathetic programmers are an even bigger problem).

I have to disagree about implicit functions not being a part of C anymore. I've yet to see one generate an error; this is optional, and frequently not used. I'm including brand new, state of the art compilers, even (default) gcc. Of course, not even emitting a warning is bananas.

I confirmed this, with the following snippet:

// start fail.c

int fail = 0;

// end fail.c

int main(void)

{

   fail();
   return 0;

}

gcc --std=c99 -g main.c fail.c -o main.exe && gdb main.exe -ex run

# Cmd line junk, however a warning was emitted for implicit function "fail"

Program received signal SIGSEGV, Segmentation fault.

0x00407020 in fail ()

>I have to disagree about implicit functions not being a part of C anymore. I've yet to see one generate an error;

This is not really a debatable matter. There's an international standard for what is, and what is not a part of the C language.

Errors as you seem to understand them are optional for everything else except for the #error preprocessor directive. For all the other invalid C programs, only a diagnostic (like the warning you got) is required, and a conforming implementation is free to complete translating the invalid translation unit. I don't see why that would be an issue, as it's very easy to switch those warnings into translation errors if wanted.

My preferred workaround for this is to write C code that is accepted by a C++1x compiler under fairly strict warning settings, and use a few standard macros that compile to the usual unsafe constructs in C but allow the C++ compiler to enforce extra rules. E.g. I use {S,K,R}_CAST macros instead of plain C casts.

Although it was great for it's time, I think now (2019) it's rather silly that you de facto must learn three languages to use C:. C, C preprocessor, and make.

If I had to do that every day (I don't use c, except passingly, and usually in read-only mode) I'd tear my hair out, and that's even before the inevitable footguns I'd write.

That's not even the half of it. Dealing with the differences between compilers, oftentimes preemptively, and various standards. For a very long time, it was common to build under c89 "just in case". Now you have to deal with the differences between c89, c99, and various industry/internal standards. That's not even considering how configurable compilers are, and all the features to consider. Then as you said, make or IDE.

Much of this isn't necessarily specific to C (lots of toolchains include build scripts, complicated settings, different language revisions, standards, ect., ect., ect.) It does feel especially bad in C though.

> I think now (2019) it's rather silly that you de facto must learn three languages to use C:. C, C preprocessor, and make.

That's basically the case with nearly every language. Most will have some sort of equivalent of the pre-processor and it's usually a lot more complicated, c++ template craziness, code generation tools, dynamic meta-programming tools, etc. For all it's faults the simple text substitution of most macros is the least complicated option.

Most languages will have there own build tools as well, sometimes it will be the same language with something like rake, other times it's xml or it's own language. And they're nearly always inferior to make in many ways.

> the fact that K&R didn't specify the size of an int or long complicated matter

I disagree. I'm glad they didn't -- we may have been stuck with 2 byte ints and 4 byte longs!

To quote the standard:

> A "plain" int object has the natural size suggested by the architecture of the execution environment

If you want a portable assembler, you absolutely need a type like C's int. Meanwhile, stdint.h provides fixed-width integers if you really need them.

> I disagree. I'm glad they didn't -- we may have been stuck with 2 byte ints and 4 byte longs!

At least then "long" would have a usage, whereas currently it's entirely dead & useless, and it'd be much easier to deal with printf's string formatting than the PRId64 nonsense.

The named-size types (int32_t, etc..) are king anyway

Reply on news.ycombinator.com