guy@auspex.auspex.com (Guy Harris) (09/24/89)
>ok@cs.mu.oz.au (Richard O'Keefe) writes: >\... #if 0 >\... ... >\ #endif 0 >\(a) ^ this token is not legal in dpANS C; V.3 tends not to like it > >What!? The rest of the line isn't ignored? And what was the very good reason >the ANSI committee decided so? From the Rationale (presented without comment - I neither endorse nor reject their rationale, I merely present it): Various proposals were considered for permitting text other than comments at the end of directives, particularly "#endif" and "#else", presumably to label them for easier matchup with their corresponding "#if" directives. The Committee rejected all such proposals because of the difficulty of specifying exactly what would be permitted, and how the translator would have to process it. Three notes: 1) V.3 "tends not to like it", but merely spits out a warning - the code will still compile. 2) If you put "/*" and "*/" around the token, the resulting text is legal (assuming, of course, that there's no "*/" in the token, etc.). 3) If there already exist compilers that disallow extra tokens like that, one should consider replacing them with comments *anyway*. >\(b) You should not use this technique to comment out text in a C program; new >\C compilers are allowed to complain about mismatched quotes when they see >\"don't" and other such text, and some _do_. > >I remember the discussion, but I don't recall the very good reason (here we >go again) why those compilers could complain. Quality of implementation? >That's another point for Sun, 'cause their cpp works. :-) Sun's "cpp" is derived from various versions of the AT&T preprocessor (the precise version depends on the SunOS release); the credit doesn't go to Sun, by and large, for it working in that particular case - you'll probably find most, if not all, other Reiser-based "cpp"s (well, "cpp"s based on Reiser's "cpp", not based on Reiser himself, but you knew what I meant :-)), handle that particular case in the fashion you desire. The SunOS 4.x "cpp" is, BTW, based on the S5R3 "cpp", but the warning for extra tokens at the end of "#else"/"#endif" was put under the control of a "-p" (for "portability") flag to "cpp" (used, as I remember, only by the S5-environment "lint" when it is given the "-p" flag) because the practice was so widespread.
mehdi@babel.SanDiego.NCR.COM (Mehdi Bonyadi) (09/29/89)
I wrote a program that creates a directed graph and traverses this graph to find the minimum and maximum cost paths. Any time a traversal ends a report of the edges and nodes is created dynamically. I am saving the top 100 ( user picks this number and there is no limit on it) of these reports. The problem I am facing is with memory usage. Once a report is put into the list and later needs to be replaced, I use the function "free" to free the memory. Well, it appears that free does not work and the memory is not freed. The reason being process memory usage goes above the limits and process dies. ( my database is quite large and I have to deal with it in one run and I can not break it down to smaller pieces so that I do not reach the limit. ) I am running this program on sun4 and sun3 workstations. An engineer from sun hot line told me about an existing problem with "free", he said it does not work in sunOS 4.0 and above ( he was not sure about previous releases of the OS ). I have a dealine to meet and I have been working on this program for over one year and ( it appears that ) none of my tests caught this problem. I guess I was counting on C in giving me the opportunity to use and release memory and I did not design a test case to make sure of that. If there is anybody who knows how to deal with this problem please let me know. If there is a work around or if there is another way of programming this thing, I am willing to do it. If someone has a memory management package that can allocate a big chunk and then work with its own malloc and free please let me know. I have time till Monday October second to solve this problem or ???????