HDTenEightyP/NetNews huggingface dataset:
From: pinkas@skywalker.intel.com (Israel Pinkas)
Subject: Re: strcpy implementation question
Organization: Software Technologies, INTeL Corporation, Santa Clara, CA
	<PINKAS.92Aug24183511@caraway.intel.com>
	<1992Aug26.224904.7671@sneaky.lonestar.org>
Date: Thu, 3 Sep 1992 01:36:35 GMT

gordon@sneaky.lonestar.org (Gordon Burditt) writes:

> You won't find an explicit statement that the source string is inviolate,
> either.  (On destructive-read machines using, say, actual core memory, you
> might save time not re-writing the data you read.  This would be a very
> wierd "optimization".)  Nor is there a statement that argc or any other 
> random variable in the program is inviolate.  And there isn't any statement 
> that evaluating "1+2" doesn't launch missiles.  But there's not much point 
> in having a standard if doing anything can cause random side effects - the 
> standard uses terms like "undefined behavior" or "implementation-defined 
> behavior", and states limits on when these can happen.  Unless the source 
> and destination overlap, the behavior is supposed to be defined.

The source argument (the second argument) to strcpy is declared as 'const
char *', which states that the routine will not modify the source string.

My understanding is that a routine is only allowed to have undocumented
side effects if they will have no effect on the execution of the program.
In other words, as long as the program runs the same when executed on
another machine, the side effect is OK.

In my book, if evaluating 1+2 launches missles, it would be OK as long as
(1) the missles did not destroy the currently executing computer, and (2)
the lack of a missle in the launch bay did not cause the program to abort:)

The question still boils down to this:

Can the compiler consider the memory past the destination of a copy as
scratch memory, or does strcpy GUARANTEE only to modify the memory that is
necessary for copying the string?

> A better example would be the infamous "variable-length struct".
> You declare something like:
>
>	 struct foo {
>		 int	type;
>		 ... bunch of other stuff here ...
>		 char	name[1];
>	 } *fp;
>	 char	x[100];
>
> and then use it like:
>
>	 fp = (struct foo *) malloc(sizeof(struct foo) + strlen(x));
>	 strcpy(fp->name, x);
>
> "name" has supposedly known size.  x has supposedly known size.
> The compiler probably aligned both of them.  But if the copying stops 
> at 1 char or 1 word when x contains a 70-char string, I'm going to be 
> annoyed.  And a lot of programs will break.

I don't know of a single compiler that guarantees to place two static
variables which are declared in the same file next to each other.  In other
words,

	int a,b;

	assert(&b-&a == 1);

is allowed to fail.

The variable length struct is a hack.  There is nothing in the language
that prevents the compiler from performing bounds checking on accesses to
name.

--------------------------------------------------
I would still like to have a pointer to something that documents that the
contents of a char array are inviolate, and therefore strcpy is not allowed
to modify past the end of the string.

-Israel

Xref: sparky comp.lang.c:12680 comp.std.c:2493
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: strcpy implementation question
Date: 23 Aug 92 19:49:19 GMT
Organization: I.E.C.C.

In article <1992Aug23.003930.9918@saaf.se> pausch@saaf.se (Paul Schlyter) writes:
>>[I said the C standard says strcpy() has to copy exactly the string
>>including the terminating null character]
>>But it doesn't say "(including the terminating null character and any other
>>garbage convenient for the compiler implementer)".  You have to stop at the
>>null byte.
>
>Even on a machine with word addressing, where each string is very likely to
>occupy an integral number of machine words?

C defines a string as a sequence of "char" items with the last one
containing a zero.  There has to be some way to address individual chars
in an implementation or it's hard to see on what basis it claims to be C.
For example, the string "ineptitude" is 11 chars long including the null
character, not 12, 15 or some other convenient multiple.  Consider the
following code:

	static char buf[6];

	strcpy(buf+3, "cd");
	strcpy(buf, "ab");

If buf doesn't end up containing "ab\0cd\0" I'd say that something was
seriously wrong.

