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

C for high level programmers (slides)

charliethe.ninja

Post reply on HN
Print view View original

81–90 of 129 posts

Re: C for high level programmers (slides)

#81

Post by xamuel »

kyllo wrote: post #52
andrepd wrote: post #21

Earlier quoted context omitted.

If you want arrays of variables, you need pointers. It's not enough to know the value of an int (the first element of the array), but you need the pointer to an int (pointer to the first element of the array). Now you can increment the pointer to go to the next element. You couldn't do this with a simple value. Also, suppose you want to pass a variable of a large data type, like an image, to a function. Instead of co…

Of course the problem is, if you're passing a pointer to a data structure to a function, the function doesn't know the size of the data structure unless you pass that as another argument.

You meant to say, "if you're passing a pointer to an array to a function, the function doesn't know the size of the array unless you pass that as another argument".

When passing a (pointer to a) data structure to a function, in 99.99% of cases there's only one data structure you'd pass, and you build this into the function's prototype, e.g.,

  int myfunction( struct my_structure *x )
instead of

  int myfunction( void *x )
and so, yes, the function does know the size of the structure. And in the case of arrays, often it's enough to mark the end of the array (with '\0' in the case of char arrays or NULL in the case of pointer arrays), I'd only roll my sleeves up and worry about minimizing length calculations if I had actually done some profiling and determined that such nitty-gritty optimization was needed (it rarely is).

Re: C for high level programmers (slides)

#82

Post by ndesaulniers »

TheAceOfHearts wrote: post #27

I think the problem with learning C is that you need to learn stuff like make, autoconf, how the compiler + preprocessors work (what do all those flags even mean!?), how making "cross-platform" stuff works, how to pull in and use "libraries", C-isms, how to test, etc. C itself is a very small and simple language, but the tooling and patterns are old and mysterious. In college I learned how to program embedded systems…

My recommendations (I've read a lot of C books), I think you can get away with just these two:

* Head First C - David Griffiths

* Expert C Programming: Deep C Secrets - Peter Van Der Linden

Re: C for high level programmers (slides)

#83

Post by ndesaulniers »

gshrikant wrote: post #59

As someone who occasionally dabbles in C code, I am interested in knowing what is the modern take on `goto`s. I know they are "harmful" but I often come across code riddled with goto statements [1] and I personally feel that as long as it makes the code readable without significantly obfuscating the logic, goto is a perfectly fine way of doing things (although popular opinion and consideration for best practices have…

Without having RAII from C++/Rust, it's really tricky to correctly release resources when something exceptional happens.

Re: C for high level programmers (slides)

#84

Post by masklinn »

mappu wrote: post #67
halayli wrote: post #17

teaching C and not checking malloc, bad idea. using realloc in the way its used in this "tutorial" can cause memory leaks. realloc should be checked before reassigned because it can return NULL and that will overwrite the previous valid memory address.

>teaching C and not checking malloc, bad idea On Linux, malloc will appear to give you memory even if there is none left to give, so checking the error is not important.

An issue which is not linux specific is when calculating the size of an array allocation you can overflow size_t. So when mallocing arrays, you're supposed to check the computed size for overflow (or use calloc(3) or OpenBSD/libbsd's reallocarray(3) instead).

Re: C for high level programmers (slides)

#85

Post by pjc50 »

TheAceOfHearts wrote: post #27

I think the problem with learning C is that you need to learn stuff like make, autoconf, how the compiler + preprocessors work (what do all those flags even mean!?), how making "cross-platform" stuff works, how to pull in and use "libraries", C-isms, how to test, etc. C itself is a very small and simple language, but the tooling and patterns are old and mysterious. In college I learned how to program embedded systems…

I reccomend "Programming in the UNIX Environment" by Kernighan and Pike. Partly because it was written so soon after UNIX and C themselves, it has very little of the modern 'cruft' in it. It's at the level of "cc program.c -o program".

Make is fairly easy to learn, at least in its basic form. Autoconf is horrendous.

Re: C for high level programmers (slides)

#86

Post by pjc50 »

NhanH wrote: post #47
fr0styMatt2 wrote: post #43

Earlier quoted context omitted.

My pet hate is #include files. The whole way that C handles multiple source files just seems archaic to me, having worked in higher-level languages. I wish C had a proper package system that was standard, so I don't have to mess around with things like include file path order (or my favorite, the C++ template definitions having to be in the header files thing I only recently learned about).

Interestingly, I first started with C (although I haven't written a line of C code for a long time), and when I first move to higher-level languages, I dislike the fact that I have no idea where the file I just imported is. Moreso when I'm playing with obscure/ new language: if I can just import whatever files I wanted (rather than at package level), it seems that would be much easier to hack on the language/std itse…

I have no idea where the file I just imported is

A sufficiently long include path can give you this problem anyway. I recently tripped over this when I created a "reason.h" and discovered that Windows had a file of the same name deep inside MFC.

Re: C for high level programmers (slides)

#88

Post by inglor »

Why do presentations always get interpreted vs compiled wrong? It's not a property of a language it's a property of the runtime. For example Java is interpreted on old versions, JIT compiled on the desktop and compiled AoT in Android...

Re: C for high level programmers (slides)

#89

Post by xcogiz »

TheLoneWolfling wrote: post #51
missblit wrote: post #45

Earlier quoted context omitted.

Not only can the compiler make it false. It can assume that the code would never make the comparison in the first place, and optimize away any cases where the undefined behavior is guaranteed to be triggered. So in a sense undefined behavior can travel back in time :O

Yep. It's impossible to have actual modular code in C. A real shock for people coming from higher level languages.

What exactly do you mean by modular code in your context?

edit: Oh, you probably meant modules integrated directly in the language. I was surprised to read that since modular design is highly successful and useful in C.

Re: C for high level programmers (slides)

#90

Post by pdw »

mappu wrote: post #67
halayli wrote: post #17

teaching C and not checking malloc, bad idea. using realloc in the way its used in this "tutorial" can cause memory leaks. realloc should be checked before reassigned because it can return NULL and that will overwrite the previous valid memory address.

>teaching C and not checking malloc, bad idea On Linux, malloc will appear to give you memory even if there is none left to give, so checking the error is not important.

Not checking malloc's return value can easily lead to security vulnerabilities, particularly in bytecode interpreters and things like that.

The basic plan is simple: Trick the target program into allocating an impossible huge block of memory (e.g. 3 gigabyte on a 32 bit system). Malloc will return NULL but the program blindly assumes the allocation has succeeded. Now use carefully chosen indices to read and write whatever memory you want.

As an example, here's a classic Flash exploit that used this technique: http://chargen.matasano.com/chargen/2007/7/27/this-new-vulne...

Really, xmalloc is five lines of code. Just use it.

    void *xmalloc(size_t size) {
      void *ptr = malloc(size);
      if (!ptr) abort();
      return ptr;
    }
Post reply on HN