HDTenEightyP/NetNews huggingface dataset:
From: bardo@ief-paris-sud.fr (Bardo Muller)
Newsgroups: comp.lang.c
Subject: undirected graph alg.
Keywords: undirected graph, double linked lists
Date: 23 Jul 92 14:16:26 GMT
Reply-To: bardo@ief-paris-sud.fr
Organization: Universite de Paris

I'm looking for pointers (or C-code, if available) for an 
efficient handling (insert/find/delete) of undirected graphs.
(something like in aho/hopcroft/ullman chapter 2.3 p. 52)

Thank you !

Bardo

___________________________________________________________________________
| Bardo MULLER                          | phone  : [33] [1] 69 41 78 50    |
| Institut d'Electronique Fondamentale  | fax    : [33] [1] 60 19 25 93    |
| Bat. 220 Universite Paris Sud         | e-mail : bardo@ief-paris-sud.fr  |
| 91405 ORSAY CEDEX FRANCE              |             THE NET WORKS !      |
|_______________________________________|__________________________________|
Newsgroups: comp.lang.c
From: mr@obelix.boss.fi (Matti Ropponen)
Subject: Re: About the 'F' in RTFM
Date: Mon, 20 Jul 1992 11:15:39 GMT
Organization: Boss Consulting, Jyvaskyla, Finland

In article <1992Jul17.202448.19848@wyvern.twuug.com> alpha@wyvern.twuug.com (Joe Wright) writes:
> Proposed change to 'standard' practice.  'RTFM' is now 'RTM'.
> The 'F' does not relate to any known adjective for Manual.
> 'Read The Manual' should suffice.

	Nice try Joe, but I still prefer RTFM. It turns your
	'silly questions' off much more efficiently than the
	old fashioned RTM.
--
Matti Ropponen -- mr@boss.fi
Newsgroups: comp.lang.c
From: boehm@parc.xerox.com (Hans Boehm)
Subject: Re: good memory allocation strategies?
Keywords: SGI kernel
Organization: Xerox PARC
Date: 22 Jul 92 19:54:25 GMT

hurst@hyper.hyper.com (Graham Hurst) writes:

>In article <1992Jul21.214115.28569@tamsun.tamu.edu> tsmith@cs.tamu.edu writes:
>...
>>I am working on a moderate size (~10000 lines so far) system on an SGI
>>workstation running UNIX system V.3, and I am wondering about some
>>memory allocation issues. [Rest deleted]

>Beware of using memory allocation on SGI computers!

>We recently discovered a "feature" of the default SGI kernel that makes
>dynamic memory allocation unreliable - it never turns down a request for
>memory!

>Since IRIX 3.3.2, the default SGI kernel will cause malloc/realloc
>(via sbrk) to return a non-zero pointer even if the requested memory size is
>greater than the sum of physical memory and swap space! If your app tries
>to use enough of this memory, the kernel sends a SIGKILL to kill your app
>and puts a message on the console about running out of swap space.

This does increase the probability of crashes due to running out of
swap space.  But the traditional way of checking malloc results is
already somewhat unreliable under most circumstances.  Consider
the following scenario:

malloc(enough space to barely fit in swap space);
call deeply recursive procedure;

On most systems that I know of, your process now gets sent a bus error due
to the inability of the kernel to grow your process stack sufficiently.
You can try to avoid this by growing the stack sufficiently in the beginning,
and catching any bus errors that occur; but if it weren't for the
particularly poor choice of SIGKILL, you could do the analogous thing
for malloc.  (AIX gives you a warning signal first, before it sends
SIGKILL, I believe.  This initially struck me as silly, but I'm begginning
to believe that it's more useful than any of the other alternatives,
including the one in which malloc preallocates swap space.)

Note that similar problems occur if there are other crucial processes
allocating swap space on the same machine.  Copy-on-write pages for
shared libararies are yet another problem.  Malloc is only one consumer
of swap space.

Hans-J. Boehm
(boehm@parc.xerox.com)

Newsgroups: comp.lang.c,comp.lang.pascal
From: sleeger@gaul.csd.uwo.ca (Richard Sleegers)
Subject: Roman Numerals
Organization: Computer Science Dept., Univ. of Western Ontario, London, Canada
Distribution: all
Date: Sat, 1 Aug 1992 00:05:13 GMT
Followup-To: comp.lang.pascal
Summary: Encoding/Decoding Roman Numerals
Keywords: Roman, Numerals

	I'm looking for a Roman Numeral converter in Pascal (preferably) or
standard C.  The successful routine will take in a number and return a 
roman numeral string, and decode routine would take a roman numeral string
and return a number (integer)

