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

Modern C [pdf]

icube-icps.unistra.fr

Post reply on HN
Print view View original

351–360 of 396 posts

Re: Modern C [pdf]

#351

Post by spc476 »

Retra wrote: post #335
ArkyBeagle wrote: post #317

Earlier quoted context omitted.

C has a perfectly useable (null-terminated) string type, and there is no good reason to ever have a buffer overrun in C. I understand that this is... obscure for some reason and I'm not saying it never happens, but let's be realistic....

C has a char* type, which we call a string, but it is also the type of a pointer to a single char, which is not a string at all, and also something perfectly usable. "Ends with nul" is barely a part of C, it's more like a programmer's agreement. The language doesn't enforce it, require it, or check it. All it does is insert nul characters in literals, which is hardly enough to make a string type. Thus if you have a t…

From the signature, I would say it expects a NUL-terminated sequence of characters (a C-string) and it would modify it in-place to upper case each character. C already has a standard C function:

    extern int toupper(int);
(via #include ) that will upper case a single character. If, on the other hand, I saw:

    extern char *to_upper(const char *);
I would expect that to_upper() returns a new string (freeable via a call to free()) that is the upper case version of the given string.

> If I happen to have a pointer-to-char and pass it to a to_upper function that operates on strings, it will just write on invalid memory, because C can't distinguish between the two.

Um ... how do you "happen" to have a pointer-to-char? And unknowingly call to_upper()? I'm lost as to how this can happen ...

Re: Modern C [pdf]

#352

Post by ArkyBeagle »

nickpsecurity wrote: post #347
ArkyBeagle wrote: post #318

Earlier quoted context omitted.

I don't recall specifically about MSC but Turbo C had the same.... We considered having all the assembler in separate files better practice...

Even in embedded examples, I see a lot of inline ASM in C functions. So, what's separate files like? Do you just compile them separately, link them in as libraries, wrap them as a C function, and then call it? And what was the argument for this over just putting them inside functions of C source where necessary?

We'd generally wrap them as C functions. We'd frequently use the compiler to generate the assembly; have a prototype and all that.

Which is better depends.

Re: Modern C [pdf]

#353

Post by jimmaswell »

mixedCase wrote: post #214
jimmaswell wrote: post #84

Earlier quoted context omitted.

>Go prevents you from compiling with unused variables, and that combined with the Go documentation goes a long way towards teaching new Go programmers how they're expected to work. Things like this make me not want to use a language. Want to comment a=b; to a=3;//b temporarily? Too bad, either assign b to 3 or comment out b too, and if b was the only variable to make use of c, same for c, and so on. Same obnoxious no…

You can always use the black hole variable _ That mild inconvenience (which I almost never face while writing Go code after getting accustomed to the language and getting my editor to run goimports on save) has a big RoI in safety and program quality, which are much loftier goals than short term code-writing convenience.

I doubt the RoI is much more than if these were just suppressible warnings instead of errors, which work out great in C#.

Re: Modern C [pdf]

#354

Post by jandrese »

AsyncAwait wrote: post #73
jandrese wrote: post #50

Earlier quoted context omitted.

I was trying to teach myself some Rust and found the state of the documentation to be very frustrating. The core language is decently documented with the manual, but the standard library documentation was out of date in many places, most annoyingly in the first few hits on Google. I found 5 different ways to read a file on Google, and only one of them still worked. Plus I saw the release notes on the newest version t…

What are you missing from the up-to-date API reference[1]? [1] - https://doc.rust-lang.org/std/

I was trying to read a file one line at a time (reading only the first few lines of a very large file), and it turned out to be somewhat difficult as the built-in functions seemed to be really keen on operating on the entire file at once.

Re: Modern C [pdf]

#355

Post by prodigal_erik »

bluetomcat wrote: post #138
rileymat2 wrote: post #126

Earlier quoted context omitted.

There is also the issue of undefined and implementation defined behavior. When developing on one platform for an extended period of time, it is human nature to forget which features are implementation defined as you use them day after day and then have unexpected errors/flaws when porting.

Undefined behaviour actually isn't the monster that most C language lawyers want you to believe it is. With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught. Compilers are also mature enough to issue warnings about the use of uninitialized variables, missing return statements or mismatched printf specifiers. Heck, Clang maybe has more than 250 -W options.

Any user action that you didn't have a test case for can provoke catastrophic UB that valgrind never saw, so catching most issues has almost no value. This is why every OS and every app I have ever used were always unreliable shit.

Re: Modern C [pdf]

#356

Post by sn9 »

____nope wrote: post #297
ticviking wrote: post #279

Earlier quoted context omitted.

This is an idea that many people resist. I think they mistakenly believe that programming languages are genuinely difficult to learn, and students must start on one that is marketable.

It's hard to teach an introduction to programming without teaching a particular language. If you have to pick a particular language, it makes sense to choose something the student is likely to use in the future. This is not hard to understand.

That's silly. If you can reasonably claim to know how to program, the choice of language largely doesn't matter. Someone who knows how to program in [first language] should be able to pick up how to program in any language one is likely to encounter in an industry position.

So the first language should be one that gives the student a firm foundation from which one can become that competent.

I've personally seen excellent introductions to programming using C (CS50x), Python (Think Python, MIT 6.001), and Scheme (SICP).

Re: Modern C [pdf]

#357

Post by sn9 »

xenihn wrote: post #232
jackhack wrote: post #179

I wish I could like this book, but after reviewing the first chapter I can only imagine the confusion of students. I support very much the idea of breaking the book into levels, but it attempts to cover far too much, far too quickly and I don't believe this book would be useful for those who are not already familiar with the language. I've been writing C since the late 1980s, moved to mostly C++ by the mid 90s, C# in…

Do you have any recommendations for books?

K&R is great if you already know how to program.

If you're new to programming, Harvard's CS50x on edx is probably the best introduction to programming online and uses C. You'll learn enough to breeze through K&R and then some.

Re: Modern C [pdf]

#358

Post by yoha »

FloDo wrote: post #272
yoha wrote: post #187

Earlier quoted context omitted.

Decrementing loops is the one place where I have indulged in some trickery. I do: for (size_t i = 9; i --> 0; ) This has the advantage to be very easy to pattern-match once known. Obviously, for a beginner, I would just do: for (int i = 9; i >= 0; i -= 1)

Do you even realize that these two loops are not equivalent? One of them starts at 8, then other one starts at 9 ...

Right, my bad. I tend to write loops in the former style, thinking of them as reversed(range(9)). This is another advantage of this style. I should have been more cautious when writing the second one.

Re: Modern C [pdf]

#359

Post by pjmlp »

ArkyBeagle wrote: post #326
loup-vaillant wrote: post #218

Earlier quoted context omitted.

There is such a thing as path dependence. C got ubiquitous because of reasons (UNIX?), and now we're stuck with it. Now the historical accident theory is pretty obvious: it could have been an Algol, Fortran derivative instead of C, if only UNIX used that as a basis. C itself could have been designed differently, and if so would probably have different flaws and qualities. Asking for a Rust/Go/Whatever OS is dishonest…

C got ubiquitous well before Linux, at least. I'd date it back to the '80s on microcomputers ( mostly meaning DOS) . Lots of Pascal, but Pascal really was an engineering constraint at the time if you were doing actual system programming. And back then, that was a serious consideration.

Not in Portugal, we were using mostly using Turbo Pascal.

In the 80's using C on MS-DOS, was only seen by those that had UNIX at work or universities and wanted to work home.

It wasn't even C, rather SmallC or any other K&R dialect.

In any case, everyone that cared about performance was using TASM and MASM, writing everything in Assembly.

Re: Modern C [pdf]

#360

Post by someburner »

yekim wrote: post #225
chrisd1100 wrote: post #114

I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…

Hear, hear! Unfortunately, C does get a lot of hate on HN. I suspect it has to do with this site's demographics. Many (not all) of the HN clan seem to be oriented towards / mostly familiar with web based technologies. I suspect that for many who have tried, going from a web dev environment to a C oriented dev environment feels like a robust shock to the system. I'd also be willing to bet that there's an age bias at p…

It gets a lot of hate because the majority of developers are not embedded developers, kernel developers, or doing anything involving hardware. The other reason, IMO, is that to do anything that's actually kinda cool or fun in C you have to get pretty adept, so it's probably just written off as an old, boring language.

Personally I'm in my mid-20s and quite enjoy working in C. And for things like bit manipulation it's much easier than in higher level languages. I suspect at some point even the smallest MCUs will be able to run Rust or Go, but until that happens there is still a place for C/C++. Haters can hate but that won't change the fact that C is still the most widely supported language for embedded platforms (and Linux, the other elephant in the room).

Post reply on HN