Live data from Hacker News

Resume in C

gist.github.com

51–60 of 115 posts

Re: Resume in C

#51
post #45

Earlier quoted context omitted.

Why is putting char* into a union a bad idea?

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?

Re: Resume in C

#53
post #6

It's cheeky, but then again it is a project you can show someone. Graphic designers get to make fancy schmancy resumes to impress their potential employers, so why not programmer? Better make sure there are no bugs in it though.

Ah nothing like handing your resume over to a prospective employer and having it SEGFAULT

If they'll run unknown code without checking it first that's something you'd want to know about.

Re: Resume in C

#54

Earlier quoted context omitted.

what does that even mean? Isn't C99 an extension of C90/ANSI? Doesn't GCC support the whole of C99 as an extension to ANSI?

It means that GCC will allow/support this even if you set it to std=c89 or std=c90.

Won't that only be supported in gnu89 or gnu90 mode?

Re: Resume in C

#56

Earlier quoted context omitted.

It's subjective. It feels more c like and natural to me to write while (foo->bar) and not while (foo[i].bar). The latter feels like the way you would do it somewhere else, grafted onto C. But it's not wrong, I don't have deep qualms with it, and that's why I put it last on my list.

It's not subjective. Intel's guidelines for writing vectorizable code: Prefer array notation to the use of pointers. C programs in particular impose very few restrictions on the use of pointers; aliased pointers may lead to unexpected dependencies. Without help, the compiler often cannot tell whether it is safe to vectorize code containing pointers. Source: https://software.intel.com/sites/default/files/8c/a9/Compile…

yep - signal your intentions as specifically to the compiler as possible, so that it can generate as optimized output as possible.

Array access is more specific and intentional than pointer arithmetic.

Re: Resume in C

#57
post #55

For bonus points (or not, depending on the recipient's sense of humour) construct a resume that would be suitable for the underhanded C contest ( http://www.underhanded-c.org/ ).

that would be an interesting way for malware to enter - you submit a seemingly innocent resume in C, ask the reader to compile it to see it in pretty colours/formatting. And subtlety pwning the machine in the process.

Re: Resume in C

#58

Earlier quoted context omitted.

It's supported by GCC as an extension to C90 too.

what does that even mean? Isn't C99 an extension of C90/ANSI? Doesn't GCC support the whole of C99 as an extension to ANSI?

C99 is not a strict extension, but as stated in its foreword, "this second edition [C99] cancels and replaces the first edition [C90]".

For instance, implicit function declarations are allowed in C90 but not in C99.

Re: Resume in C

#59

Code review: * The struct members and variables pointing at string literals should be const. * People do break this all the time but typedefs ending in _t are reserved by POSIX. * Your C99 style struct initializers are valid but it's notable that one popular compiler, MSVC, will not like them. * If we are being idiomatic I would suggest pointer arithmetic to iterate instead of using a counter i.

Style review:

* Avoid using NULL in your resume. It has a negative connotation, and makes your resume look bad.

* Make use of as many existing libraries as possible, to show that you're not the kind of programmer that wants to invent the wheel on every occasion.

* Try to obfuscate your resume a little (but not too much!) As it is written here, your reader can easily guess what the program will do, and he/she will not even want to run it anymore.

* #include a portfolio of your work inside your resume.

Re: Resume in C

#60

Earlier quoted context omitted.

It means that GCC will allow/support this even if you set it to std=c89 or std=c90.

Won't that only be supported in gnu89 or gnu90 mode?

No, it will be supported using -std=c89 or -std=90, unless you also specify -pedantic.
Post reply on HN