Rich

-- 
Richard Sleegers                      sleeger@gaul.csd.uwo.ca
London, Ontario, CANADA               University of Western Ontario
From: gegu@zurich.spectrospin.ch (Gerry Gucher)
Newsgroups: comp.lang.c
Subject: Re: While problem
Summary: readline, bugfix #1
Date: 28 Jul 92 16:58:24 GMT
Organization: Spectrospin AG, Fallanden Switzerland


OOPS, I blew it, ( as always when I shout loudest )


>   while( siz-- > 0 && (c = getc(fp)) != EOF ) {
           ^^^^^
           should be --siz  of course


Gerry 

+------------------------------------------------------------------+
| Gerry Gucher                             gegu@spectrospin.ch	   |
| Spectrospin AG,  Industriestr 26,  8117  Faellanden Switzerland  | 
+------------------------------------------------------------------+
| A program that  returns the  wrong | There is nothing wrong with |
| result twice as fast is infinitely | making  mistakes,  but make |
| slower.               - H. Spencer | new ones.           - D.Sim |	
+------------------------------------------------------------------+
From: mikey@ontek.com (euphausia superba)
Newsgroups: comp.lang.c
Subject: Re: About the 'F' in RTFM
Date: 30 Jul 92 16:43:17 GMT
Organization: Ontek Corporation -- Laguna Hills, California

In comp.lang.c, murphy@npri6.npri.com (David P. Murphy) writes:
| 
| but, pray tell, what does that make the <very bad adjective> person at AT&T
| who decided that [a] no index was needed in the System V reference manuals
| and that [b] the table of contents didn't need page numbers and that
| [c] the "alphabetical" list of commands is only sorted that way _within_
| each group, as in make(1) fork(2) cuserid(3C) sin(3F) and so on.
| 
| oh, and knowing that the commands are in alphabetical order may not 
| may not be of much help, even if you _do_ know the group number.
| for instance, fstat() appears only under stat(2), while fileno() is
| discussed under ferror(3S).  i realize, of course, that this arrangement
| does not inconvenience you at all, fred, and that it is just the dues
| i must pay in order to one day be recognized as a unix guru ---
| coincidentally the same day i will slash my wrists.
| 
| why is the "layout of the manual" so <mind-shockingly rude adjective> sacred
| that no index is prepared??  huh??  c'mon, fred, let's hear some reasons!
| 
| READ BEFORE FLAMING:  the groups mentioned above, and putting fileno()
| under ferror(), is fine . . . or would be, if they would just index it.

I think this is why there's a catman(8).

      the krill
Organization: Penn State University
Date: Wed, 22 Jul 1992 15:53:49 EDT
From: <GNR100@psuvm.psu.edu>
Newsgroups: comp.lang.c
Subject: Macros

      Is there a way to write "generic" macros?  I mean, say I want to
write a macro for a series of functions, but I don't want to have to
change the macro to fit the different variables in each program I use
it in.  Could I write one that will have the variables plugged into it by
the compiler?
                       gnr100@psuvm.psu.edu
From: KOSU_MATSB@ROUTH.KOSUFY.LU.SE
Newsgroups: comp.lang.c
Subject: Concatenation of two macros?
Date: 23 Jul 92 12:00:50 GMT
X-Unparsable-Date: Thu, 23 Jul 92 13:57 GMT+02


	Concatenation of two macros. Is it possible?

	If i have the following two definitions:
		#define A pre
		#define B post
	And want to "#define C" to be  "prepost" BUT as an 
	expression of A and B! How do i do it?
	#define C (expression of A and B to yield prepost)

		Sincerely/Mats B.
 -----------------------------------  -----------------------------------
 Mats Bergstrvm                       mats.bergstrom@kosufy.lu.se
 Div of Cosmic and Subatomic Physics  kosu_matsb@130.235.92.17
 Department of Physics                ROUTH::KOSU_MATSB (ROUTH::=57412::)
 University of Lund                   Phone: (+46)104767
 SWEDEN.                              Fax:   (+46)104709
 -----------------------------------  -----------------------------------
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: About the 'F' in RTFM
Organization: Texas Instruments Inc
Date: Sun, 26 Jul 1992 19:09:28 GMT

In <1992Jul23.155203.11430@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:

>In article <1992Jul17.202448.19848@wyvern.tw>, alpha@wyvern.twuug.com writes:
>|> 
>|> Proposed change to 'standard' practice.  'RTFM' is now 'RTM'.
>|> The 'F' does not relate to any known adjective for Manual.
>|> 'Read The Manual' should suffice.

>The usual interpretation of the F is an accurate description of the quality
>of most UNIX manuals.  The correct response to `RTFM' is "I *did* read it,
>and it didn't answer the question I wanted answered."

At which point, of course, you reach up, pull down the appropriate 
manual, open it up, drop it in front of them and point.  They then
say, "Oh," and walk away looking sheeplike.
-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.c
From: RJONES1@ua1vm.ua.edu (Bart Jones)
Subject: learning C?
Organization: The University of Alabama, Tuscaloosa
Date: Wed, 29 Jul 1992 05:39:25 GMT

   What advice would you all give to a (very) novice who wants to learn C
on the Mac?  Where would I start, and with what?  Books?  Reference?  Programs,
etc....  Any help or advice would be appreciated.
 
 
 
 
 
*************************************************************************
*                                                                       *
*                             BART JONES                                *
*                                                                       *
*                 RJONES1@UA1VM.UA.EDU  --INTERNET                      *
*                 RJONES1@UA1VM         --BITNET                        *
*                 BART JONES            --AMERICA ONLINE                *
*                                                                       *
*************************************************************************
*************************************************************************
 
Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: unsigned long to long without lossage (Help)
Organization: SoftQuad Inc., Toronto, Canada
Date: Fri, 24 Jul 92 06:29:52 GMT

See the referenced articles if you don't remember the context; it would
take an unreasonable amount of quoting to recap the thread before the
posting that I'm responding to here.

> But most machines in use today are neither sign-magnitude nor 1's complemnet
> but rather are 2's complement in which the representation of zero is unique
> (i.e. there is no representation of -0).

This is not disputed, but it is best to avoid depending on 2's complement.
That's why Chris and I had to discuss other representations.

> The much simpler explanation is 
> that in a fixed size integer representation the ranges of allowable values
> for signed and unsigned numbers are DIFFERENT. In typical 16 bit integer
> implementations, for example, the maximum signed small int is 32,767 but
> unssigned ints can have values exceeding that and therefore there is no
> guaranteed way to convert back and forth between signed and unsigned
> ints (small or long) without limiting the range of the unsigned ints.

Also correct.  Conversion from signed to unsigned is guaranteed -- you
always get the value that you'd get in 2's complement by just copying
the bits.  Conversion the other way is not guaranteed.

However, the problem was precisely to work around this fact.  As Chris and
I said, this is best done by asking for the bits to be copied, by using
the type pun "*(unsigned long *)&foo.long" to access the long as an
unsigned long.  Well, actually, it's _best_ done by changing the types
of the variables so that the problem goes away, but we're assuming that
that option isn't available.
-- 
Mark Brader		    "People tend to assume that things they don't know
SoftQuad Inc., Toronto	     about are either safe or dangerous or useless,
utzoo!sq!msb, msb@sq.com     depending on their prejudices."    -- Tim Freeman

This article is in the public domain.
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Turbo C Overlays and getchar problems.
Date: 23 Jul 92 08:40:38 GMT
Organization: University of Helsinki

larrie@beaufort.sfu.ca (Larrie Simon Carr) writes:
>First problem was using getchar, getc, etc to read an ASCII 13.
>Why does this character get ignored?  I can transfer the file
>and the code to a Unix box and everything works fine.

You are probably reading a file in "text mode" instead of "binary mode".
Text mode means that the I/O library may convert the incoming bytes in
more or less any way it wishes so that what the program sees will be
as near as possible to the Unix model in which text files are ended with
a single '\n', i.e. not '\r' then '\n', as in MS-DOS.  In binary mode no
such translation occurs.  (This should be clearly explained in any
decent C book.)

>I am writing an application that I would like to have unload most
>of its self (all but main() and the overlay handler) before 
>spawning to another application.

For this you don't need overlays, you need something that swaps your
whole application out while the other program runs.  Try using archie to
find spawno*.*, a library of routines by Ralph Brown (I think) that do
exactly that.  Some version can be found the comp.binaries.ibm.pc
archives.  Further discussion of spawning and swapping programs to disk
should be taken to comp.os.msdos.programmer, since they are not relevant
to comp.lang.c (so _edit_ your Newsgroups line!).

(Of course, a better solution is to switch operating systems, but if
you're stuck with DOS...)

--
Lars.Wirzenius@helsinki.fi
From: guido@gvr.win.tue.nl (Guido van Rooij)
Newsgroups: comp.lang.c
Subject: help wanted for typedef
Date: 22 Jul 92 18:24:23 GMT
Organization: Guido's home 486 box

Can anyone please tell me how to make a typedef for the following type:
a is of TYPE T if it is an array [] of array [constant_length] of pointers
to void functions.
I tried it in several ways, but it seems impossible to do it in just one
typedef. Also the following went wrong, though I don't know why:
typedef void *F();
typedef F[][constant_length] T;

Please reply by email...I'm not a regular reader of this group.

-Guido
Newsgroups: comp.lang.c,comp.lang.pascal
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Subject: Re: Flexible array indexing in C (like Pascal)
Organization: Technical University Vienna, Dept. for Realtime Systems, AUSTRIA
Date: Fri, 31 Jul 1992 15:44:04 GMT

veerasam@utdallas.edu (Jeyakesavan Veerasamy) writes:

>When translating Pascal programs to C, this tip may be helpful.

>It basically allocates the memory, returns the pointer
>after adjusting it for index range.

>/* Allocates array for which index value low to hi will be legal,
>   Only requirement is, low < hi */

>#define allocate(type,low,hi) \
>	((type *) malloc ( (hi-low+1) * sizeof(type) ) - low)

Note that this only is garantueed to work if low <= 0 <= high + 1. If
this condition is not satisfied, the returned pointer does not point
into the allocated memory region, and may cause an exception when used.

[This `tip' comes up every few months. I wish people would read the FAQ
(Q. 2.11 in this case) before posting their pet tricks]

	Peter
