home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / c / 13664 < prev    next >
Encoding:
Text File  |  1992-09-14  |  2.4 KB  |  60 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news
  3. From: scs@adam.mit.edu (Steve Summit)
  4. Subject: Re: sscanf and portability
  5. Message-ID: <1992Sep15.005935.19233@athena.mit.edu>
  6. Sender: news@athena.mit.edu (News system)
  7. Nntp-Posting-Host: adam.mit.edu
  8. Organization: none, at the moment
  9. References: <RUJO.92Sep14160231@ulrik.uio.no>
  10. Date: Tue, 15 Sep 1992 00:59:35 GMT
  11. Lines: 47
  12.  
  13. In article <RUJO.92Sep14160231@ulrik.uio.no>, rujo@ulrik.uio.no (Rune J|rgensen) writes:
  14. > If you use types that explisit defines a byte size, e.g.:
  15. > 
  16. > typedef short INT16;
  17. > typedef long  INT32;
  18. > INT16 i16;
  19. > INT32 i32;
  20. > 
  21. > How do you preserve portability with sscanf? E.g:
  22.  
  23. Mit Schwierigkeit, as they say in Deutschland.
  24.  
  25. Defining types with precise numbers of bits is a bit of a
  26. perversion on the intent of C's type system, so it is not too
  27. surprising that occasional difficulties like this arise.  When
  28. precisely-sized types are truly necessary, typedefs like the
  29. above are the right way to implement them, but their necessity
  30. should be rare.  (I don't believe I have ever used such a type.)
  31.  
  32. The traditional need for precisely-sized types arises of course
  33. when people fall into the trap of using "binary" data files or
  34. otherwise attempting to conform to externally-imposed storage
  35. layouts.  Such situations should themselves be much rarer than
  36. they are, further minimizing the occurrence of the problem which
  37. Rune mentions.  Nevertheless, if a program does use precisely-sized
  38. variables to facilitate "binary" I/O, it should have fewer places
  39. where it needs to perform text I/O (scanf/printf) using those
  40. variables.
  41.  
  42. Obviously, some of the numbers which are read from or written to
  43. a data file must be respectively presented to or requested from
  44. the user, but scanf is a notoriously poor vehicle for interactive
  45. input and should itself be avoided, and printf uses values rather
  46. than pointers such that conservative format-specifiers and
  47. explicit casts solve the problem rather easily:
  48.  
  49.     printf("%d %ld", (int)i16, (long)i32);
  50.  
  51. If I were faced with this problem, I'd ask myself carefully
  52. whether I really needed to be using precisely-sized types at all,
  53. and whether I really needed to use scanf.  If both were in fact
  54. absolutely necessary, the solution (using temporary variables and
  55. extra assignments) which Lars Wirzenius has already outlined
  56. would be about the best that could be done.
  57.  
  58.                     Steve Summit
  59.                     scs@adam.mit.edu
  60.