home *** CD-ROM | disk | FTP | other *** search
/ Mac-Source 1994 July / Mac-Source_July_1994.iso / Information / comp.lang.c / C-FAQ-list.diff < prev    next >
Encoding:
Internet Message Format  |  1994-06-01  |  16.9 KB  |  [TEXT/R*ch]

  1. Path: bloom-beacon.mit.edu!news.media.mit.edu!uhog.mit.edu!news.kei.com!babbage.ece.uc.edu!mary.iia.org!rtp.vnet.net!news.sprintlink.net!connected.com!beauty!rwing!eskimo!scs
  2. From: scs@eskimo.com (Steve Summit)
  3. Newsgroups: comp.lang.c,comp.answers,news.answers
  4. Subject: comp.lang.c Changes to Answers to Frequently Asked Questions (FAQ)
  5. Message-ID: <1994May01.0300.scs.0001@eskimo.com>
  6. Date: 1 May 94 10:00:53 GMT
  7. Sender: scs@eskimo.com (Steve Summit)
  8. Reply-To: scs@eskimo.com
  9. Followup-To: poster
  10. Organization: none, at the moment
  11. Lines: 407
  12. Approved: news-answers-request@MIT.Edu
  13. X-Archive-Name: C-faq/diff
  14. Xref: bloom-beacon.mit.edu comp.lang.c:39866 comp.answers:5147 news.answers:18923
  15.  
  16. Archive-name: C-faq/diff
  17. Comp-lang-c-archive-name: C-FAQ-list.diff
  18.  
  19. This article contains a massaged diff list comparing the previous
  20. revision of the comp.lang.c frequently-asked questions list
  21. (last modified March 1, 1994, last posted April 1) and the
  22. current one.  Due to the massaging (which is intended to make the
  23. changes easier to see), this list is not suitable for input to a
  24. patch program.
  25.  
  26. As usual, there are more changes in the works than are reflected
  27. in this month's posting.  If you have made a suggestion or
  28. correction which you think vital, but which you do not see here,
  29. don't panic: though the mills of FAQ list revision grind slowly,
  30. yet they grind exceeding fine (with apologies to von Logau).
  31.  
  32. ==========
  33. < [Last modified March 1, 1994 by scs.]
  34. ---
  35. > [Last modified April 16, 1994 by scs.]
  36. ==========
  37.   1.5:    If NULL were defined as follows:
  38.  
  39. <         #define NULL (char *)0
  40. ---
  41. >         #define NULL ((char *)0)
  42. ==========
  43.   A:    This message, which occurs only under MS-DOS (see, therefore,
  44. <     section 16) means that you've written, via a null pointer, to
  45. <     location zero.
  46. ---
  47. >     section 16) means that you've written, via an unintialized
  48. >     and/or null pointer, to location zero.
  49. ==========
  50. < A:    There is no single perfect method.  Given a function f1()
  51. <     similar to the f() of question 2.10, the array as declared in
  52. <     question 2.10, f2() as declared in question 2.11, array1,
  53. <     array2, array3, and array4 as declared in question 2.14, and a
  54. <     function f3() declared as:
  55. <         f3(pp, m, n)
  56. <         int **pp;
  57. <         int m, n;
  58. <
  59. <     ; the following calls should work as expected:
  60. ---
  61. > A:    There is no single perfect method.  Given the declarations
  62. >         int array[NROWS][NCOLUMNS];
  63. >         int **array1;
  64. >         int **array2;
  65. >         int *array3;
  66. >         int (*array4)[NCOLUMNS];
  67. >     as initialized in the code fragments in questions 2.10 and 2.14,
  68. >     and functions declared as
  69. >         f1(int a[][NCOLUMNS], int m, int n);
  70. >         f2(int *aryp, int nrows, int ncolumns);
  71. >         f3(int **pp, int m, int n);
  72. >
  73. >     (see questions 2.10 and 2.11), the following calls should work
  74. >     as expected:
  75. ==========
  76.   A:    Did the function try to initialize the pointer itself, or just
  77.     what it pointed to?  Remember that arguments in C are passed by
  78.     value.  The called function altered only the passed copy of the
  79. <     pointer.  You'll want to pass the address of the pointer (the
  80. <     function will end up accepting a pointer-to-a-pointer).
  81. ---
  82. >     pointer.  You'll either want to pass the address of the pointer
  83. >     (the function will end up accepting a pointer-to-a-pointer), or
  84. >     have the function return the pointer.
  85. ==========
  86. <     Note that this example also uses fgets instead of gets (always a
  87. <     good idea; see question 11.5), allowing the size of the array to
  88. ---
  89. >     Note that this example also uses fgets() instead of gets()
  90. >     (always a good idea; see question 11.6), allowing the size of
  91. ==========
  92.     The programmer must arrange (explicitly) for sufficient space
  93.     for the results of run-time operations such as string
  94.     concatenation, typically by declaring arrays, or by calling
  95. <     malloc.
  96. ---
  97. >     malloc.  (See also question 17.20.)
  98. ==========
  99.   A:    Make sure that the memory to which the function returns a
  100.     pointer is correctly allocated.  The returned pointer should be
  101.     to a statically-allocated buffer, or to a buffer passed in by
  102. <     the caller, but _not_ to a local (auto) array.  In other words,
  103. <     never do something like
  104. ---
  105. >     the caller, or to memory obtained with malloc(), but _not_ to a
  106. >     local (auto) array.  In other words, never do something like
  107. ==========
  108. <     One fix would to to declare the buffer as
  109. ---
  110. >     One fix (which is imperfect, especially if f() is called
  111. >     recursively, or if several of its return values are needed
  112. >     simultaneously) would to to declare the buffer as
  113.  
  114.             static char buf[10];
  115. ==========
  116.   A:    Before ANSI/ISO Standard C introduced the void * generic pointer
  117.     type, these casts were typically required to silence warnings
  118. <     about assignment between incompatible pointer types.
  119. ---
  120. >     about assignment between incompatible pointer types.  (Under
  121. >     ANSI/ISO Standard C, these casts are not required.)
  122. ==========
  123.   A:    Most implementations of malloc/free do not return freed memory
  124.     to the operating system (if there is one), but merely make it
  125. <     available for future malloc calls.
  126. ---
  127. >     available for future malloc calls within the same process.
  128. ==========
  129.   A:    There is a special exception for those operators, (as well as
  130. <     ?: ); each of them does imply a sequence point (i.e. left-to-
  131. ---
  132. >     the ?: operator); each of them does imply a sequence point (i.e.
  133. ==========
  134.     hand-side.  Use an explicit cast to force long arithmetic:
  135.  
  136.         long int c = (long int)a * b;
  137.  
  138. >     Note that the code (long int)(a * b) would _not_ have the
  139. >     desired effect.
  140. ==========
  141.   5.13:    Is exit(status) truly equivalent to returning status from main?
  142.  
  143. < A:    Essentially, except under a few older, nonconforming systems,
  144. <     and unless data local to main might be needed during cleanup
  145. <     (due perhaps to a setbuf or atexit call).
  146. ---
  147. > A:    Formally, yes, although discrepancies arise under a few older,
  148. >     nonconforming systems, or if data local to main() might be needed
  149. >     during cleanup (due perhaps to a setbuf or atexit call), or if
  150. >     main() is called recursively.
  151. ==========
  152.     Before performing arithmetic, cast the pointer either to char *
  153. <     or to the type you're trying to manipulate.
  154. ---
  155. >     or to the type you're trying to manipulate (but see question
  156. >     2.18).
  157. ==========
  158. < 5.22:    What does #pragma once mean?  I found it in some header files.
  159. ---
  160. > 5.22:    What does "#pragma once" mean?  I found it in some header files.
  161. ==========
  162.   6.9:    How can I list all of the pre#defined identifiers?
  163.  
  164. < A:    There's no standard way, although it is a frequent need.  The
  165. <     most expedient way is probably to extract printable strings from
  166. <     the compiler or preprocessor executable with something like the
  167. <     Unix strings(1) utility.
  168. ---
  169. > A:    There's no standard way, although it is a frequent need.  If the
  170. >     compiler documentation is unhelpful, the most expedient way is
  171. >     probably to extract printable strings from the compiler or
  172. >     preprocessor executable with something like the Unix strings(1)
  173. >     utility.  Beware that many traditional system-selective
  174. >     pre#defined identifiers (e.g. "unix") are non-Standard (because
  175. >     they clash with the user's namespace) and are being removed or
  176. >     renamed.
  177. ==========
  178.     A good rule of thumb is to use TRUE and FALSE (or the like) only
  179. <     for assignment to a Boolean variable, or as the return value
  180. <     from a Boolean function, never in a comparison.
  181. ---
  182. >     for assignment to a Boolean variable or function parameter, or
  183. >     as the return value from a Boolean function, but never in a
  184. >     comparison.
  185. ==========
  186.   10.6:    My compiler is complaining about an invalid redeclaration of a
  187.     function, but I only define it once and call it once.
  188.  
  189. < A:    If the first call precedes the definition, the compiler will
  190. <     assume a function returns an int.  Non-int functions must be
  191. ---
  192. > A:    Functions which are called without a declaration in scope (or
  193. >     before they are declared) are assumed to be declared as
  194. >     returning int, leading to discrepancies if the function is later
  195. >     declared otherwise.  Non-int functions must be declared before
  196. >     they are called.
  197. ==========
  198. < 11.1:    Why doesn't this code:
  199. <
  200. <        char c;
  201. <        while((c = getchar()) != EOF)...
  202. <
  203. <     work?
  204. ---
  205. > 11.1:    What's wrong with this code:
  206. <
  207. <        char c;
  208. <        while((c = getchar()) != EOF)...
  209. ==========
  210.     through a char,
  211.     either a normal character might be misinterpreted as EOF, or the
  212. <     EOF might be altered and so never seen.
  213. ---
  214. >     EOF might be altered (particularly if type char is unsigned) and
  215. >     so never seen.
  216. ==========
  217. > 11.2:    How can I print a '%' character in a printf format string?  I
  218. >     tried \%, but it didn't work.
  219. > A:    Simply double the percent sign: %% .
  220. >     References: K&R I Sec. 7.3 p. 147; K&R II Sec. 7.2 p. 154; ANSI
  221. >     Sec. 4.9.6.1 .
  222. 2575c2585
  223. < 11.9:    I'm trying to update a file in place, by using fopen mode "r+",
  224. ---
  225. > 11.10:    I'm trying to update a file in place, by using fopen mode "r+",
  226. ==========
  227.   A:    Be sure to call fseek before you write, both to seek back to the
  228.     beginning of the string you're trying to overwrite, and because
  229.     an fseek or fflush is always required between reading and
  230. <     writing in the read/write "+" modes.
  231. ---
  232. >     writing in the read/write "+" modes.  Also, remember that you
  233. >     can only overwrite characters with the same number of
  234. >     replacement characters; see also question 17.4.
  235. ==========
  236.         int mystructcmp(p1, p2)
  237.         char *p1, *p2;        /* const void * for ANSI C */
  238.         {
  239.             struct mystruct *sp1 = (struct mystruct *)p1;
  240.             struct mystruct *sp2 = (struct mystruct *)p2;
  241. <             /* now compare sp1->whatever and *sp2-> ... */
  242. ---
  243. >             /* now compare sp1->whatever and sp2-> ... */
  244. ==========
  245.   12.7:    How can I add n days to a date?  How can I find the difference
  246.     between two dates?
  247.  
  248.   A:    The ANSI/ISO Standard C mktime and difftime functions provide
  249. <     support for both problems.  mktime accepts non-normalized dates,
  250. ---
  251. >     some support for both problems.  mktime() accepts non-normalized
  252. ==========
  253. <     dates to be subtracted.  (Note, however, that these solutions
  254. <     only work for dates which can be represented as time_t's.)  See
  255. <     also questions 12.6 and 17.28.
  256. ---
  257. >     time_t values for two dates to be subtracted.  (Note, however,
  258. >     that these solutions only work for dates in the range which can
  259. >     be represented as time_t's, and that not all days are 86400
  260. >     seconds long.)  See also questions 12.6 and 17.28.
  261. ==========
  262. < 12.12: I'm trying to port this    A:  These routines are variously
  263. <     old program.  Why do I            obsolete; you should
  264. <     get "undefined external"        instead:
  265. ---
  266. > 12.12: I'm trying to port this    A:  Those routines are variously
  267. >     old program.  Why do I            obsolete; you should
  268. >     get "undefined external"        instead:
  269. ==========
  270.     undefined.  Therefore, the order in which libraries are listed
  271.     with respect to object files (and each other) is significant;
  272. <     usually, you want to search the libraries last (i.e., under
  273. <     Unix, put any -l switches towards the end of the command line).
  274. ---
  275. >     usually, you want to search the libraries last.  (For example,
  276. >     under Unix, put any -l switches towards the end of the command
  277. >     line.)
  278. ==========
  279. < 12.16: How can I split up a command line into argc and argv, like the
  280. <     shell does?
  281. ---
  282. > 12.16: How can I split up a command line into whitespace-separated
  283. >     arguments, like main's argc and argv?
  284. ==========
  285. < A:    Most systems have a routine called strtok.
  286. ---
  287. > A:    Most systems have a routine called strtok, although it can be
  288. >     tricky to use and it may not do everything you want it to (e.g.,
  289. >     quoting).
  290. ==========
  291.     The System V release 4 lint is ANSI-compatible, and is available
  292.     separately (bundled with other C tools) from UNIX Support Labs
  293. <     (a subsidiary of AT&T), or from System V resellers.
  294. ---
  295. >     or from System V resellers.
  296. ==========
  297. >     In the absence of lint, many modern compilers attempt to
  298. >     diagnose almost as many problems as a good lint does.
  299. ==========
  300. <         giza.cis.ohio-state.edu    pub/style-guide
  301. ---
  302. >         ftp.cs.umd.edu          pub/style-guide
  303. ==========
  304.   16.7:    How can I check whether a file exists?  I want to query the user
  305. <     if a requested output file already exists.
  306. ---
  307. >     before overwriting existing files.
  308. ==========
  309. < A:    You can try the access() routine, although it's got a few
  310. <     problems.  (It isn't atomic with respect to the following
  311. <     action, and it has anomalies if the program calling it is
  312. <     running as root.)
  313. ---
  314. > A:    On Unix-like systems, you can try the access() routine, although
  315. >     it's got a few problems.  (It isn't atomic with respect to the
  316. >     following action, and can have anomalies if used in setuid
  317. >     programs.)  Another option (perhaps preferable) is to call
  318. >     stat() on the file.  Otherwise, the only guaranteed and portable
  319. >     way to test for file existence is to try opening the file (which
  320. >     doesn't help if you're trying to avoid overwriting an existing
  321. >     file, unless you've got something like the BSD Unix O_EXCL open
  322. >     option available).
  323. ==========
  324.   A:    Unix and some other systems provide a popen() routine, which
  325.     sets up a stdio stream on a pipe connected to the process
  326.     running a command, so that the output can be read (or the input
  327. <     supplied).
  328. ---
  329. >     supplied).  Alternately, invoke the command simply (see question
  330. >     16.12) in such a way that it writes its output to a file, then
  331. >     open and read that file.
  332. ==========
  333. A:    Perhaps you have a pre-ANSI compiler, which doesn't allow
  334.     initialization of "automatic aggregates" (i.e. non-static local
  335.     arrays and structures).  As a workaround, you can make the array
  336. <     global or static.  (You can always initialize local char *
  337. ---
  338. >     global or static, and initialize it with strcpy when f is
  339. >     called.  (You can always initialize local char * variables with
  340. ==========
  341. < 17.4:    How can I delete a line (or record) from the middle of a file?
  342. ---
  343. > 17.4:    How can I insert or delete a line (or record) in the middle of a
  344. >     file?
  345. ==========
  346.     f2c    A Fortran to C converter jointly developed by people
  347.         from Bell Labs, Bellcore, and Carnegie Mellon.  To find
  348. <         about f2c, send the mail message "send index from f2c"
  349. <         to netlib@research.att.com or research!netlib.  (It is
  350. <         also available via anonymous ftp on research.att.com, in
  351. <         directory dist/f2c.)
  352. ---
  353. >         out more about f2c, send the mail message "send index
  354. >         from f2c" to netlib@research.att.com or research!netlib.
  355. >         (It is also available via anonymous ftp on
  356. >         netlib.att.com, in directory netlib/f2c.)
  357. ==========
  358.     (or ask archie; see question 17.12); and MEMDEBUG from
  359. <     dorado.crpht.lu in pub/sources/memdebug .  See also question
  360. <     17.12.
  361. ---
  362. >     ftp.crpht.lu in pub/sources/memdebug .  See also question 17.12.
  363. ==========
  364.   A:    Use mktime (see questions 12.6 and 12.7), or Zeller's
  365. <     congruence.  Here is one quick implementation posted by Tomohiko
  366. <     Sakamoto:
  367. ---
  368. >     congruence, or see the sci.math FAQ list, or try this code
  369. >     posted by Tomohiko Sakamoto:
  370. ==========
  371. <     garbo.uwasa.fi:/pc/c/c-lesson.zip
  372. <     oak.oakland.edu:pub/msdos/c/LEARN-C.ZIP
  373. ---
  374. >     garbo.uwasa.fi:/pc/c-lang/c-lesson.zip
  375. ==========
  376. <     other FAQ lists, including this one: two sites are rtfm.mit.edu
  377. ---
  378. >     other FAQ lists, including this one; two sites are rtfm.mit.edu
  379. ==========
  380.   Acknowledgements
  381.  
  382.   Thanks to Jamshid Afshar, Sudheer Apte, Randall Atkinson, Dan Bernstein,
  383.   Vincent Broman, Stan Brown, Joe Buehler, Gordon Burditt, Burkhard Burow,
  384.   Conor P. Cahill, D'Arcy J.M. Cain, Christopher Calabrese, Ian Cargill,
  385. > Paul Carter, Billy Chambless, Raymond Chen, Jonathan Coxhead, Lee
  386.   Crawford, Steve Dahmer, Andrew Daviel, James Davies, Jutta Degener, Norm
  387.   Diamond, Jeff Dunlop, Ray Dunn, Stephen M. Dunn, Michael J. Eager, Dave
  388.   Eisen, Bjorn Engsig, Chris Flatters, Rod Flores, Alexander Forst, Jeff
  389.   Francis, Dave Gillespie, Samuel Goldstein, Alasdair Grant, Ron
  390.   Guilmette, Doug Gwyn, Tony Hansen, Joe Harrington, Guy Harris, Elliotte
  391.   Rusty Harold, Jos Horsmeier, Blair Houghton, Ke Jin, Kirk Johnson, Larry
  392.   Jones, Kin-ichi Kitano, Peter Klausler, Andrew Koenig, Tom Koenig, Ajoy
  393.   Krishnan T, Markus Kuhn, John Lauro, Felix Lee, Mike Lee, Timothy J.
  394.   Lee, Tony Lee, Don Libes, Christopher Lott, Tim Love, Tim McDaniel,
  395.   Stuart MacMartin, John R. MacMillan, Bob Makowski, Evan Manning, Barry
  396.   Margolin, George Matas, Brad Mears, Bill Mitchell, Mark Moraes, Darren
  397.   Morby, Ken Nakata, Landon Curt Noll, David O'Brien, Richard A. O'Keefe,
  398. > Hans Olsson, Philip (lijnzaad@embl-heidelberg.de), Andrew Phillips,
  399.   inard, Dan Pop, Kevin D. Quitt, Pat
  400.   Rankin, J. M. Rosenstock, Erkki Ruohtula, Tomohiko Sakamoto, Rich Salz,
  401.   Chip Salzenberg, Paul Sand, DaviD W. Sanderson, Christopher Sawtell,
  402. > Paul Schlyter, Doug Schmidt, Rene Schmit, Russell Schulz, Patricia
  403.   Shanahan, Peter da Silva, Joshua Simons, Henry Spencer, David Spuler,
  404.   Melanie Summit, Erik Talvola, Clarke Thatcher, Wayne Throop, Chris
  405.   Torek, Andrew Tucker, Goran Uddeborg, Rodrigo Vanegas, Jim Van Zandt,
  406.   Wietse Venema, Ed Vielmetti, Larry Virden, Chris Volpe, Mark Warren,
  407.   Larry Weiss, Freek Wiedijk, Lars Wirzenius, Dave Wolverton, Mitch
  408.   Wright, Conway Yee, and Zhuo Zang, who have contributed, directly or
  409.   indirectly, to this article.  Special thanks to Karl Heuer, and
  410.   particularly to Mark Brader, who (to borrow a line from Steve Johnson)
  411.   have goaded me beyond my inclination, and occasionally beyond my
  412.   endurance, in relentless pursuit of a better FAQ list.
  413. ==========
  414.  
  415.                     Steve Summit
  416.                     scs@eskimo.com
  417.