home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / os2 / programm / 7215 < prev    next >
Encoding:
Internet Message Format  |  1992-12-28  |  1.4 KB
  1. Path: sparky!uunet!gatech!prism!gt3968a
  2. From: gt3968a@prism.gatech.EDU (Yang, Che Kan)
  3. Newsgroups: comp.os.os2.programmer
  4. Subject: Re: emx/gcc large data structure problem
  5. Message-ID: <78847@hydra.gatech.EDU>
  6. Date: 28 Dec 92 15:10:54 GMT
  7. References: <78835@hydra.gatech.EDU> <Bzy9pp.C8M@ecf.toronto.edu>
  8. Organization: Georgia Institute of Technology
  9. Lines: 26
  10.  
  11. In article <Bzy9pp.C8M@ecf.toronto.edu>, malone@ecf.toronto.edu (MALONE MATTHEW JAMES) writes:
  12. > 
  13. > see why I am wrong.  A structure where each element exceeds 64k with
  14. > a thousand elements is a 64Meg structure.  It does not seem to me to 
  15. > be unusual that OS/2 is trying to allocate a 64Meg slice of virtual
  16. > memory which translates into a 64Meg addition to your swapper file.
  17. > It seems natural that 20Meg of (free) disk space is not enough.  I
  18.  
  19.  
  20. Matt is indeed right on the problem.  This may be the exact thing 
  21. that happened.  But what I am actually concern about is whether
  22. there is a such a bug in gcc in general.  I read about this in 
  23. linux newsgroup but nobody address it anymore.
  24.  
  25. I read this news just when I was having that problem so I carelessly
  26. assume it is device problem but not user's problem ( oops! )
  27.  
  28. Thanks anyway.  So, anyone know about that may be gcc problem?
  29.  
  30.  
  31. Yang, Che Kan
  32. Georgia Institute of Technology, Atlanta Georgia, 30332
  33. uucp:     ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!gt3968a
  34. Internet: gt3968a@prism.gatech.edu
  35.           ayang@math.gatech.edu
  36.  
  37.