-- 
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |
From: 528010@llnl.gov (Mark Levinson)
Newsgroups: comp.lang.c
Subject: Help with converting Borlandc peekb to Microsoft C equivalent
Date: 29 Jul 92 22:51:42 GMT
Reply-To: 528010aisws7@llnl.gov
Organization: Lawrence Livermore National Lab


---
We are converting a  working Borland-C program to an equivalent Microsoft C++ program.  Is there a list of the corresponding function calls.   In particular from Borlandc 's pokeb()  and peekb()  to the Microsoft C++ equivalent

 ---------------------------------------------------------------------------
Mark Levinson                                                          Internet:    markl@llnl.gov
 Lawrence Livermore National Lab             PacBell Net: (510) 422-1794
Newsgroups: comp.lang.c
From: pegasus@csd4.csd.uwm.edu (David R Hucke)
Subject: Curious bug...
Originator: pegasus@csd4.csd.uwm.edu
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Wed, 22 Jul 1992 05:00:21 GMT

Hello everybody!

I have a program that I have written in Quick C 2.5 that doesn't work right and
I am stumped.

I use a program called "TheDraw" to create menus which are saved as binary
screen dumps to a disk file.   This program below reads the file in and
puts it into an array.  Then the array is put in the screen.

What happens is this:  When I run the program in the QC Environment it
works fine.  The characters are correct, and the colors are not correct.

