HDTenEightyP/NetNews huggingface dataset:
From: boehm@parc.xerox.com (Hans Boehm)
Newsgroups: comp.lang.c
Subject: Re: Allocate memory to typed in string, How?
Date: 14 Aug 92 21:31:55 GMT
Organization: Xerox PARC

alpha@wyvern.twuug.com (Joe Wright) writes:

>Attempts to allocate memory, char at a time, to an arbitrary 'string'
>is silly even if it is possible.  If a string is assumed to be a line
>of a text file or arbitrary keyboard input, we can easily declare that
>it must not be longer than (let's say) 256 bytes.  Given that screens
>are usually 80 to 132 chars wide, 256 will be wide enough for the
>Ivory standard (99.44 % pure).  Having captured the line in our big
>static buffer we can easily determine its length and allocate memory
>and/or file space for the actual string.  If you don't like static 
>strings, allocate 256 bytes, read the 'string' into it, find its length,
>allocate that much (+1) and copy it.  Lots faster..

If you do this, PLEASE at least check for buffer overflow.  Not doing
so properly has led to lots of amusing phenomena that I could do without:

1. My 6 month old crashing my workstation whenever he got near the keyboard.
(It's hard to teach a 6 month old that he should hit RETURN every 256
characters.)

2. The internet worm.

3. A neat way to turn on debugging output for some versions of ftp.  (Type
in a sufficiently long filename.)

4. All sorts of interesting results when I try to use UNIX utilities on
text files that have no newlines within a paragraph (thus avoiding
reformatting when I change screen size).

If you use a static buffer, don't try to reuse the code with a threads
package.  If you malloc the buffer, it's easy to double its
size when it overflows.  It's guaranteed not to slow down code that
doesn't use it.

Hans-J. Boehm
Newsgroups: comp.lang.c
Organization: Penn State - Erie
Date: Mon, 17 Aug 1992 09:36:48 EDT
From: Ron McCarty <RON@psuvm.psu.edu>
Newsgroups: comp.lang.c
Subject: summary responses on CXL

A while back I posted a request for information about a shareware package
called CXL (C eXtended Library). In true net fashion, I received the
information I needed very quickly and from several people. Thanks to
everyone who responded to my query.

For anyone else who might be interested in CXL, this is what I found out:

> Mike Smedley sold CXL to Innovative Data Concepts some years ago.
> It's now called TCXL, and is, I believe, no longer shareware.  At
> least, I've seen ads for it from commercial vendors of software.
>
> This is the latest address I have:
>
> Innovative Data Concepts, Inc.
> Suite 5
> Hatboro, PA 19040
> Voice: 1-215-443-9705
> Orders: 1-800-926-4551
> FAX: 1-215-443-9753
>
> --
> Anders Thulin       ath@linkoping.trab.se
> Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden

I contacted IDC and they are sending me demo disks. They have a
DOS version for $99 and a windows version for $69.

I received mixed reviews from netters on the TCXL package. Everyone
who responded to me who expressed an opinion liked the original CXL
but 2 netters told me that the new TCXL is buggy and is quite different
than the original CXL, with many of the old functions gone and others
substantially reorganized (a bummer if you already have applications
built around the original).

On the other hand, another netter had high praise for TCXL saying that it
was a much more mature product than the original.

I can not offer an opinion of my own since I have not yet seen TCXL. So
this post is not meant to be an endorsement or a sales pitch for the
product. I simply offer it as information.

Thanks again to everyone who helped me out.

Ron McCarty
Penn State Erie
Erie PA 16563
(814) 898-6252 (W)
(814) 825-3678 (H)
Newsgroups: comp.lang.c
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Subject: Re: Pointer/address reluctance
Originator: sasghm@theseus.unx.sas.com
Date: Thu, 13 Aug 1992 17:28:22 GMT
Organization: SAS Institute Inc.


In article <l8kteaINNp2c@exodus.Eng.Sun.COM>, linden@positive.Eng.Sun.COM (Peter van der Linden) writes:
|> Can anyone explain the reluctance that some of the experts here
|> have in equating "pointer" with "address"?
|> 
|> The ANSI C standard displays no such inhibition, e.g. Section 3.4
|> line 32 mentions "An address constant is a pointer to ..."
|> 

First (and pardon what may appear as pedantry), the section you
quote does *not* "equate" a pointer with an address.  In fact, I
am unaware of anywhere the standard discusses the concept of *address*.
The section you quote (as well as section 3.3.3.2) establishes
a relation between a *pointer* and an *address constant*.  An
*address constant* is a kind of *constant* (it is *not* an address),
and a *pointer* is a type in C.  There is no type in C called
"address".  Thus, in part, the reluctance you sense may simply be
a resistance to "equating" a formal and precise concept (pointer)
with an informal concept (address) that is not given precise meaning
in the standard.

Beyond this, while there is a clear intuitive association of
"pointer" with "address", one may want to leave open the possibility
of implementing pointers as something other than addresses (perhaps
as an address together with some other component).  In theory,
I suppose one could conceive of an "abstract machine" and an
implementation of C for this machine that did not implement a pointer
as an address.  The semantics for C leaves this open (and should).
To do otherwise would be to limit the applicability of the language
by an arbitrary restriction on its semantics.

The issue here is conceptual and semantic.  To "equate" a pointer
with an address is akin to equating "array" with "contiguous sequence
of memory locations".  In short, it is to confuse a concept (or type)
with one *possible* implementation of that concept.  An array is
*usually* implemented as a contiguous sequence of memory locations,
but it need not be.  What characterizes an array is its "algebra" --
the set of operations that may be performed on it, the closure
conditions of such operations, etc.  Similarly for "pointer".
-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Paranoia, side effects, and optimizing compilers
Date: 18 Aug 1992 18:47:30 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <DAVIS.92Aug14120003@pacific.mps.ohio-state.edu>
davis@pacific.mps.ohio-state.edu ("John E. Davis") writes:
>     unsigned char *p;   
>     while (1)
>       {
>          p = CLine->data + Point;
>          if (*p > ' ') break;
>          del();
>       }

Just as a side note, I would probably rewrite this as:

	while (CLine->data[Point] <= ' ')
		del();

>Here CLine->data is a pointer of same type as p and Point is an integer.
>del() is a routine that has that might possibly do a realloc on
>CLine->data so p might change in the loop.

>Would an optimizing compiler asssume that p will not change in the loop,
>evaluate it once and assume it is fixed in the loop?  [or should I make
>p `volatile']

Short answer: if so, it would be broken.

In article <BszL5o.B0s@pgroup.com> lfm@pgroup.com (Larry Meadows) gets
this right.  He goes on to say that

>volatile is only necessary for variables that might change due to events
>that aren't explicitly specified (e.g., shared memory multiprocessor
>systems, setjmp-longjmp, interrupt handlers, external hardware).

More precisely, those that might change *or be accessed*: compilers
can move or eliminate assignments to nonvolatile variables, provided
this is not detectable through proper C language constructs.  Volatile
variables are (aside from longjmp and signals, where the standard wimps
out :-) ) those that are used in some way ``outside'' the language.
This includes things like programs or hardware that scan shared memory,
as well as those that change them.

In article <9222819.26380@mulga.cs.mu.OZ.AU> baillie@cs.mu.OZ.AU
(Stephen Baillie) writes:
>Strangely enough, it depends on the compiler.  For example, Microsoft's
>C/C++ 7 gives one two options on this - /Oa to assume that there is no
>aliasing (function calls do not change variables) and /Ow for weak
>aliasing (function calls may change variables, but things in the code don't)

These options are nonconformant.  Microsoft has chosen to give you
several ways to say: ``compile a language that resembles C, but is not
actually C'', because programs written in those other languages are
easier to compile.  As a result, if you write programs in those other
languages---whether deliberately or accidentally---Micosoft's not-
quite-C version of the compiler may produce faster object code.

(Whether these `weakened' version of C are a Good Thing depends on
one's point of view.  It is far easier to get in trouble with them; but
on the other hand, it is far easier to write a compiler that produces
faster code with them.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: u8903845@cs.uow.edu.au (Anil Sachdeva)
Newsgroups: comp.lang.c
Subject: Graph Algorithms Implementation ?
Date: 13 Aug 92 14:02:46 GMT
Organization: Dept of Computer Science, Wollongong University, Australia

Hello

I would be thankful if somebody could send me code for these graph problems.

Firstly i am trying to check if the graph is connected or not .

Then I check for cycles in the graph .

If the implementation of the graphs is on some ftp sites i would be thankful
if you could let me know that site .




e.g

If i have the following graph


         J
	 |
	 |
  A------B-----C-----D			W-------X--------Y
	 |     |
	 |     |
         E-----F

Then these two graphs are not connected and their is a cycle BCFEB

Thanks a lot

Anil

email : u8903845@cs.uow.edu.au
Newsgroups: comp.lang.c
From: mjs@hubcap.clemson.edu (M. J. Saltzman)
Subject: Re: sort routines
Organization: Clemson University, Clemson SC
Date: Thu, 13 Aug 1992 20:11:57 GMT

In article <1992Aug13.170424@axion.bt.co.uk> pkeddie@axion.bt.co.uk (Paul Keddie) writes:
>
>How do people sort a single linked list in a C program ? I know there
>is thw qsort routine but that seems to assume you know the maximum possible
>size of the list. 
>
>Do you just have to resort to writing your own routine, and if so which is the
>best for a single linked list data structure (insertion,bubble.etc).

If you want to actually sort the linked structure, you need to write a
merge or bucket sort to do it (insertion sort would work, but is
probably slower--insertion sort is what you would do if you built the
list in sorted order to begin with).

On the other hand, what about creating an array of pointers to
elements of the list, and running qsort() on it, then rebuilding the
list?  Yes, you need to know how many elements are in the list, but
only at the moment you do the sort.  You can malloc() the space for
the array at that point.

If its a big list, or you are sorting it frequently or searching it
frequently, you might think about using some other data structure
(like a tree), or using a heuristic to cut down on access times in an
unsorted list (such as moving the most recently accessed element to
the front), depending on the characteristics of the list access
requests.

>Cheers Paul
>Software Maintenance Group, Software Technology Division, BT
>Research Labs, Martlesham Heath, Ipswich, IP5 7RE, UK
>E-mail:  pkeddie@axion.bt.co.uk
>Phone:  +44 473 649154
>Fax:    +44 473 643019 


-- 
		Matthew Saltzman
		Clemson University Math Sciences
		mjs@clemson.edu
Newsgroups: comp.lang.c
From: hm342st@unidui.uni-duisburg.de (Michael Staats)
Subject: Re: POWER OF LARGE NUMBERS
Date: 20 Aug 92 08:03:39 GMT
Organization: Rechenzentrum Uni-Duisburg

In <hm342st.714231186@unidui> hm342st@unidui.uni-duisburg.de (Michael Staats) writes:

>In <1992Aug19.140602.1509@tac.fi> tiok_ks@tac.fi writes:

>>In article <thompson.714156001@daphne.socsci.umn.edu>
>>thompson@atlas.socsci.umn.edu (T. Scott Thompson) writes:

>>> Alright!  Who volunteers for 7 ^ (7 ^ 7)?
>>>                                 ...
>>>                              10 ^ (10 ^ 10) ?
>>> 
>>> P.S.  Mathematica 2.1 on a Sparc 2 does 6 ^ (6 ^ 6) in 5.02 CPU seconds.

>>OK, I can do the latter one - after all, it's greater:

>>1E+10 000 000 000

>>It took about 4 seconds of my personal CPU, but my
>>hands are slow, so it took about 10 secs of I/O time.
>>But after all, that's an exact number... ;-)

>>Now, who's going to calculate the smaller ones, like
>>7 ^ (7 ^ 7) ?

>Now I don't think it's too complicated. The answer is of course

>1E+10 000 000 000 (Base 7)

>It took me and a friend about one minute CPU time (two
>parallel processors) to verify this solution, I/O was about
>the same.

>So long
>Michael

I'm very sorry, this is NOT the correct answer. I found that some
hours after posting the quoted article (again some CPU seconds on
one processor) but had no terminal available, so with some delay:

The correct answer should be

1E+10 000 000 (Base 7).

(That's one of the disadvantages of these bio-cpu with their complex
OS: They make mistakes. But one of the major advantages is: They might
find out they made a mistake :-)

Michael
-- 
Michael Staats
Theoretische Tieftemperaturphysik
Universitaet Gesamthochschule Duisburg
michael@hal9000.uni-duisburg.de
Newsgroups: comp.lang.c
From: goudreau@batman.rtp.dg.com (Bob Goudreau)
Subject: Re: Pointer/address reluctance
Date: Tue, 18 Aug 92 16:52:51 GMT
Organization: Data General Corporation, RTP, NC

In article <l906giINN4rl@exodus.Eng.Sun.COM> linden@positive.Eng.Sun.COM (Peter van der Linden) writes:
> > You are perfectly free to redefine 'address' to mean 'pointer.' 
>
> It's not a redefinition, as it is already used in the ANSI C standard
> with this meaning.   

Beg your pardon?  I can find no definition of a thing called "address"
in the standard.  The closest I can come is section 3.3.3.2, which
describes an *operator* called "address-of".  This operator most
certainly does not yield an address, but a pointer:

	The result of the unary & (address-of) operator is a pointer
	to the object or function designated by its operand.  If the
	operand has type ``_type_'', the result has type ``pointer to
	_type_''.

----------------------------------------------------------------------
Bob Goudreau			Data General Corporation
goudreau@dg-rtp.dg.com		62 Alexander Drive	
+1 919 248 6231			Research Triangle Park, NC  27709, USA
Newsgroups: comp.lang.c
From: greyham@research.canon.oz.au (Graham Stoney)
Subject: Re: I wish ANSI-C sizeof (void) == 1 (was Re: preprocessing subterfuge)
Organization: Canon Information Systems Research Australia
Date: Tue, 18 Aug 1992 01:09:45 GMT

volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe) writes:
>In article <BswME5.6Mp@research.canon.oz.au>, greyham@research.canon.oz.au (Graham Stoney) writes:
>|>                   void * is the natural type to use when you're considering a
>|> pointer to a chunk of memory that can hold any arbitrary type; in the Unix
>|> kernel for instance it seems a natural replacement for caddr_t. And any time
>|> I need to do arithmetic on one, it's always in terms of bytes - it would be
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>If you need to do arithmetic on one, then the variable should not be declared
>as "void *" in the first place. That type is for pointing to objects whose
>size you don't know. If you know you're going to be dealing with arrays of
>bytes, then declare it as "[unsigned] char *". 

Yes, but I'm _not_ dealing with arrays of bytes. I'm pointing to arbitrary
locations which store as yet unknown types. One example is converting a
pointer in shared memory from one virtual address space to another. Another
is adding the base address of a hardware device to the address at which the
block of address space in which it resides is mapped. You really aren't
dealing with arrays of bytes, just memory addresses; you can't dereference
them, but sometimes you need to add to them.

Graham
-- 
Graham Stoney                    | "a Perl script is correct if it's halfway
Flip Dibner fan club, "Hi Flip!" |  readable and gets the job done before your
Ph: +61 2 805-2909  Fax: -2929   |  boss fires you." L. Wall & R. Schwartz
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Help: read() question.
Date: 21 Aug 1992 21:08:18 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <1992Aug21.154401.5050@gw.wmich.edu> 754clifton@gw.wmich.edu writes:
>Assuming I have a file I have found the exact size (len) of using lseek or
>some other method. Assume also that I have a valid file descriptor ...

What is a `file descriptor', and where is `lseek' in the C standard?

>	nread = read(fd, buf, len); 

You have not shown us your `read' function.  Can we please keep UNIX
and MS-DOS and other system-specific questions to system-specific
groups?

To answer the question anyway:  UNIX never promised to read exactly as
many bytes as you ask for.  Most UNIX *implementations* happen to do it
when the underlying file is a `disk file', but that is a side effect of
the implementation, not a design feature.  I cannot speak for other
operating systems.  Since you did not name the OS, the question is in
fact unanswerable.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: andrew@teslab.lab.oz.au (Andrew Phillips)
Newsgroups: comp.lang.c
Subject: Scaled random number (Was: Matt Dillon's DICE (Amiga C) and rand() function)
Date: 16 Aug 92 22:09:45 GMT
Organization: Technology Services, Chief Secretary's Dept, Sydney

I tried to mail this but it bounced:

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

: Suppose you want to generate integers in the range 0..N-1,
: with each integer being equally likely, and that you have
: a rand() function which delivers integers in the range 0..RANDMAX
: with each integer being equally likely.
: Then r%N will indeed give you integers in the range 0..N-1,
: but unless (RANDMAX+1)%N == 0, they will NOT be equally likely.

Yes that is a problem.  Another problem is that most random number
generators (even good ones) are not very random in their least
significant digits.  So if N=2 you could get a sequence like
0,1,0,1,0,1 ...

The proper way is to use the most significant digits:

#include <stdlib.h>

#define RANDN(N)	((int)((rand()*(unsigned long)N)/(RAND_MAX+1)))

This should be OK for even large values of N since RAND_MAX is
usually very much smaller than ULONG_MAX.  This is also probably not
much less efficient than rand()%N since RAND_MAX+1 is usually a power
of 2 and a good compiler will change the division into a shift.

Also note that according to Standard C the maximum value returned by
rand() is RAND_MAX (note the underscore) not RANDMAX.

--
Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney) 287 6551
From: jbc@hpcuhe.cup.hp.com (Jeff Caldwell)
Date: Wed, 12 Aug 1992 05:09:40 GMT
Subject: Re: How can a program know where it was invoked?
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.lang.c

>
>jbc@hpcuhe.cup.hp.com (Jeff Caldwell) writes:
>:One rudimentary method is to use "system".  Compile the following and run it:
>:
>:     #include <stdlib.h>
>:     
>:     main(argc, argv)
>:      int argc;
>:      char     *argv[];
>:     {
>:        char string[20];
>:        sprintf(&string, "which %s", argv[0]);
>:        system(string);
>:     }
>
>Unfortunately, this assumes that you're running the default version of a
>binary.  As a simple example of how this won't work, there are two C
>compilers on SINIX machines; the CES system, and the CCS system.  If my
>PATH is /usr/ccs/bin and I call /usr/ces/bin/cc (which we'll pretend
>uses the above code for some reason), funny things happen.
>

Ahhh but notice that the string we are sending to "what" uses argv[0].
"what /usr/ces/bin/cc" will return /usr/ces/bin/cc, not the path search 
for cc.

			-Jeff Caldwell
Newsgroups: comp.lang.c
From: twpierce@amhux1.amherst.edu (Tim Pierce)
Subject: Re: Allocate memory to typed in string, How?
Organization: Amherst College, Amherst MA
Date: Tue, 18 Aug 1992 04:34:05 GMT

In article <1992Aug14.194448.10225@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes:

>alpha@wyvern.twuug.com (Joe Wright) writes:
>
>>Attempts to allocate memory, char at a time, to an arbitrary 'string'
>>is silly even if it is possible.  If a string is assumed to be a line
>>of a text file or arbitrary keyboard input, we can easily declare that
>>it must not be longer than (let's say) 256 bytes.  Given that screens
>
>Obviously you don't have a cat "helping" you do your input.  :-)  This
>also applies to leaving a book pressing against a key.  Even if only a
>single character is allowed, accidents do happen and the system should
>be able to cope.

fgets() is excellent at this sort of thing, so you shouldn't really
have to provide a custom-written routine to handle arbitrarily long
strings.  The question is whether you really want your application to
handle such strings in toto; I can't think of any applications where
this would be necessary, but I'm dubious of Joe's claim that there
exist none.

-- 
____ Tim Pierce                / "Bisexual just means you pay for it."
\  / twpierce@amherst.edu      /  
 \/ (BITnet: TWPIERCE@AMHERST) /   -- Rock Hudson
From: sammy@anagld.analytics.com (Sam Blackburn)
Newsgroups: comp.lang.c
Subject: Re: function pointers
Date: 23 Aug 92 13:52:31 GMT
Organization: Computer Sciences Corporation - Systems Engineering Division

sbhatia@mary.fordham.edu (SABU) writes:


>if(func == NULL)
>..
>else
>..
>In essence I want to either pass a function or a null pointer to indicate
>an alternate processing approach.

Sure, a pointer is a pointer is a pointer.  My suggestion would be to
typedef your function and then cast NULL to prevent any compiler warnings.

typedef int (*MYFUNC)( int, int ); // MYFUNC is a pointer to a function that
                                   // accepts two ints and returns an int

compute( x, function )
int x;
MYFUNC function;
{
   if ( function == (MYFUNC) NULL )
   {
      return( x );
   }

   return( (*function)( x, 14 ) );
}

Some compilers allow you to call function( x, 14 ) directly while others
require you to dereference the pointer first.
Newsgroups: comp.lang.c,comp.programming
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: A LITTLE BRAINTEASER...
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Fri, 14 Aug 1992 11:50:26 GMT

I'm so pleased to see that these solutions that contain _no data structures_
also contain _no code at all_  -- get a grip...


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
From: scotth@felix.filenet.com (Scott Hopson)
Newsgroups: comp.lang.c
Subject: Re: WANTED:  Simple Windows source code.
Date: 16 Aug 92 19:42:29 GMT
Reply-To: scotth@fritz.filenet.com (Scott Hopson)
Organization: FileNet Corp., Costa Mesa, CA

In article <1992Aug14.122133.1441@lub001.lamar.edu> williford@lub001.lamar.edu writes:
>
>	I am looking for some simple sorce code for a Windows program.  I would
>like to start playing with programing Windows programs. I have the Borland C++
>compiler.  Any simple source would be greatly appreciated! 

If you have a legel copy of Borland C++ then you have some simple windows
source code already. It comes with the package. If you don't have a legal
copy then you should get one.

If you go to the book store you should be able to find several books with
examples on using Borland C++ to create Windows applications.

Try Crown Books they usually have a few books for Borland users.


-- 
Scott Hopson   (scotth@filenet.com)
Xref: sparky comp.lang.c:12238 comp.programming:2289