The original question asked whether when using strcpy() to copy a string
from one static array to another it would be an OK optimization to copy
the whole array as full words in an unwound loop rather than looking for
the null byte.  Temporarily disregarding the total wrongheadedness of the
idea, there are two other reasons not to copy words:

1.  If the programmer wanted to copy the whole buffer, he would have used
memcpy(), since that's what it's for.

2.  It is my impression that the most common case where source and target
array length are both known is when the source operand is a literal
string.  In that case the compiler knows the exact length of the actual
string and can generate its unwound code, copying exactly the right number
of characters at the end.  This gets you most of the performance gain of
the proposed optimization while still being correct.

-- 
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 492 3869
johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl
Re-elect Vice President Potatoe-Head !
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: Most difficult part of learning C?
Date: 26 Aug 1992 15:58:13 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <chuckb.714781695@milton> chuckb@milton.u.washington.edu (Chuck Bass) writes:
>I would bet that assembly language programmers have no problem
>picking up C's notion of pointers.

I disagree.  Assembly programmers are used to pointers being addresses, and
arithmetic on pointers being address arithmetic.  They're probably the ones
who get most confused by C's automatic scaling during ptr+integer
calculations, and don't understand why p+=sizeof(*p) doesn't do what they
expect.

On the other hand, perhaps your comment was motivated by the fact that most
other high level languages don't provide pointer arithmetic at all.
Programmers used to PL/O, Pascal, or Ada are familiar with pointers being
used for things like linked lists, but not pointers into the middle of
objects.  Assembly programmers can deal with pointers that can address
anything.

I never had this problem because my introduction to pointers was in PL/I on
Multics, which has extensions that perform pointer arithmetic (but since
PL/I doesn't have typed pointers, the arithmetic is on the raw address,
rather than being scaled automatically as in C).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: cee1@ra.msstate.edu (Charles Evans)
Newsgroups: comp.lang.c
Subject: Are there C docs anywhere around
Date: 27 Aug 92 14:46:12 GMT
Organization: Mississippi State University

Iknow in my UNIX here on campus I can man <command> and get info on the
various c commands, however, I wonder if there is a complete "C docs" at
any ftp sitw?

any ifo would be great

chuck

-- 
+--------------------+-----------------------+------------------------+
|  Charles E. Evans  |  cee1@ra.msstate.edu  |  All things are green  |
|    iDLE CHATTEr    |  cee1@MSSTATE.BITNET  |  unless they are not.  |
+--------------------+-----------------------+------------------------+
From: julie%erix@uunet.uu.net (Julie Cafritz)
Newsgroups: comp.lang.c
Subject: DOS Compiler 
Date: Mon, 24 Aug 92 22:43:08 EDT
Distribution: world
Organization: Erix Remote

there a public domain, freeware or shareware C compiler
for DOS machines available by ftp or e-mail ?
Newsgroups: comp.lang.c
From: jack@afs.com (Jack Brasch)
Subject: Convert COBOL COMP-3 to double?
Reply-To: jack@afs.com (Jack Brasch)
Date: Wed, 26 Aug 1992 15:10:21 GMT

Could someone point me in the right direction or mail me a routine to  
convert COBOL COMP-3 types to a double.

thanks

jack@afs.com
Newsgroups: comp.lang.c
From: ebergman@nyx.cs.du.edu (Eric Bergman-Terrell)
Subject: Re: Problem on Sun4
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Mon, 24 Aug 92 04:23:44 GMT

Call stat() or fstat() specifying the tty device as the filename.

Terrell
From: xiong@fzi.de (Xiong Xun)
Newsgroups: comp.lang.c
Subject: primitive Question
Date: 4 Sep 92 14:10:18 GMT
Reply-To: xiong@fzi.de
Organization: Forschungszentrum Informatik (FZI), Karlsruhe, Germany

Has someone a "Convert_Integer_to_ASCII" C-function for a C-beginner?
Please send email. Thanks!
From: dano@ssc-vax (Dan Olson)
Newsgroups: comp.lang.c
Subject: Re: Most difficult part of learning C?
Date: 31 Aug 92 16:18:51 GMT
Reply-To: dano@ssc-vax.boeing.com (Dan Olson)
Organization: Boeing Aerospace & Electronics

