HDTenEightyP/NetNews huggingface dataset:
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: Allocate memory to typed in string, How?
Date: Fri, 14 Aug 1992 19:44:48 GMT
Organization: D'Arcy Cain Consulting

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.

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |
Newsgroups: comp.lang.c
From: bjornmu@idt.unit.no (Bj|rn P. Munch)
Subject: Re: general tree
Reply-To: bjornmu@idt.unit.no (Bj|rn P. Munch)
Organization: Div. of CS & Telematics, Norwegian Institute of Technology
Date: Wed, 12 Aug 92 19:25:29 GMT

In article <6t4myyq.qualtrak@netcom.com>, qualtrak@netcom.com (Qual Trak) writes:
|> In article <1992Aug12.092635.27271@ugle.unit.no> bjornmu@idt.unit.no (Bj|rn P. Munch) writes:
|> >In article <chuckb.713584418@milton>, chuckb@milton.u.washington.edu (Chuck Bass) writes:
|> >|> bjornmu@idt.unit.no (Bj|rn P. Munch) writes:
|> >|> 
|> >|> >In article <1992Aug11.200208.19716@infonode.ingr.com>, dpm@wizard.b29.ingr.com (David Mikesell) writes:
|> >|> >|> 
|> >|> >|> I am beginning work on a C program that will manipulate a general tree, i.e.
|> >|> >|> a tree in which each node can have an arbitrary number of children.  An ex-
|> >|> >|> ample declaration of the structure follows:
|> >|> >|> 
|> >|> >|> struct node
|> >|> >|> {
|> >|> >|>     DATA        data;
|> >|> >|>     struct node *parent;
|> >|> >|>     struct node **children;
|> >|> >|> };
|> >|> 
|> >|> >In stead of putting the children into an array (what do you do if this
|> >|> >array suddenly isn't big enough?), you may consider putting them in a
|> >|> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> >|> This is a perfect time to use something like ... realloc.
|> >
|> >I also thought about realloc(), but soon realized this would be a
|> >rather bad idea.  Maybe I should have explained why...
|> >
|> >Remember: realloc() may move your array to another address.  If you
|> >have references to the children that were stored there (like parent
|> >pointers in _their_ children), then you're in deep trouble.
|> >
|> 
|> Seems to me realloc () will work quite adequately if you reference the
|> children pointer explicitly thru the node - i.e.
|> 	struct node *nodeptr, (nodeptr1;
|> 
|> 	nodeptr1 = nodeptr->children [0];
|> 
|> Will always return you the same value even if nodeptr->children has been
|> realloced ();

Oops, my mistake.  "children" is an array of _pointers_ to nodes, so of
course it doesn't matter if they are moved by realloc().  The nodes
themselves do not move and the pointers are still valid.....

I still like the sibling list, though.  You may need one more pointer
dereferencing to get at each child, but you save the address
calculation needed for indexing.  Of course, if you often need to get
directly at child number N > 1, the array is far more efficient.

And if you look carefully, you will see that the array soultion
actually requires more space.  Both use three pointer per node, but
you may have more malloc() fragments, plus you need to store # of
children.

Well, I guess the most important factor is how this tree is going to
be used.  Either approach would be best in some cases.

---
Bj|rn P. Munch               | Dept. of Comp. Science & Telematics,
Bjoern.P.Munch@idt.unit.no   | Norwegian Institute of Technology (NTH),
PhD Student                  | N-7034 Trondheim, Norway
 (some filler words here)    | Fingerable addr:  bjornmu@multe.idt.unit.no
Newsgroups: comp.lang.c
From: baillie@cs.mu.OZ.AU (Stephen Baillie)
Subject: Re: Paranoia, side effects, and optimizing compilers
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 15 Aug 1992 09:26:54 GMT

davis@pacific.mps.ohio-state.edu ("John E. Davis") writes:

>Hi,

>   Consider:

>      unsigned char *p;   
>   
>      while (1)
>        {
>           p = CLine->data + Point;
>           if (*p > ' ') break;
>           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?  In this case, I would
>want to declare it as volatile but I'd rather not worry about these issues.
>Or should I?

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)

Hope this helps,

Steve.
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Using fscanf with files
Date: 22 Aug 92 10:56:31 GMT
Organization: AND Software BV Rotterdam

In article <1992Aug22.052345.3597@lugb.latrobe.edu.au> CS19241103D@LUST2.LATROBE.EDU.AU (TELFORD, ROD) writes:
|
|I was wondering if it is possible to read in a string, from a file, which
|contains spaces using fscanf()
|
|basically I want to read in a line terimnated by a line feed using fscanf()

Well, personally I would use the fgets() function here. This function
simply reads a line from a file, but if you insist using fscanf for
this, I'd suggest using the character class format:

	fscanf(file, "%[^\n]\n", buffer);

The format specification %[<characters>] reads a string from the input
file as long as the input characters match one of the characters in
<characters>. A leading caret (^) reverses the test: fscanf continues
reading the input file as long as the input characters do _not_ match
one of the <characters> chars.

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c
From: sdarbha@ho19.eng.ua.edu (Subrahmanyam Darbha)
Subject: Malloc and Calloci 
Organization: The University of Alabama, Tuscaloosa
Date: Wed, 19 Aug 1992 03:48:41 GMT

I have a problem understanding the difference between calloc and malloc
because in my code malloc seems to be working and calloc does not seem to be
Can anybody enlighten me on this ?
Thank you

-- 
*************************** Who else But Darbha ******************************* 
sdarbha@buster.eng.ua.edu     Res: (205) 349 - 5143   Off: (205) 348-9289
*******************************************************************************
From: bsullivn@sc.sni.ie (Bryan O'Sullivan)
Newsgroups: comp.lang.c
Subject: Re: String hashing algorithms
Date: 18 Aug 92 09:01:57 GMT
Article-I.D.: sc.161
Reply-To: bryan@sc.sni.ie
Organization: Siemens-Nixdorf Software Development Centre, Dublin
X-Newsreader: Tin 1.1 PL3



wolf@hubcap.clemson.edu (Randy Martin) writes:
: Does anyone have any string hashing algorithms that are very fast and
: produce few collisions?  

I don't have any source to hand, but Peter Weinberger's hashpjw
algorithm seems to produce consistently good results and few collisions.
A listing can be found in K&R2 or the 1985 edition of the Dragon book
(Aho, Sethi, and Ullman).

	-- Bryan

-- 
Bryan O'Sullivan                                             +353-1-767551 x225
Siemens-Nixdorf Informationssysteme AG                          bryan@sc.sni.ie
Software Development Centre                    "Theory like mist on eyeglasses.
Dublin                                          Obscure facts." -- Charlie Chan
From: desmarai@ERE.UMontreal.CA (Desmarais Normand)
Newsgroups: comp.lang.c
Subject: Succes! (was: Linker Error: Segment _TEXT exceeds 64K)
Keywords: BC++ 2.0, Linker Error, _TEXT
Date: 21 Aug 92 15:50:06 GMT
Organization: Universite de Montreal


	Ok!  There is no more Linker Error since I change the memory
model to Medium size.  Thanks to

	Alexander Kardanev,
	Timothy D. Goss and
	Ander Thulin

for the hint!

Norm.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.lang.c
Subject: Re: Memory alignment of struct elements
Date: 18 Aug 92 16:27:15 GMT

adam@microware.com (Adam Goldberg) writes:
>That's all well and good, but what if, say, you are coding an implementation
>of LIM EMS 4.0, which takes as a parameter a structure which, in assembler,
>looks like this:
>Parm Struct
>MemIn      dd   ?   ; 4 bytes
>MemIType   db   ?   ; 1 byte
>MemISize   dw   ?   ; 2 bytes
>MemOut     dd   ?   ; 4 bytes
>MemOType   db   ?   ; 1 byte	
>MemOSize   dw   ?   ; 2 bytes
>Parm Struct

>In C, this *could* be :
>typedef struct PARM {
>  char *MemIn, MemIType;
>  short MemISize;
>  char *MemOut, MemOType;
>  short MemOSize;
>} PARM, *pPARM;

>Except for the addition of superflourous padding bytes.  Is there any
>standard way to FORCE the C Struct to be identical to the Asm struct?

>No, I didn't think so.  There ought to be, though.

If your C programming environment requires this capability, you should demand
that the vendor of your C compiler provide it for you as an extension.  Don't
demand that the Standard require features that *aren't* easily implementable
on CPUs not designed as washing-machine controllers :-).

>I've been forced to do nasty things like:
>typedef struct PARM {
>  char MemIn[4], MemIType, MemISize[2];
>  char MemOut[4],MemOType, MemOSize[2];
>};
>Then on each usage of, say 'MemOut', I've got to:
>   (char *)(p->MemOut)

Nasty hardware makes you do nasty things.  Please don't insist that the
language be as nasty as the nastiest possible piece of hardware (ugh).
Newsgroups: comp.lang.c
From: stern@mble.philips.be
Newsgroups: comp.lang.c
Subject: Re: Any one who have used "TURBO VISION" in BORLAND C++ 3.0?
Date: 12 Aug 92 08:53:54 MEWT
Organization: MBLE , Brussels, Belgium

In article <1992Aug11.144050.10833@alf.uib.no>, eystein@smyril.fi.uib.no (Eystein Dugstad) writes:
> I would like to get in touch with any one who's using "Turbo Vision"
> 
> More specifically I wonder if it's possible to get a graphics window on  
> the screen while the rest of the TV interface is intact.
> 
> Answers are appreciated by email or on usenet
> 
> Eystein Dugstad
> University of Bergen

I'm currently using TV 1.03 (the version included in BC++ 3.1) to develop
a big professional project. After a few days studying the examples and the
doc I began to specify and to code my application (Yes, it is an interactive
process since I didn't really know what I could do with the package and how).
I must admit that almost anything I needed was included in the package:
lists without any data in memory (the acces method is user-defined),
interactions between dialog boxes,...

Even if it isn't always simple to guess which mechanism to use, you can
easily read the examples and the sources (fortunatly it is well-coded
in C++ which is readable because there aren't almost any comment).
I now have a very powerful and complex application and it works!!!

The only two points I have to tudy know are how to have a multiple-choice
list (like TCheckBox but with any number of items - at least more than 16)
and how to put my modules in overlay because I still have a problem to overlay
my own modules using TV.

For the graphical question, I found on SIMTEL something for Turbo Pascal
which you link with your application (it's a TPU) and, miracle, your program is
now in graphical mode. (You only have to add an initialization line).
By a graphical application I mean that you open a file-viewer window like
in text mode but you also can open a grphical window on the desktop with an
animation in it; and you always have the ability to move/resize/zoom all the
windows. It looks great, BUT... is it usable with C++ version ?
I contacted the author and wait for an answer.
Some more info in the future



--  Marc Stern  <stern@mble.philips.be>
Xref: sparky comp.lang.c:12395 comp.programming:2345
From: CS19241103D@LUST2.LATROBE.EDU.AU (TELFORD, ROD)
Newsgroups: comp.lang.c
Subject: Using fscanf with files
Date: 22 Aug 92 05:23:45 GMT
Organization: La Trobe University
X-News-Reader: VMS NEWS 1.22


I was wondering if it is possible to read in a string, from a file, which
contains spaces using fscanf()

basically I want to read in a line terimnated by a line feed using fscanf()

Thanks.

_______________________________________________________________________________
 \  /\  /\  /                    Rod Telford.                      \  /\  /\  /
  \/  \/  \/           CS19241103D@LUST1.LATROBE.EDU.AU             \/  \/  \/
  /\  /\  /\   -------------------------------------------------    /\  /\  /\
 /  \/  \/  \      %STRESS-E-OVERLOAD,     Dispositon Dumped       /  \/  \/  \
-------------------------------------------------------------------------------
Newsgroups: comp.lang.c,gnu.gcc,gnu.gcc.help
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: gcc-cpp chokes: bug or feature?
Summary: it's a feature : -)
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 14 Aug 1992 22:06:10 GMT

leland@cs.columbia.edu (Leland Woodbury) writes:

>#if 0
>I don't have much experience with gcc, I started using it only
>recently.  And I'm in the habit of using the C preprocessor (as shown
>here) rather than /* */ to delineate most multi-line comments, because
>I think it's more elegant and less likely to result in error.  But
>gcc-cpp chokes on any line within such text that contains an odd number
>of single quotes, complaining about unterminated character constants.
>(Run gcc on the file containing this message for a demo.)
>
>I haven't looked at the source code, but does this make any sense to
>anyone?  Is there something in ANSI C that requires such behavior?
>Obviously, gcc-cpp is parsing -- in a line-oriented fashion -- the text
>between the #if 0 and the #endif, but what's it looking for (besides
>#else or #endif)?  Why is it parsing what should be getting ifdef'd
>out?
>
>Leland Woodbury
>#endif

Sorry, but it's a feature. Your entire program must consist of legal
lexical tokens. (Many K&R preprocessors let you get away with murder,
but ANSI C is a lot more strict with regard to preprocessing.)

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c
From: pt@geovision.gvc.com (Paul Tomblin)
Subject: Re: spin the wheel
Reply-To: pt@geovision.gvc.com
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario
Date: Tue, 18 Aug 1992 00:50:11 GMT

U56779@uicvm.uic.edu writes:

>Can anybody tell me a code in c to spin the wheel after drawing it.
>thanks...

I've heard of _reinventing_ the wheel, but....
What the f*ck are you talking about?

-- 
Paul Tomblin, pt@geovision.gvc.com
(This is not an official opinion/statement of GeoVision Systems Inc.)
Anybody who doesn't wear a helmet when biking probably _will_ have their head
examined - by a coroner
Newsgroups: comp.lang.c
From: jsanders@symcom.math.uiuc.edu (John Eric Sanders)
Subject: Re: Array of pointers to structures
Organization: Math Dept., University of Illinois at Urbana/Champaign
Date: Tue, 18 Aug 1992 17:58:58 GMT

Thanx to all that helped--this is new territory and my brain must have
been fried when I tried it the first time.  (I think I was trying
*ptr[x].elment[y] to access the data.)  Looking at the examples, and
with the words of wisdom from everyone, it looks like my code will
work now (using ptr[x]->elment[y], or (*ptr[x]).elment[y])

Thanks again.    


-- 
 The Jester (John E. Sanders)       jsanders@symcom.math.uiuc.edu       
 I have finally discovered the method to my madness.  Unfortunately,    
 there is more madness to my method than method to my madness.
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Newsgroups: comp.lang.c
Subject: Re: Pointer/address reluctance
Date: 14 Aug 92 21:50:12 GMT
Organization: UIUC SCS

In article <14807@ksr.com> jfw@ksr.com (John F. Woods) writes:

>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"?

>Because as soon as someone slips and admits that "addresses" are one possible
>scheme for implementing "pointers", dozens of non-experts start posting
>ancient misunderstandings and silliness based on how things work on their
>peecee, thus driving all of the experts to drink heavily.  Good Scotch is
>quite expensive, so the insistance upon the abstract nature of pointers is
>a cost-saving measure.


However, in fact pointers **are** addresses of a sort, and the real
programmer nees to understand them if they are to do general programming in
C.

This can, in fact, be proven:

1) General programming includes all the programming that can, and is,
   done in C

2) Some C programming is for interaction with devices, for example,
   direct control of devices from programs and/or device drivers if an OS
   uses such beasties.

3) Some devices use memory mapped magic addresses

4) IF these can be addressed from C, which is usually the case (for example,
   C code running in   "unhosted" mode at the highest privilege level),
   then the usual way to address them  is by actually coding the proper bits
   into an integral variable (or in rare cases the integral part of a union)
   and casing to a pointer.