When I run the program from DOS (outside of the QC Environment) the characters
are correct but the colors are not correct.

Can somebody tell me what is wrong here?


#include <stdio.h>

main()
{

   short far *SCREEN = (short far *) 0xB8000000;
   short menu[8][20];
   short x,y;
   FILE *file;
   int i,j,z;

   if(!(file = fopen("c:\\test.scn","r"))){
	printf("Unable to open file!\n");
	exit(99);
    }
    for(j=0;j<8;j++)
	for(i=0;i<20;i++){
   	    fscanf(file,"%c%c",&x,&y);    /* reading in attribute and
					     character bytes */
	    menu[j][i] = (short)((y<<8)+x);  /* putting together screen
						character ---> attribute
						and character.  Shifting
						one of the bytes. */
	}
    fclose(file);
	for(j=0;j<8;j++)
	    for(i=0;i<20;i++)
		*(SCREEN+((j+5)*80)+(30+i)) = (int)menu[j][i];
}


Thank you for the help.

===
pegasus@csd4.csd.uwm.edu

-- 
pegasus@csd4.csd.uwm.edu                David R. Hucke
                                        UW-Milwaukee Film Major
--
Newsgroups: comp.lang.c,comp.lang.c++
From: macg9505@uxa.cso.uiuc.edu (Michael Alan Corn)
Subject: A graphic window while in Text mode?
Organization: University of Illinois at Urbana
Date: Fri, 24 Jul 1992 16:57:09 GMT

IBM's newest wordprocessor can display a split screen with
1/2 as WYSIWYG and the other in text mode.  Can anyone explain
how to do this?  I'd like to bring up a graphic window in
a text mode display, but thought it couldn't be done. I use
BC++ 3.1 Thanks.  Post or email to macg9505@uxa.cso.uiuc.edu