It's been a while since I learned C, so even though I remember having
problems (I still do!), I don't remember many specific ones.  Probably
the biggest all around gatcha was that syntax for other high level
languages was legal in C, but wasn't what you wanted.  Like...

  Matrix indexing: M[i,j] (instead of) M[i][j]
  Equality test:   a = b  (instead of) a == b

And I seem to remember alot of people being confused with strings doing
things like...

  char *msg;
  strcpy(msg, "fukitsnukin");

And in K&R days, problems with mismatched function arguments.
-- 
dano  [] UUCP:      ..!uw-beaver!ssc-vax!dano
      [] Internet:  dano@ssc-vax.boeing.com
"Once the game is over, the king and the pawn go back in the same box."
- Italian Proverb (I think)
Newsgroups: comp.lang.c
From: adam@microware.com (Adam Goldberg)
Subject: Re: sscanf? What am I doing wrong?
Organization: Microware Systems Corp., Des Moines, Iowa
Date: Thu, 3 Sep 1992 13:42:59 GMT

kpearce@magnus.acs.ohio-state.edu (BULLDAWG) writes:

>char partA[20];   \* and is for example "transmit data" *\
>char tran[] = "transmit"

>  if (partA==tran)
>  {
>  	printf("We have a match\n");
>  }
>  else

>This always fails.  I have tried putting \r\0 and various other control
>characters at the end of the ttest string tran[] to no avail.


partA and tran are both POINTERS to some number of characters.  The 
if statement (partA == tran) is checking if the POINTERS are equal...
clearly they're not, unless you did something previously like
partA = tran.

What you (probably) want to do is something like this:

   if(strcmp(partA, tran)==0)
   {
      match
   }


or

   if(strncmp(partA, tran, strlen(partA))==0)
   { ... }


-- 
Adam G.
adamg@microware.com, or ...!uunet!mcrware!adamg
The above is not to be construed in any way as the official or unofficial
statements of Microware, or any Microware employees.
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: Most difficult part of learning C?
Date: 26 Aug 92 18:43:39 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

The most difficult part of learning C is getting the mechanical
skills to be such a matter of routine that you don't have to think
about them any more.

It's a little like the comment made by the instructor of a photography
workshop I took two years ago: ``There are only two hard things about
taking pictures: where to stand and when to push the button.  Everything
else is just technique.''
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c
From: rot@multisys.com (Republic of Taiwan)
Subject: Re: Why should POINTERS be so damn hard to understand ?
Organization: Multimedia Information Systems Corporation, San Jose, CA                        TEL: (408) 437-3031            E-mail: info@multisys.com
Date: Tue, 1 Sep 1992 20:56:41 GMT

In article <1992Aug28.163724.11581@mccc.edu> pjh@mccc.edu (Pete Holsberg) writes:
=In article <1992Aug27.135946.6622@infonode.ingr.com> henders@infonode.ingr.com (Greg Henderson) writes:
==Well one reason that pops to mind is the nice ability to use a pointer 
==to traverse an array more efficently than the 'normal' way.  For ex...
==
==You could do this normally:
=={
==    int a[1000], i; 
==
==    for ( i=0; i<1000; i++ )
==	a[i] = get_some_arbitrary_value();
==}
==
==Or you could do this w/ a pointer:
=={
==    int a[1000], *_i;
==
==    for (_i=a;  _i<a+1000; _i++ )
==	*_i = get_some_arbitrary_value();
==}
==
==These two pieces of code do the exact same thing, but if you are 
==worried about low-level efficiency the second version is a little
==tighter, as each reference to the array value in the pointer version
==requires less work to come up w/ that address.

The presumption here is that the length of int is same as
the length of the address space.

If the int is 4 byte long and the address space is 2(or 8 or 3) byte long,
the this fell miserably. The second one is not portable.

