I'm interested in learning about reverse engineering and malware analysis. Is learning C the proper first step in getting my hands dirty? I used C++ in a few college courses, but I've been primarily a Java developer for the past two years.
To become a good C programmer (2011)
71–80 of 106 posts
Re: To become a good C programmer (2011)
#72The more I learn C the more I hate it. At first it seems simple and easy but reading "Expert C Programming" is reading a laundry list of what's really messed up with the language. 80% of the problems would be solved by some sane syntactic sugar that compiles down to C
I would say generally I feel that way about any language I've learned. Initially they are pretty easy and the examples given include slick solutions to contrived problems. Then you get into wanting to do real work and you learn about all the corner cases and ambiguities and landmines that are hidden farther afield. Can anyone name a language that they've grown to like more the more they learned about it? I would gues…
I have really enjoyed Scala. The more depth I gain in the language, the more I appreciate it. It has the ability to be compact without being overly terse, and is very readable if you don't get too crazy with using symbol overloading and overly-complicated types.
Re: To become a good C programmer (2011)
#73I found that, after learning the basics of the language via K&R or a similar book, the best way to get a good understanding of C and its weird corner cases and eccentricities is just to go through the comp.lang.c FAQ page. http://c-faq.com/index.html It's pretty comprehensive, and I found the level was pretty good for a "not total newbie, but still not familiar with the subtilties" level that can be kind of hard to f…
Making a blogging engine in C would be very informative (though difficult).
it would be pretty easy to make one using c pre processor
Re: To become a good C programmer (2011)
#74Earlier quoted context omitted.
I think the style should be avoided; code shouldn't be compact and variable names should be descriptive. Artificial example: for( int i = 0 ; i should be: for( int count = 0 ; count It may be allowed to use i in place of count here, but this is the only place where single name variables should be permitted and only if i is really just a simple array index iterator.
I hope you don't have a stroke: https://github.com/jsoftware/jsource/blob/master/jsrc/cip.c ...just one of the many source files that make the interpreter for the J language.
The 'style' even leaked out to file naming: a.c, ab.c, af.c, am.c, c.c, ca.c, cc.c, cd.c, cf.c, ...
Brilliant!
I doubt that this is either serious (unobfuscated) or handwritten code though.
Re: To become a good C programmer (2011)
#75The more I learn C the more I hate it. At first it seems simple and easy but reading "Expert C Programming" is reading a laundry list of what's really messed up with the language. 80% of the problems would be solved by some sane syntactic sugar that compiles down to C
My guess is that liking/not liking 'C' depends on how interested you are in its representation model. If you're actively disinterested in how things work as bits in memory, then I can't blame you a ... bit.
I was actively interested how bits and hardware work, using Z80, 80x86, 68000, GW Basic, Turbo Basic, Turbo Pascal, Modula-2 and Oberon.
No need for C and its flaws.
Re: To become a good C programmer (2011)
#76Earlier quoted context omitted.
I am having trouble identifying "the LKML thread."
I think he meant this: https://lkml.org/lkml/2015/9/3/428 (It's Torvalds on a bug made harder to spot by using array arguments in C, which you shouldn't do.)
sorry for OT, but:
g+ share: 0, reddit share: 1k.
.. so I guess it becomes clear why Google is deemphasising this.
Re: To become a good C programmer (2011)
#77Earlier quoted context omitted.
I think the style should be avoided; code shouldn't be compact and variable names should be descriptive. Artificial example: for( int i = 0 ; i should be: for( int count = 0 ; count It may be allowed to use i in place of count here, but this is the only place where single name variables should be permitted and only if i is really just a simple array index iterator.
Even "i" can be changed to "index". My rule of thumb is this: If you wouldn't use the abbreviation when speaking, don't use it when coding. I don't understand why 'i' has been given a pass. The argument boils down to saved keystrokes. Typing is not the bottleneck.
> I don't understand why 'i' has been given a pass.
The reason is that in FORTRAN variables starting with i, j, k..n were defined as integers.
Back in the day I learned fortran first, then basic. People that learned basic first often would use the letter 'a' as a loop index instead of 'i'
Now days I still use 'i' but often use indx instead because my editor doesn't highlight single letter variables easily.
Re: To become a good C programmer (2011)
#78Earlier quoted context omitted.
I think the style should be avoided; code shouldn't be compact and variable names should be descriptive. Artificial example: for( int i = 0 ; i should be: for( int count = 0 ; count It may be allowed to use i in place of count here, but this is the only place where single name variables should be permitted and only if i is really just a simple array index iterator.
Even "i" can be changed to "index". My rule of thumb is this: If you wouldn't use the abbreviation when speaking, don't use it when coding. I don't understand why 'i' has been given a pass. The argument boils down to saved keystrokes. Typing is not the bottleneck.
> I don't understand why 'i' has been given a pass.
Because it is well enough established (in both programming and mathematics) that it communicates literally no less information to the reader than "iterator" or "index" would in the same context.
> The argument boils down to saved keystrokes.
Not at all. I, for one, find it easier to see the shape of the whole expression when the variable names are shorter.
Re: To become a good C programmer (2011)
#79Earlier quoted context omitted.
I think the style should be avoided; code shouldn't be compact and variable names should be descriptive. Artificial example: for( int i = 0 ; i should be: for( int count = 0 ; count It may be allowed to use i in place of count here, but this is the only place where single name variables should be permitted and only if i is really just a simple array index iterator.
Even "i" can be changed to "index". My rule of thumb is this: If you wouldn't use the abbreviation when speaking, don't use it when coding. I don't understand why 'i' has been given a pass. The argument boils down to saved keystrokes. Typing is not the bottleneck.
When I started to program in C I used "n" for the longest time, simple because it was quicker on to type on my first computer; "Next N" was a quick two taps on the N key.
Guess the platform :-)
Re: To become a good C programmer (2011)
#80Earlier quoted context omitted.
Making a blogging engine in C would be very informative (though difficult).
i think fefes cms is written in C... [1] [1] http://www.fefe.de/poweredby.html
Eeyup. A 2009 version is archived at https://erdgeist.org/cvsweb/Fefe/blog/blog.c
The best part is that where stores his posts. SQL? Nope. NoSQL? Nope. Plain text files? Nope. Fucking LDAP. [1]
[1] Source: http://blog.fefe.de/?ts=a8d61c27