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

Some dark corners of C

docs.google.com

Post reply on HN
Print view View original

131–140 of 175 posts

Re: Some dark corners of C

#131

Post by graycat »

temac wrote: post #118
graycat wrote: post #79

For "dark corners of C", when I was writing C code I had several serious concerns. Below I list eight such in roughly descending order on 'seriousness': First, what are malloc() and free() doing? That is, what are the details, all the details and exactly how they work? It was easy enough to read K&R, see how malloc() and free() were supposed to be used, and to use them, but even if they worked perfectly I was unsure…

Don't think the K&R book is the standard. The standard now exists and is detailed enough, for what C aims at being. As for doing maths in C or wanting managed allocation, it is well there are better languages for that (and it was even better wide know twenty years ago for the math part...) You seems to have found some that works well for your needs so everything is good.

I confess: When I was writing C, K&R was the standard! Good to see that now there are better versions of C with more detailed documentation.

The last time I had to write some C, I just refreshed my C 'skills' with K&R and reading some of my old code.

For your

"You seems to have found some that works well for your needs so everything is good."

I agree: I looked at Java early on and didn't like it. From some of the comments and links here at HN, I see that Java has made progress since then. Indeed, some of what I like in Visual Basic .NET (I say ".NET" because there is an earlier version of Visual Basic that is quite different and less 'advanced') seems to have come from Java. So, now I'm glad to have the progress of Java and/or Visual Basic .NET and will return to C only when necessary.

Actually, the last time I worked with C, I wrote only a few lines of it! Instead, I took some Fortran code, washed it through the famous Bell Labs program f2c (apparently abbreviates 'Fortran to C') to translate to C, slightly tweaked the C, compiled it into a DLL, and now call it from Visual Basic .NET.

Maybe what will be waiting for me in the lower reaches is C programming on an early version of Unix without virtual memory and without a good text editor on a slow time sharing computer using a B/W character terminal, 24 x 80!

Re: Some dark corners of C

#132

Post by graycat »

jejones3141 wrote: post #109
graycat wrote: post #79

For "dark corners of C", when I was writing C code I had several serious concerns. Below I list eight such in roughly descending order on 'seriousness': First, what are malloc() and free() doing? That is, what are the details, all the details and exactly how they work? It was easy enough to read K&R, see how malloc() and free() were supposed to be used, and to use them, but even if they worked perfectly I was unsure…

"heap" goes back at least to Algol 68, where you could write (using case stropping) REF INT i = HEAP INT; # sort of like C++ "new" # REF INT i = LOC INT; # allocates from the stack # or the shorter forms HEAP INT i; LOC INT i;

You got me! I wrote a little Algol 60 at one time and heard nice things about Algol 68 but never looked at it.

Since heap is the word used in heap sort, it's fair to say that the second use of that word was a misuse. I don't know which use was second and don't really care but did want to know the details of the dynamic memory allocation used by the C malloc() and free(). I just would have appreciated an explanation of malloc() and free() were doing so that could write some code, as I described, to 'help' me monitor what my code was doing with memory. Sure, now writing a good system for 'garbage collection' complete with reference counts and memory compactification is difficult, but what malloc() and free() were doing was likely not very tricky. I just wish K&R had documented it.

Re: Some dark corners of C

#133

Post by norswap »

kstenerud wrote: post #111
robotresearcher wrote: post #102

Earlier quoted context omitted.

It does test knowledge. Nothing wrong with knowledge. I expect they asked some other questions too.

It tests esoteric (aka borderline useless) knowledge. There's a big difference between that and, say, knowing how to use something actually useful like double pointers. I had no idea how the C parsing algorithm worked for +++ et al, and I'm an expert C programmer. Then again, I'd also never use such ridiculous constructs in production code.

It's not that esoteric. You need to see it in a broader scope than simply something that the C standard specifies. It's about how parsing is traditionally done: by splitting input into token using a longest-match if multiple token fit the begin of input. Then you can use the token to do things.

Even if you don't know that much about the subject, you can still have an interesting reasoning about it. Seeing that it is ambiguous is already a good observation. You then can propose way to resolve the ambiguity and touch (willingly or not) upon the topics of operator precedence, associativity, greedy matching.

Those topics are not only relevant in parsing either, for instance associativity is an important concept for list operations such as folding (a right fold is different from a left fold).

Re: Some dark corners of C

#134

Post by wahnfrieden »

Flimm wrote: post #121
pooriaazimi wrote: post #81

Earlier quoted context omitted.

> My main take-away from this is that Google Drive seems like a nice way to put presentations online :-) Don't. I've been trying to access the presentation for 10 minutes and it won't allow me: Wow, this file is really popular! Some tools might be unavailable until the crowd clears. and then I get redirected to https://support.google.com/accounts/bin/answer.py?hl=en&... (which is stupid, because there's nothing cache…

For me, it works, but it makes each slide an entry in my browser's history, which I hate.

In Chrome, it will still show the last history item with a different host at the bottom. So maybe use a better browser ;)

Re: Some dark corners of C

#135

Post by DerekL »

kps wrote: post #72

int x = 'FOO!'; will not make demons fly out of your nose: it is not undefined behaviour . It is guaranteed to produce a value; the specific value is implementation defined (that is, one that the compiler vendor has decided and documented), but it is an integer value, not a demon value. I'm sure, though, that someone sooner or later will be bitten by code like int x = 'é'; which is equally implementation-defined.

    int x = 'A';
is also implementation-defined.

Re: Some dark corners of C

#136

Post by billforsternz »

graycat wrote: post #79

For "dark corners of C", when I was writing C code I had several serious concerns. Below I list eight such in roughly descending order on 'seriousness': First, what are malloc() and free() doing? That is, what are the details, all the details and exactly how they work? It was easy enough to read K&R, see how malloc() and free() were supposed to be used, and to use them, but even if they worked perfectly I was unsure…