=
=Isn't that a function of the compiler? In fact, let me ask why don't we
=have compilers that produce the most efficient code even when array
=notation is used? Is it that they would be too slow? I recall a FORTRAN
=compiler for a 16-bit digital computer used in a hybrid computer system
=back in the 60s that produced wonderful code, but took a very very long
=time to do it.
=
Newsgroups: comp.lang.c
Subject: Macros for C to compile Pascal
From: jwstuart@ecst.csuchico.edu (Jesse William Leo Stuart)
Date: Mon, 31 Aug 1992 02:04:37 GMT
Organization: California State University, Chico

	Does anyone know of a list of macros that let a C/C++ compiler
compile Pascal/Turbo Pascal 6.0 source code?  If you do please e-mail it to
me or an ftp adress so I coulg get it.

Jess Stuart
CSUC Chico CA
Newsgroups: comp.lang.c,comp.unix.programmer,comp.sys.sun.misc
From: chupchup@ferkel.ucsb.edu (Robert Earl)
Subject: Re: SunOS 4.1.2: Increasing per process file pointers
Followup-To: comp.unix.programmer,comp.sys.sun.misc
Organization: (EVIL!)
Date: Thu, 3 Sep 1992 08:08:32 GMT

fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald) writes:

| Hugh Warren writes:
| >How can you increase the number of open file pointers allowable
| >per process under SunOS 4.1.2?  I'm hitting a limit of 60 using
| >fopen() right now.  Thanks for any help...

| To increase your descriptor limit to 256:
| ... [rlimit solutions deleted] ...

Unfortunately, since the poster was using fopen() and SunOS, he's out
of luck past fd #127, since the Sun library was compiled with signed
chars and only a "char" allocated for the fileno field of a FILE
object, thus it may return a pointer just fine, but will crap out on
any I/O done on the (converted and sign-extended to int) value of the
file descriptor.   Oh well.

-- 
"If you've got a pig that likes jumping fences, | robert earl
you have to make its fence a lot higher all at  | rearl@ucsd.edu
once -- if you do it by increments, all you're  | rearl@piggy.ucsb.edu
doing is training a jumping pig." -Henry Spencer|
Xref: sparky comp.lang.c:13236 comp.unix.programmer:4540
From: hurtta@cs.Helsinki.FI (Kari E. Hurtta)
Newsgroups: comp.lang.c,comp.unix.programmer
Subject: Re: Realloc question
Date: 4 Sep 92 18:29:41 GMT
Followup-To: comp.lang.c
Organization: Department of Computer Science, University of Helsinki, Finland

(I added Followup-To: comp.lang.c)

In article <1992Sep4.100203.1@ducvax.auburn.edu> swanger@ducvax.auburn.edu wrote:
> int num_strings, string_size, loop,;
> char **strings;
> 
> num_strings = 100  /* will actually be entered by user */
> string_size = 100  /* ditto                            */
> 
> strings = (char **) calloc(num_strings, sizeof(char*));
<DELETED>
> -----------------------------------------------------------------------
> Somewhere later in the program, I discover that I need more more strings. 
> Is the following syntax correct?
> 
> strings = (char **) realloc((char **) strings, new_num_strings);

In ANSI:
  strings = (char **) realloc ((void *) strings, 
			       new_num_strings * sizeof(char*));

In older systems (ie. SunOS pre 5.0)
  strings = (char **) realloc ((char *) strings, 
                               new_num_strings * sizeof(char*));

or simply:

  strings = (char **) realloc (strings, new_num_strings * sizeof(char*));


That sizeof(char *) is important. That size in realloc isn't 
wanted new number of elements. It is wanted new size of allocated 
area.

- K E H
( Kari.Hurtta@Helsinki.FI,
  hurtta@cc.Helsinki.FI,
  hurtta@cs.Helsinki.FI,
  HURTTA@FINUH.BITNET
)
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: main()
Date: 3 Sep 92 12:50:42 GMT
Organization: University of Helsinki

doug@tisdec.tis.tandy.com writes:
>Actually main() is defined as
>
>  int main(int argc, char **argv, char *envp);

As was noted already, this is not true for standard C.

>Declaring it as "void main(void)" is dead wrong.  But you can still do
>it because the compiler has no idea how main() is defined.

The compiler might not complain about "void main", but it still doesn't
have to work.

