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

Resume in C

gist.github.com

Post reply on HN
Print view View original

61–70 of 115 posts

Re: Resume in C

#61

Post by perdunov »

masklinn wrote: post #51
perdunov wrote: post #48

Earlier quoted context omitted.

char* points to some mutable buffer of char's that is supposed to be allocated somewhere. In this particular case they are assigned string literals, but in general it would be quite easy for someone to break consistency of allocations/deallocations in such code.

Given all unioned members are char*, where would the issue come from?

Say, somebody allocated one of the strings with malloc or strdup and put a free(), but mixed up when to call free() and when not.

Re: Resume in C

#62

Post by wrboyce »

nvader wrote: post #26

When I saw the title, I thought it was going to be about pausing and resuming a thread of execution or some stack. Could an editor put the slanty thing over the e in the title?

FYI the "slanty thing" is called an acute accent.

Re: Resume in C

#63

Post by perdunov »

malka wrote: post #49
masklinn wrote: post #46

Earlier quoted context omitted.

Surely it should be `thing_t* thing`!

thing_t* thing_ptr, thing imo, the star should be with the variable name. because, in this case, a reader could think that both thing_ptr and thing are pointer to a thing_t "thing_t thing_ptr, thing, other_thing_ptr" is imo more readable

If one uses the entity* notation, they must always declare each variable with a separate declaration, that is:

  thing_t* ptr1;
  thing_t* ptr2;
not

  thing_t* ptr1, ptr2 /*

Re: Resume in C

#64

Post by wschroed »

Aldo_MX wrote: post #5

Wow, I didn't know this was valid C code, it's pretty convenient. school_t uiuc = { .school = "University of Illinois at Urbana-Champaign", .location = "Urbana, IL", .program = "BS Computer Science", .started = 1251158400, .left = 1336608000, .accomplishments = { "Minor in International Studies in Engineering, Japan", "Focused on systems software courses", NULL } };

I highly recommend "21st Century C" (http://shop.oreilly.com/product/0636920025108.do) as a tour of modern C programming, including use of C99 features. It goes over C tooling (profiling, debugging, testing, cross-platform deployment), and explores C99.

Re: Resume in C

#65

Post by masklinn »

perdunov wrote: post #61
masklinn wrote: post #51

Earlier quoted context omitted.

Given all unioned members are char*, where would the issue come from?

Say, somebody allocated one of the strings with malloc or strdup and put a free(), but mixed up when to call free() and when not.

OK but that's an issue with using char* where does the union issue come in? I could understand an issue with a union between char* and, say, int or some other pointer, but I don't see what specific issue would arise from a union between the exact same pointer types.

Re: Resume in C

#66

Post by perdunov »

masklinn wrote: post #50
perdunov wrote: post #47

Earlier quoted context omitted.

There are three data structures unsystematically blended into one (that is, one cannot unambiguously tell which fields go into which "virtual" type, and cannot formally check the correctness). The name thing_t is indicative that you indeed cannot really tell what that entity is. This kind of data structure design begs for errors, while being conceptually wrong.

> There are three data structures unsystematically blended into one The point is that they're not three completely separate data structures, they're a single data structure with context-dependent field labelling.

I get your point, but how to tell "labelling" from typing? Typing depends on semantics. This particular example only works out because the types are all strings, which is a case of sort of loose typing often used in programming. It could've been like this:

  typedef struct {
	union {
		company_t * company;
		school_t * school;
		project_t * project;
	};
	union {
		address_t * location;
		url_t * url;
	};
etc.

Re: Resume in C

#67

Post by lukeasrodgers »

newobj wrote: post #2

--- a/resume.c +++ b/resume.c @@ -118,7 +118,7 @@ void print_job(job_t * job) { } } -int main(int argc, char * argv) { +int main(int argc, char ** argv) { int i = 0; while (jobs[i]) { @@ -127,4 +127,4 @@ int main(int argc, char * argv) { } return 0; -} \ No newline at end of file +}

For those who don't write C, could you explain what is significant about this change? I'm guessing the earlier version was some kind of subtle bug?

Re: Resume in C

#69

Post by bane »

This is great fun, which comes along at a nice time since I'm working through an intro to C class to revive some very stale "real language" skills I've lost years ago. I've studied through some basic dynamic data structures (linked-lists, binary trees, etc.) and was quite surprised at both how much of this I could follow AND how much I learned.

Re: Resume in C

#70

Post by tcas »

lukeasrodgers wrote: post #67
newobj wrote: post #2

--- a/resume.c +++ b/resume.c @@ -118,7 +118,7 @@ void print_job(job_t * job) { } } -int main(int argc, char * argv) { +int main(int argc, char ** argv) { int i = 0; while (jobs[i]) { @@ -127,4 +127,4 @@ int main(int argc, char * argv) { } return 0; -} \ No newline at end of file +}

For those who don't write C, could you explain what is significant about this change? I'm guessing the earlier version was some kind of subtle bug?

  char * argv
is a pointer to a string (or a single character).

  char ** argv
is a pointer to an array of pointers to strings. The latter is used since it allows for multiple arguments in (the number being `int argc`).

This picture shows the second example in terms of pointers:

http://www.londonquilters.org.uk/ctext/pic511.gif

Post reply on HN