home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / mswindo / programm / win32 / 2601 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  3.0 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!micro-heart-of-gold.mit.edu!uw-beaver!cs.ubc.ca!mala.bc.ca!bigras
  2. From: bigras@mala.bc.ca
  3. Newsgroups: comp.os.ms-windows.programmer.win32
  4. Subject: Re: Bizzare array size link errors??
  5. Message-ID: <1992Dec27.195223.1158@mala.bc.ca>
  6. Date: 27 Dec 92 19:52:23 -0700
  7. References: <1992Dec22.211411.1147@mala.bc.ca> <1992Dec23.233102.18242@emr1.emr.ca>
  8. Organization: Malaspina College
  9. Lines: 95
  10.  
  11. In article <1992Dec23.233102.18242@emr1.emr.ca>, jagrant@emr1.emr.ca (John Grant) writes:
  12. > In article <1992Dec22.211411.1147@mala.bc.ca> bigras@mala.bc.ca writes:
  13. >>Hi,
  14. >>There seems to be a weird little bug involving large
  15. >>fixed arrays using the SDK.
  16. >>
  17. >>This does not compile and link the buff array properly.
  18. >>
  19. >> #include <stdio.h>
  20. >> int i;  
  21. >> long count;
  22. >> long buff[1024*1024*4];                         
  23. >> main()
  24. >> {
  25. >> for (i=0; i<=1; i++)
  26. >>  {
  27. >>  for (count=0; count<=1024*1024*4; count++)
  28. >>    buff[count]=count;
  29. >>  printf ("Win32\n");
  30. >>  }
  31. >> return(0);     
  32. >> }
  33. >>
  34. >>When made this produces the following error:
  35. >>
  36. >> Microsoft(R) Windows NT Linker Version 2.19        
  37. >> (C) 1989-1992 Microsoft Corp. All rights reserved. 
  38. >>                                                   
  39. >> simple.obj() : warning 0516: _buff is undefined    
  40. >>
  41. >>
  42. >>Yet the following code makes fine, the only difference is the size
  43. >>of the buff array!  So why is this? 
  44. >>
  45. >> #include <stdio.h>
  46. >> int i;  
  47. >> long count;
  48. >> long buff[1024*1024*2];                         
  49. >> main()
  50. >> {
  51. >> for (i=0; i<=1; i++)
  52. >>  {
  53. >>  for (count=0; count<=1024*1024*2; count++)
  54. >>    buff[count]=count;
  55. >>  printf ("Win32\n");
  56. >>  }
  57. >> return(0);     
  58. >> }
  59. >>
  60. >>Various other sizes of char or int arrays exhibit similar
  61. >>bizzare errors depending on the size of the array.
  62. >>
  63. >>Any ideas?
  64. >> 
  65. >>Tony Bigras
  66. >> 
  67. >>   BIGRAS@MALA.BC.CA 
  68. >>
  69. >>ok 
  70. > 
  71. >     Try this:
  72. >         printf("%d",1024*1024*4);
  73. >     
  74. >     now try this:
  75. >         printf("%ld",1024L*1024L*4L);
  76. > 
  77. >     Is there any difference?  Why?
  78. > 
  79.  
  80. Forcing the constants to long has no effect on the errors
  81. generated by the linker.  This appears to be some weird bug
  82. related to the size of physical/virtual memory. It is triggered
  83. a various array sizes between 8MB and16MB on my 8MB system.
  84.  
  85.  
  86. >     I'm not trying to be deliberately obtuse here, but don't
  87. >     forget to declare your constants long or use a (long) cast.
  88. >     If you don't they are assumed to be short (if less than 16 bits).
  89. >     Calculations using short ints where the result is a long will
  90. >     invariably be wrong.
  91. > -- 
  92. > John A. Grant                        jagrant@emr1.emr.ca
  93. > Airborne Geophysics
  94. > Geological Survey of Canada, Ottawa
  95.  
  96. C has always stuck me as a poor general purpose language
  97. with its poor type enforcement. Surely I should not have to declare
  98. constants as long if they are being used on long variables.  Is the
  99. compiler just a portable assembler, or is it supposed to do a bit of the
  100. work as well?  I appreciate the ability to relax typing but are C compilers
  101. totally brain-dead?
  102.  
  103. Tony Bigras                BIGRAS@MALA.BC.CA
  104.  
  105.  
  106.