>So you can either put a return
>value in or define main() as void to suppress it.

Except that you can't define main as void.  Or, at least you can't do
that unless you want to sacrifice portability and correctness (it is
unfortunate but true that programs that have void main actually do work
in many environments).

I don't myself understand why it should be so difficult to a) ignore a
"no return for main" error message (if there is an exit somewhere
instead, that is), or b) to automatically remove the warning message
from the error list (this I've done, it was a couple of lines of code
with the appropriate tools).  I see no need to use non-standard and very
possibly dangerous methods just to get rid of one warning message.

>If I don't declare main() with exactly
>the return value and parameters it expects then the linker will spit out
>some warning messages.  To avoid these I declare everything, including
>envp, at which point the compiler spits out it's own warning messages
>telling me that I declared but didn't use some parameters.

Are you certain that defining main as:

	int main(int argc, char **argv)

does not work?  If it does not, your compiler or linker is seriously
broken and needs urgent fixing.

--
Lars.Wirzenius@helsinki.fi
From: grether@cvt11.verfahrenstechnik.uni-stuttgart.de (Grether Bernd (sorescu))
Newsgroups: comp.lang.c
Subject: Re: C vs. FORTRAN
Date: 4 Sep 92 08:48:23 GMT
Reply-To: grether@cvt11.verfahrenstechnik.uni-stuttgart.de (Grether Bernd (sorescu))
Organization: Dep.Chem.Eng.(ICVT), Uni Stuttgart, FRG

In article <DWISEMAN.92Sep3164036@spsd630a.erim.org>, dwiseman@spsd630a.erim.org (Dave Wiseman) writes:
|> 
|> Help!
|> 
|> I have a (two) simple programs, one in fortran, and one in C.  I have compiled
|> them both optimized, and timed the results.  The fortran version takes .1 s
|> to run, and the C version takes 12.5s to run.  I know (hope) that there is a
|> simple remedy for this.  The project that I am working on has to do many 
|> sines and cosines, and I'd prefer to keep the entire program in C, and not
|> mix the languages.  What can I do to improve the speed of the C version?
|> 
|> 	Dave Wiseman
|> 	dwiseman@erim.org

[
code deleted:

loop 1000000 times
  the_sin = sin(...)
  the_cos = cos(...)
]

It looks like the Fortran compiler does a better optimization and computes
the_sin and the_cos only once (the first 999999 results are not used
in the program).
These are the times I get on a SPARC2:

Without optimization: C: 12.9s / Fortran: 13.5s
With optimization:    C: 12.4s / Fortran:  0.1s


If I declare the_sin and the_cos as arrays (the_sin[i] = sin(...))
the times are:

Without optimization: C: 14.2s / Fortran: 14.5s
With optimization:    C: 13.2s / Fortran: 14.0s

Now the compiler is forced to compute sin() and cos() a million times.
Conclusion: your example is too simple. In a non-trivial program you
wouldn't do a million useless computations (:-)).

-- 
Bernd "booster bendi" Grether | Ain't singing for Pepsi
                              | ain't singing for Coke
*** bi uns cha me au          | I don't sing for nobody
    alemannisch schwaetze *** | makes me look like a joke (Neil Young)
Xref: sparky comp.lang.c:13182 comp.sys.sun.misc:4072
From: khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup)
Newsgroups: comp.lang.c,comp.sys.sun.misc
Subject: Re: sun cc optimization failure
Date: 3 Sep 92 10:17:51
Organization: Sun MegaSystems
NNTP-Posting-Host: chiba
In-reply-to: dwb@IMD.Sterling.COM's message of Thu, 3 Sep 1992 14:21:12 GMT


>...code elided
>... misc questions and comments...
>...Sun out there listening?  Does Sun even care given that they are unbundling

The problem was fixed in the unbundled compiler released quite a while
ago.

