home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / phrack2 / phrack52.001 < prev    next >
Encoding:
Text File  |  2003-06-11  |  11.6 KB  |  217 lines
  1.  
  2. ---[  Phrack Magazine   Volume 8, Issue 52 January 26, 1998, article 01 of 20
  3.  
  4.  
  5. -------------------------[  P H R A C K     5 2     I N D E X
  6.  
  7.  
  8. --------[  Choose your own $PATH adventure
  9.  
  10.  
  11.  
  12.     Whew.  You would be quite surprised at the evil wheels I had to set in
  13. motion in order to get this issue out.  According to Newton, a Phrack Issue
  14. remains at rest or continues to move in a straight line with a uniform
  15. velocity if there is no unbalanced force acting on it.  This issue was at rest.
  16. Its velocity was constant.  And there were few forces acting on it.  Anyhow,
  17. after many machinations it's here.  Enjoy.
  18.  
  19.     I have a gripe.  Something upon which I'd like dwell for a spell.  Let's
  20. talk about coding aesthetic (from the C programming standpoint).  Now, this is
  21. not a harangue about effective coding or efficient coding, I'll save those for
  22. some other time (perhaps for the time when I feel I can write effective and
  23. efficient code proficiently enough to vituperate to those who do not).  I
  24. want to touch down on a few topics of visual appeal, which are overlooked so
  25. often.
  26.  
  27.     The five major areas I will cover are indentation, brace placement,
  28. use of whitespace, commenting, as well as variable and function nomenclature.
  29. I suppose I should also mention that coding style is a personal preference
  30. type of thing.  There are all kinds of schools of thought out there, and all
  31. kinds of methodologies on how to write pretty code.  In the grand scheme of
  32. things, none are really any more correct than any others, except mine.
  33.  
  34.     C is, for the most part, a format free programming language.  Code can be
  35. written with all manner of whitespace, tabs, and newlines.  The compiler
  36. certainly doesn't care.  The machine doesn't care.  This can be a double
  37. edged sword.  There is quite a bit of room for artistic interpretation.  And
  38. just like in real life, there is a lot of crappy art out there.
  39.  
  40.     Indenting your code is a must.  Please, do this.  Indentation is here for
  41. one simple reason: to clearly and unequivocally define blocks of control.
  42. However, 8 space tabstops are overkill.  Unless you are using a 2 point font on
  43. a 13" screen, 4 spaces should easily define your control blocks.  This allows
  44. you to maintain clarity on an 80 column screen while nesting blocks of control
  45. much deeper then you would with 8 space tab stops.  2 space tabstop advocates
  46. should be shot.  However, don't let typography take over your code (ala ink
  47. obscuring the intent).  If you have 7 million levels of indentation, perhaps
  48. you should rethink your approach to tackling the problem...
  49.  
  50.     Bracing has a simple solution.  The most effective use of bracing is in
  51. placing them on newlines so that they neatly enclose the area of control.  This
  52. is especially important with nested levels of control.  I know this generates
  53. empty lines.  Oh well.  They're free.  Blocks of control become easily visible
  54. and it is easy to isolate one from another.  This goes for functions as well
  55. as conditionals and loop structures.  I know I go against K&R here.  Oh well.
  56.  
  57.     In the pursuit of clear, readable code, whitespace is your friend.  Single
  58. space all keywords and all variables and constants separated by commas.  It's
  59. a simple thing to do to drastically improve readability.  When you have a
  60. series of assignments, one after another, it's a nice touch to line them up on
  61. the closest relative 4 space boundary.  And please, no spaces between structure
  62. pointer operators and structure contents.
  63.  
  64.     Commenting is a delicate matter.  Descriptive, concise, well written code
  65. shouldn't really need commenting, or at least very much of it.  But this isn't
  66. a rant about descriptive, concise, well written code.  If you feel the need
  67. to comment your code, follow a few simple rules:
  68.     - Keep the comment block as small as possible.
  69.     - Don't tab out your comment frames to line up with each other.  That's
  70.       just plain fucking annoying.  If you're doing that, you have too many
  71.       comments anyway.
  72.     - Commenting datatype declarations rather then the functions that
  73.       manipulate them is usually more helpful.
  74.     - If you must comment, keep your style as consistent as possible.  If the
  75.       commenting detracts from the readibilty of your code, you've just ponied
  76.       up any clarification you might have achieved with the commenting.
  77.  
  78.     The major exception to these rules are file headers.  The beginning of
  79. source and header files should always have some descriptive information,
  80. including: file name, author, purpose, modification dates, etc...  These
  81. comment blocks should always have a simple vertical line of unobtrusive
  82. astricks, framed with the required forward slashes.  People using C++ style
  83. commenting in C programs should be drawn and quartered.
  84.  
  85.     The other exception to this rule is when you are writing code specifically
  86. for the benefit of others.  If the code is intended to be a learning tool, 
  87. copious commenting is allowable.
  88.  
  89.     Variable and function nomenclature should have connotation as to what their
  90. purpose in life is.  As short as possible while still preserving some sort of
  91. identity.  Descriptive names are wonderful, but don't go overboard.  Generally,
  92. a condensed one or two word descriptor (possiblely connected via an underscore)
  93. will work fine.  And please, no mixed case.  The only time uppercase characters
  94. should appear in C code are in symbolic constants and macros (and possibly
  95. strings and comments).
  96.  
  97.  
  98.     This tirade is the result of my experiences in reading and writing C code.
  99. In my travels as a stalwart mediocre programmer, I have progressed through many
  100. levels of maturity in my programming style.  Much of my old code exhibits many
  101. of the very things eschewed as anathema in this jeremiad.  Well, what can I
  102. say?  I believe that I have grown.  I am at home with the me.  This is me
  103. breathing.  (Tell me what movie that's from, and I will give you a Phrack
  104. Donut.)
  105.  
  106.  
  107. Enjoy the magazine.  It is by and for the hacking community.  Period.
  108.  
  109.  
  110. -- Editor in Chief ----------------[  route
  111. -- Director of Public Operations --[  dangergirl
  112. -- Phrack World News --------------[  disorder
  113. -- Werdsmith ----------------------[  loadammo
  114. -------- Elite -------------------->  asriel
  115. -- Santa vs. Jesus ----------------[  ISS vs. SNI
  116. -- Festively Plump ----------------[  Cartman
  117. -- Extra Special Thanks -----------[  No one.
  118. -- Official Phrack CD -------------[  FLA/Flavour of the Weak
  119. -- Official Phrack Drink ----------[  `The C Kilborn` (2.9 parts ketel one,
  120. -----------------------------------|  .1 parts tonic)
  121. -- Shout Outs and Thank Yous ------[  Lords of Acid, cantor, Yggdrasil,
  122. -----------------------------------|  snokerash, Voyager, TNO, Jeff Thompson,
  123. -----------------------------------|  angstrom, redragon, Rob Pike, halflife
  124. -- B.A. Baracus Phrack Fracas -----[  loadammo vs. Death Veggie
  125. -- Original flip.c author (props) -[  datagram
  126. -- Gas Face Given (drops) ---------[  solo, klepto
  127.  
  128. Phrack Magazine V. 8, #52, January 26, 1998.  ISSN 1068-1035
  129. Contents Copyright (c) 1998 Phrack Magazine. All Rights Reserved.  Nothing
  130. may be reproduced in whole or in part without written permission from the
  131. editor in chief.  Phrack Magazine is made available quarterly to the public,
  132. free of charge.  Go nuts people.
  133.  
  134.  
  135. Subscription requests, articles, comments, whatever should be directed to:
  136.  
  137.                 phrackedit@phrack.com
  138.  
  139. Submissions to the above email address may be encrypted with the following key:
  140.  
  141. -----BEGIN PGP PUBLIC KEY BLOCK-----
  142. Version: 2.6.2
  143.  
  144. mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW
  145. ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O
  146. vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j
  147. 0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W
  148. DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG
  149. /v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0GjxwaHJhY2tlZGl0QGlu
  150. Zm9uZXh1cy5jb20+tA9QaHJhY2sgTWFnYXppbmU=
  151. =1iyt
  152. -----END PGP PUBLIC KEY BLOCK-----
  153.                    
  154. As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED.  Phrack goes out 
  155. plaintext.  You certainly can subscribe in plaintext.
  156.  
  157. phrack:~# head -20 /usr/include/std-disclaimer.h
  158. /*
  159.  *  All information in Phrack Magazine is, to the best of the ability of the 
  160.  *  editors and contributors, truthful and accurate.  When possible, all facts
  161.  *  are checked, all code is compiled.  However, we are not omniscient (hell,
  162.  *  we don't even get paid).  It is entirely possible something contained 
  163.  *  within this publication is incorrect in some way.  If this is the case, 
  164.  *  please drop us some email so that we can correct it in a future issue.  
  165.  *
  166.  *
  167.  *  Also, keep in mind that Phrack Magazine accepts no responsibility for the
  168.  *  entirely stupid (or illegal) things people may do with the information
  169.  *  contained here-in.  Phrack is a compendium of knowledge, wisdom, wit, and
  170.  *  sass.  We neither advocate, condone nor participate in any sort of illicit 
  171.  *  behavior.  But we will sit back and watch.
  172.  *
  173.  *
  174.  *  Lastly, it bears mentioning that the opinions that may be expressed in the
  175.  *  article of Phrack Magazine are intellectual property of their authors.
  176.  *  These opinions do not necessarily represent those of the Phrack Staff.
  177.  */
  178.  
  179. -------------------------[  T A B L E   O F   C O N T E N T S
  180.  
  181.  1 Introduction                                            Phrack Staff   12K
  182.  2 Phrack Loopback                                         Phrack Staff   60K
  183.  3 Line Noise                                              various        79K
  184.  4 Phrack Prophile on o0                                   Phrack Staff   07K
  185.  5 Everything a hacker needs to know about getting busted  Agent Steal    72K
  186.  6 Hardening the Linux Kernel                              daemon9        42K
  187.  7 The Linux pingd                                         daemon9        17K
  188.  8 Steganography Thumbprinting                             anonymous      35K
  189.  9 On the Morality of Phreaking                            Phrack Staff   19K
  190. 10 A Quick NT Interrogation Probe                          twitch         18K
  191. 11 Subscriber Loop Carrier                                 voyager        48K
  192. 12 Voice Response Systems                                  voyager        18K
  193. 13 Pay Per View (you don't have to)                        cavalier       19K
  194. 14 The International Crime Syndicate Association           D. Demming     20K
  195. 15 Digital Certificates                                    Yggdrasil      14K
  196. 16 Piercing Firewalls                                      bishnu         31K
  197. 17 Protected mode programming and O/S development          mythrandir     76K
  198. 18 Weakening the Linux Kernel                              plaguez        27K
  199. 19 Phrack World News                                       Disorder       64K
  200. 20 extract.c                                               Phrack Staff   08K
  201.  
  202.                                                                          687K
  203.  
  204. -----------------------------------------------------------------------------
  205.  
  206.     When Sen. Bob Kerrey (D-Neb.) was asked to define encryption, the results 
  207. were horrific.  "Well, I mean, to answer your question, I mean, encryption is 
  208. -- the political equivalent of encryption is you ask me a question, I give you
  209. an answer and you don't understand it," he managed. "I mean, I intentionally 
  210. garble the answer frequently.  I intentionally garble the response so that you 
  211. can't understand what I'm saying.  And that's -- you notice that I've got the
  212. ability to do that." 
  213.  
  214. -----------------------------------------------------------------------------
  215.  
  216. ----[  EOF
  217.