Newsgroups: comp.lang.c
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Variable length records
Date: 29 Jul 92 16:06:18 GMT
Organization: University of Helsinki

In an earlier article I asked for what the advantages of using the
non-standard "struct { ...; float data[];}" or the tricky but more
standard "struct {...; float data[1];}" for structures where the data
array may be of varying lengths.  I offered the "struct {...; float *}"
version instead, as it is strictly conforming and will work everywhere.

The reasons for the trickery versions were convenience (no need for
managing a separately allocated array), less wasted space (no additional
pointer), and no need for a pointer dereference.  Your mileage may vary,
but I don't think these are very good reasons, at least under normal
circumstances.  If speed or size is critical, one's values may be
different.

One point which I didn't think of until now (and which doesn't seem to
have been pointed out by others) is that the '[]' and '[1]' versions
don't allow using the structures as values, like for assignment,
parameter passing and returning as function values.  This may or may not
be important, but it is something you have to check for, as it could
lead to difficult bugs, as such usage doesn't look wrong in itself.

--
Lars.Wirzenius@helsinki.fi
From: bkuhn@rhlab.UUCP (bmk Bradley Kuhn)
Newsgroups: comp.lang.c
Subject: Re: About the 'F' in RTFM
Summary: forgotten
Date: 21 Jul 92 12:00:14 GMT
Organization: Baltimore Rh Laboratory, Inc., Maryland

In article <1992Jul17.222246.29743@hplabsz.hpl.hp.com>, chew@hplb.hpl.hp.com (Chee Chew) writes:
> In article <1992Jul17.202448.19848@wyvern.twuug.com>,
> alpha@wyvern.twuug.com (Joe Wright) writes:
> |>Proposed change to 'standard' practice.  'RTFM' is now 'RTM'.
> |>'Read The Manual' should suffice.
>       
> what?  you got something  against the word "friendly" ?
> 
 No, The 'F' is a merely a reminder that the manual has been 
                           Forgotten.
                           ~
From: darcy@druid.uucp
Newsgroups: comp.lang.c
Date: 18 Jul 92 03:26 MDT
Subject: Simple preprocessor
Nf-ID: #N:1992Jul17.232621.20226@druid.uuc:-1295377463:001:2384
Nf-From: druid.uucp!darcy    Jul 18 03:26:00 1992


scs@adam.mit.edu (Steve Summit) writes:
>Once of these days, someone should write a good, simple
>preprocessor, perhaps simply a stripped-down cpp, that handled
>#include, #ifdef, and simple #define (and *maybe* macros with
>arguments), which *would* be appropriate for general-purpose,
>non-C preprocessing tasks such as Makefiles, calendar files,
>crontab files, etc.  (Hmm; gotta write myself another note.)

TA DA!!!

Introducing mkfiles(3) (Actually that's too much like a BSD utility I
believe but that's the name I started with.  I'll probably change it.)

It's not quite ready for distribution yet but here is a glimpse.

First of all the '#' is a comment character like just about every
Unix utility except cc.  Blank lines are ignored.  There are hooks
if you need '#'  or blank lines in the output.

Preprocessor directives start with '@'.  These include;

  @DEFINE          Define a macro
  @DEFAULT         Like @DEFINE but only if not already defined
  @UNDEFINE        Undef same
  @INCLUDE         Include a file
  @PACKAGE         Include a file from a predefined directory
  @FILE            Redirect output to a new file
  @PRINT           Print to standard output regardless of current output
  @SHOW            Show defined macros (for debugging)
  @CLEAR           Clear all macros to a specific point
  @IFDEF           Conditional
  @IFNDEF	           "
  @ELIFDEF             "
  @ELIFNDEF            "
  @ELSE                "
  @ENDIF           End conditional
  @QUOTE           Quote all lines (a specialty thing I needed)
  @FOR             For loop construct
  @END             End for loop
  @ERROR           Print message and exit

Macros can take arguments and defaults can be specified for the arguments.
Here is a sample macro:
    @DEFINE foo bar $(1:zap)
And it's expansion:
    $(foo:goo)    ==>     bar goo
    $(foo)        ==>     bar zap

The sample script creates a skeleton SVR4 device driver including the
system files, Makefile, Bare C file, etc.

The distribution includes my getarg(3) and getline(3), valuable utilities
in their own right if I say so myself.

I have a little more testing to do on it and then I will probably post it.

-- 
D'Arcy J.M. Cain (darcy@druid)     |
D'Arcy Cain Consulting             |   There's no government
Toronto, Ontario, Canada           |   like no government!
+1 416 424 2871          DoD#0082  |