cc net.c && a.out
in for loop
in for loop
in for loop
$ cc -O net.c && a.out
in for loop
in for loop
in for loop
$ cc -O4 net.c && a.out
in for loop
in for loop
in for loop
$ cc -V -fast -O4 net.c && a.out
cc: Warning: -O4 overwrites previously set optimization level of -O2
version-id of "/home1/compilers/SC1.0/cpp":          SC1.0	1Mar1991
/home1/compilers/SC1.0/cpp -undef -Dunix -Dsun -Dsparc -I/home1/compilers/SC1.0/include net.c >/tmp/cpp.06089.0.i
version-id of "/home1/compilers/SC1.0/ccom":         SC1.0	1Mar1991
/home1/compilers/SC1.0/ccom - -XO4 /tmp/ccom.06089.2.ir -fsingle </tmp/cpp.06089.0.i >/tmp/ccom.06089.1.s
rm /tmp/cpp.06089.0.i
version-id of "/home1/compilers/SC1.0/iropt":        SC1.0	1Mar1991
/home1/compilers/SC1.0/iropt -O4 -F -o /tmp/iropt.06089.3.ir /tmp/ccom.06089.2.ir
rm /tmp/ccom.06089.2.ir
version-id of "/home1/compilers/SC1.0/cg":           SC1.0	1Mar1991
/home1/compilers/SC1.0/cg -d -cg89 /tmp/iropt.06089.3.ir >/tmp/cg.06089.4.s
rm /tmp/iropt.06089.3.ir
version-id of "/home1/compilers/SC1.0/inline":       SC1.0	1Mar1991
/home1/compilers/SC1.0/inline -i /home1/compilers/SC1.0/cg89/libm.il </tmp/cg.06089.4.s >/tmp/inline.06089.5.s
rm /tmp/cg.06089.4.s
version-id of "/home1/compilers/SC1.0/as":           SC1.0	1Mar1991
/home1/compilers/SC1.0/as -o net.o -O4 -cg89 /tmp/ccom.06089.1.s /tmp/inline.06089.5.s
rm /tmp/ccom.06089.1.s
version-id of "/bin/ld":                             Unknown
/bin/ld -dc -dp -e start -X -o a.out /home1/compilers/SC1.0/crt0.o /home1/compilers/SC1.0/cg89/_nonstd_crt1.o -L/home1/compilers/SC1.0/cg89 -L/home1/compilers/SC1.0 net.o -lm -lc
rm /tmp/inline.06089.5.s
rm net.o
in for loop
in for loop
in for loop
$ 

The authors of the compiler are always interested in improving it.
Please report problems (including release number of the compiler) when
they are found.















--
----------------------------------------------------------------
Keith H. Bierman    keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SunPro 2550 Garcia MTV 12-33             | (415 336 2648) fax 964 0946
Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992
Newsgroups: comp.lang.c
Subject: Re: How to use the same file of structs on PC and Sun?
From: selig@sysjj.mdcbbs.com
Date: 31 Aug 92 12:39:34 GMT
Followup-To: comp.lang.c
Organization: McDonnell Douglas M&E, Cypress CA
Nntp-Posting-User: selig

In article <559@alden.UUCP>, sgr@alden.UUCP (Stan Ryckman) writes:
> In article <71527@apple.Apple.COM> may@Apple.COM (Patrick May) writes:
>>Hi,
>>
>>     I'm porting an application from an MS-DOS environment to the Sun
>>(SunOS 4.1.1).  The app makes heavy use of files opened in binary mode
>>to store various structs.  When I tried to use these same files on the
>>Sun I found that the Sun compiler came up with a different size for
>>these structs than did the MS-DOS compiler (uSoft).

          Micosoft C has that PRAGMA instruction (#pragma pack) that
          instructs the system how (or whether) to pack structures.

          Dan
Xref: sparky comp.lang.c:13103 comp.lang.c++:13192 comp.sources.wanted:4185
From: okuyama@pioneer.arc.nasa.gov (Darin Okuyama YR)
Subject: call graph tool
Summary: call graph tool
Keywords: call graph tool
Organization: NASA Ames Res. Ctr. Mtn Vw CA 94035
Date: Wed, 2 Sep 92 13:59:15 GMT

Does anyone know of a widely available tool
that will produce a call graph of a C program
by reading its source.

Darin Okuyama
NASA Ames Research Center