QED.


Of course, there are some individuals who aren't interested in such 
things ..  or aren't trusted enough to do it.

Doug McDonald
From: u8903845@cs.uow.edu.au (Anil Sachdeva)
Newsgroups: comp.lang.c
Subject: Graph Algorithms ?
Keywords: Graph
Date: 13 Aug 92 10:30:37 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.uo
Newsgroups: comp.lang.c
From: chupchup@ferkel.ucsb.edu (Robert Earl)
Subject: Re: Large memory problem
Organization: (EVIL!)
Date: Sat, 22 Aug 1992 05:21:02 GMT

U37956@uicvm.uic.edu writes:

| The following C code is causing me trouble:

| #include <stdio.h>
| main()
| $ int i;
|   unsigned char *buffer;

|   buffer=(unsigned char*)malloc(480000);

I'm assuming the "$" characters are curly-braces...

You need to declare malloc(); it's in <stdlib.h> on ANSI systems.  The
compiler is assuming malloc() returns an `int', and sizeof (int) is
probably smaller than sizeof (unsigned char *) in this particular
case.

Also, it would help to free() the memory before your program
terminates.

-- 
"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|
From: jrv@truth.uucp (Vanzandt)
Newsgroups: comp.lang.c
Subject: Re: Scaled random number (Was: Matt Dillon's DICE (Amiga C) and rand() function)
Date: 19 Aug 92 17:59:13 GMT
Organization: The MITRE Corp., Bedford, Ma.

In article <4476@teslab.lab.oz.au> andrew@teslab.lab.oz.au (Andrew Phillips) writes:
>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.
>
>The proper way is to use the most significant digits:
>
>#include <stdlib.h>
>
>#define RANDN(N)	((int)((rand()*(unsigned long)N)/(RAND_MAX+1)))
>
>Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney) 287 6551

The division still doesn't give _equally_likely_ integers.  Suppose 
RAND_MAX==7, N==3, and r=rand().  We have the following 8 equally likely
possibilities:
	r	r*3/8
	0	0
	1	0
	2	0
	3	1
	4	1
	5	1
	6	2
	7	2
...so 0 is more likely than 2.  I believe you must discard the original random
number if r/N >= RAND_MAX/N, then you can use r%N or r*N/(RAND_MAX+1).  
If this is done in a function then three divisions, or else two divisions 
and a multiplication, are required.  If it's done in the calling program 
and N doesn't change, then one of the divisions can be moved outside the loop.

                     - Jim Van Zandt <jrv@mbunix.mitre.org>

P.S. Should this be in the FAQ?
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Newsgroups: comp.lang.c
Subject: Re: Memory alignment of struct elements
Date: 13 Aug 92 13:44:23 GMT
Organization: SAS Institute Inc.
Originator: sasghm@theseus.unx.sas.com


In article <1992Aug12.133132.10723@Princeton.EDU>, udalski@astro.Princeton.EDU (Andrzej Udalski) writes:
|> I am writing the software for a big database and the space is very
|> important. If I try to use a 
|> 
|> struct { char ch ; float f }
|> 
|> the compiler (both in SunOS 4.0.1 and Interactive SYSVR3) allocates
|> 8 bytes for it, starting the "f" element at fifth byte of the structure.
|> This makes both reading and writing such records from/to a binary database 
|> file (consisting of 5-byte-long records) very inconvinient, requiring
|> a declaration of character array of 5 bytes and using "memcpy()". Is there 
|> a way to force the compiler to align the struct elements following their 
|> true length?

This depends upon the compiler, of course.  Many compilers have such
an option, but (depending upon the architecture, etc.) it may not
be a good idea to use it.  You might simply try:

	struct { float f; char ch; }

which will not require the internal padding you are encountering.
In general, to avoid such padding you should define your structure
members in decreasing order of alignment requirements.  Note that
the compiler will tend to add padding to the *end* of the structure
in order to achieve correct alignment in *arrays* of such structures.
Still, such an approach may help you.

I would be a little concerned about the maintainability of your code,
however. If things are done in a careful and modular manner (and,
for example, sizes of records, etc. are not "hardcoded"), I do not
see much inconvenience in going to/from the database via an intermediate
buffer.  The danger you need to be aware of, of course, is the
possibility that in the future someone decides to add a new field to
your structure, and either adds it in the "wrong" place (for padding
purposes) or forgets to update routines that access it.  Whatever you
do, you should choose safety and maintainability over any small
gain in what might be thought of as "convenience".


-- 
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