1) malloc() and free() are just library calls, they're not first class citizens of the language. K&R and other good C references describe their public interface well and that's all you need to know to use them effectively. The public interface encapsulates the implementation details, good software engineering in my book. 2) Usage of the stack reflects C's low-level, high performance "portable assembler" roots. Choosing the stack size, and avoiding allocating too much on the stack are familiar problems for assembly programmers too. I remember back in the 80s some C programmers were high level guys going down and some were assembly guys going up. Only one of these groups would ever try to put 100,000 character arrays on the stack :- ) 3) C strings are admittedly idiosyncratic, but with practice you can grow to love them and be very productive with them. But they are only a good match for textual data. If you are trying to use C strings for things like audio samples, sorry you are doing it wrong. 3) C casts are useful when you understand and the machine representation of the types you are working with. Typical use cases arise when you are bit twiddling, for example writing hardware drivers etc. If you have no particular interest in the machine representation of your data, then the presence of C casts in your code is a red flag. They aren't needed for normal computational tasks. 5) Fair enough, you can make a decent threading library in C, but it's not for the faint hearted or inexperienced. 6) Personally, I don't use multi-dimensional arrays in C much. I suspect you are probably right, they are just a weak part of the language. I could potentially be persuaded otherwise by someone more proficient. 7 and 8) I don't know much about PL/I so I will not comment in depth. I suspect you are exhibiting the 'mother' syndrome here. You learned PL/I first, that's what you fell in love with. I'd probably look at PL/I and think why don't they do it like C ? C is such an nice balance of terse yet capable. Far from being obscure I'd judge the C pointer syntax to be a miracle of concise elegance, etc. etc.

Re: Some dark corners of C

#137

Post by asveikau »

udp wrote: post #113
tobiasu wrote: post #5

Earlier quoted context omitted.

Last time this came up on HN, it was thought to be a clang feature. Edit: While we're talking about dark corners, please stop casting functions that return void * . If your code lacks the declaration of the function, the compiler will assume pre ANSI-C semantics and generate code returning an int . On machines where pointers do not fit ints (basically all 64bit machines), you just silently (due to the cast there is n…

> While we're talking about dark corners, please stop casting functions that return void * The problem is, if I want my C code to compile with MSVC, it has to compile as C++ - and even if I abhor Windows for development myself, a lot of developers are using MSVC. I just wish Microsoft would update their C compiler, at least to C90. But then I suppose the standard has only been around for 23 years, and nobody really u…

> The problem is, if I want my C code to compile with MSVC, it has to compile as C++

As someone who has compiled a lot of .c files that do not cast void pointers with cl.exe, I'd say no, this is not true... Maybe what you're trying to say is that your code relies on C99 features that are also present in C++? IMO if that's what's holding you back it's much easier to just write C89, maybe with the occasional ifdef, than to suddenly write some crummy C/C++ hybrid. That or just use mingw. (Unless you're doing SEH. I'm not aware of a good way to do SEH with mingw.)

Re: Some dark corners of C

#138

Post by asveikau »

Peaker wrote: post #128
dakimov wrote: post #42

Earlier quoted context omitted.

Is my thought that complicated it needs additional explanation? By the way, I'm an expert C/C++ programmer, so my opinion matters.

A self-proclaimed expert, one must add.

I don't know dakimov and what his history may be (maybe it's even a language issue or that he simply doesn't "speak HN" yet - I also sometimes find myself out of touch with the culture on this site like he seems to be), but I can vouch for what he's saying. I find it difficult to read discussions about C on HN. A lot of the discussion is as if to read a bunch of kids who seemingly just learned javascript or ruby yesterday, then they go way out of their element talking about C. An experienced and competent C programmer would not be surprised by anything in these slides, except perhaps the slide about the novel use of "static", because it's an obscure C99 feature that nobody really uses (in the same way that most people would also not recognize that, for example, C99 specifies compiler support for complex numbers).

Re: Some dark corners of C

#139

Post by spc476 »

graycat wrote: post #132
jejones3141 wrote: post #109

Earlier quoted context omitted.

"heap" goes back at least to Algol 68, where you could write (using case stropping) REF INT i = HEAP INT; # sort of like C++ "new" # REF INT i = LOC INT; # allocates from the stack # or the shorter forms HEAP INT i; LOC INT i;

You got me! I wrote a little Algol 60 at one time and heard nice things about Algol 68 but never looked at it. Since heap is the word used in heap sort, it's fair to say that the second use of that word was a misuse. I don't know which use was second and don't really care but did want to know the details of the dynamic memory allocation used by the C malloc() and free(). I just would have appreciated an explanation o…

Um ... but K&R did. Chapter 8, section 7, "A Storage Allocator". Yes, it's simple, but it's there.

Re: Some dark corners of C

#140

Post by graycat »

nostrademons wrote: post #95
graycat wrote: post #94

Earlier quoted context omitted.

"On machines where pointers do not fit ints (basically all 64bit machines), you just silently (due to the cast there is no warning) truncated a pointer. Worse, it may work depending on the malloc implementation and how much memory you allocate." Wow! Ugly! Scary! Another good reason to know in fine details just what cast does. At one point, my Visual Basic .NET code actually calls some old C code, and in time I will…

Well, the bug only appears if you didn't include the header file declaring malloc (or any other void*-returning function). If you did, there's no problem. It's a pretty easy thing to leave out, missing a required header, but if you always compile under -Wall it'll catch this and many other problems as well.

Thanks for the details, but I remain concerned about taking a language, clearly with some tricky aspects, so closely identified with 16 and 32 bit computing into 64 bit computing.
Post reply on HN