HDTenEightyP/NetNews huggingface dataset:
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: 1-800-SPELL-IT
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 16 Apr 92 15:54:18 GMT

In article <664@wookie.dbaccess.com> steve@dbaccess.com (Steve Suttles) writes:
>in article <andreww.702802050@suite.sw.oz.au>, andreww@suite.sw.oz.au (Andrew White) says:
>> 
>>>In article <1992Apr6.214828.15228@dsg.tandem.com> narayan@aravali.everest.tandem.com (Pankaj Narayan) writes:
>> 
>>>	   Does anyone have any programs that will take a string of digits
>>>	   and convert them to something meaningful by matching them
>>>	   against the telephone digit-to-alphabet table.

Michael Berry (THinking Machines COrp) offered a simple APL function
to do this in "Adverbial Programming" in the August 1990 issue of
SIGPLAN Notices. It will work on phone numbers of any length.
Bob




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
Newsgroups: comp.lang.c
From: scs@adam.mit.edu (Steve Summit)
Subject: Re: End struct with unsized array?
Keywords: struct array unsized
Reply-To: scs@adam.mit.edu
Organization: none, at the moment
Distribution: na
Date: Mon, 13 Apr 1992 06:50:56 GMT

In article <1992Apr10.200130.24858@bronze.ucs.indiana.edu> burleigh@bronze.ucs.indiana.edu (Frank Burleigh) writes:
> typedef struct x
> {
>    int        i;
>    int        j;
>    SOMETYPE   k[]; /* perhaps not a good idea */
> } X;
>
> Actually the trouble comes with initialization, as the compiler
> complains that it doesn't know the size of an X.k.

There is actually a two-part problem here.  The first is that the
k array has no dimension at all, which can reasonably be expected
to give a compiler fits.  (There are places where you may legally
omit an array dimension, but this isn't one of them.)  The second
problem is that, if the compiler happens to interpret "missing
dimension" as "dimension of 0," (as many compilers do), we end up
with a 0-sized array, which the ANSI C Standard disallows.  (Some
earlier compilers allowed 0-sized arrays, and attempts have been
made to make 0-sized objects a formal part of the language, but
such objects are problematical and not now legal.)

The solution is to give the last array member a nonzero size, and
to compensate for it when doing the allocation.  I like to hide
the particular nonzero size value I use behind a macro, which
makes it a bit clearer what's going on:

	#define INIALLOC 1	/* initial # of k's allocated */

	struct x
		{
		int i;
		int j;
		SOMETYPE k[INIALLOC];
		};

	struct x *
	makex(num_of_k)
	int num_of_k;
	{
	return (struct x *)malloc(sizeof(struct x) +
				(num_of_k - INIALLOC) * sizeof(SOMETYPE));
	}

Now, the other question that comes up here is "is this trick
really portable?"  As the FAQ list says,

	This technique is popular, although Dennis Ritchie has called it
	"unwarranted chumminess with the compiler."  The ANSI C standard
	allows it only implicitly.  It seems to be portable to all known
	implementations.  (Compilers which check array bounds carefully
	might issue warnings.)

						Steve Summit
						scs@adam.mit.edu
From: volpe@bart.crd.ge.com (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: passing structure to a function
Date: 10 Apr 92 21:28:20 GMT
Reply-To: volpe@bart.crd.ge.com (Christopher R Volpe)
Organization: GE Corporate R&D Center

In article <mcook.702843388@mrc.dev.cdx.mot.com>,
mcook@mrc.dev.cdx.mot.com (Michael Cook) writes:
|>volpe@bart.crd.ge.com (Christopher R Volpe) writes:
|>
|>>C, whether it be ANSI or pre-ANSI, has always required that all parameters,
|>>structures or otherwise, be passed by value.
|>
|>Except arrays.  They're passed by reference.

Wrong. Arrays aren't passed at all. Pointers are passed. And they're passed
by value.

|>-- 
|> ==========================================================
|> Michael.Cook@merlin.dev.cdx.mot.com          (617)821-7590
|> Motorola/Codex, 20 Cabot Blvd, C2-135, Mansfield, MA 02048
|> ==========================================================
           
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.lang.c
From: gay@selkirk.sfu.ca (Ian D. Gay)
Subject: Re: Timing problems on 486-33--delay() function in Turbo C
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Thu, 9 Apr 1992 16:40:15 GMT

dons@hpmwtd.HP.COM (Donald St.Denis) writes:

>>/ hpmwtpd8:comp.lang.c / rcrane@yoda.eecs.wsu.edu (Robert Crane - OTHER) /  1:15 am  Apr  8, 1992 /
>>
>>The delay() function in turbo c is not accurate on my 486-33.
>>It works much slower than it should.
>>When I removed the external and internal cache it seemed to work
>>correctly.  Has anyone else experienced this problem???

>    No problem with delay() on my HP486/33T.  I have not touched the
>    caches.

>>-bob crane
>--
>Donald St. Denis                  Hewlett-Packard


The delay() function calibrates itself by finding how many times a 
software loop can run in one tick of the 55ms clock. If the program 
structure was such that everything was cached for the calibration, but 
not when the function was really used, this might cause the problem.
Xref: sparky comp.lang.c:7644 comp.std.c:1822 comp.arch:5040
From: shap@xanadu.com (Jonathan Shapiro)
Newsgroups: comp.lang.c,comp.std.c,comp.arch
Subject: Re: "long long" for 64 bits
Date: 15 Apr 92 06:56:58 GMT
Article-I.D.: xanadu.1992Apr15.065658.16086
Organization: Xanadu Operating Company

In article <1992Apr12.050347.7785@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes:
>shap@xanadu.com (Jonathan Shapiro) writes:
>
>>In article <ktf7loINNq8a@spim.mips.com> mash@mips.com (John Mashey) writes:
>>I don't know where HaL ended up.  I don't know what I think the right
>>answer here is.  I do know that all of the answers are prohibitively
>>expensive.  You only get to choose which prohibitively expensive answer you
>>intend to implement.
>
>>Jonathan Shapiro
>>Independent Consultant
>
>The most obvious solution would be to simply make it a compiler
>switch. That is, unless the strict ANSI switch is on, "long long" would
>get you a 64bit int. The only other decision left to make then is the
>sizeof(long), sizeof(int) and sizeof(short). If no switchs (default), then
>long == 64bit, int==32bit, short==16bit
>1 switch makes int==long==64, and another makes short==32.
>
>This makes the compiler uglier but does not force any one
>design decision onto *everything*.

Unfortunately that's just not true.

Changing the size of the integral types has implications for:

	o Calling convention
	o OS interface (instance of calling convention, but probably
	  interacts with assembler)
	o I/O, esp. printf() and friends
	o alignment rules
	o structure sizes of nominally compatible structures.

It's clear that a single program has to be one mode only.  It's only
slightly less clear that the cost of engineering all possible options
for libraries and operating system interfaces makes this strategy
totally out of the question.

Jonathan Shapiro
Independent Consultant
Newsgroups: comp.lang.c,comp.programming
From: aet@mullian.ee.mu.OZ.AU (bert thompson)
Subject: a parallel mergesort in C
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 14 Apr 1992 09:49:51 GMT


hi!
	
	i am interested in writing a parallel mergesort in C
	as a way of working out a method for writing parallel
	programs in general.

	can anyone provide me with:

		hints
		short simple code
		an idea of which library procedures might be useful
		an idea of what primitives i should create

thanks people!

bert.
Newsgroups: comp.lang.c
From: ted@mdbs.uucp (Ted "Dracula" Carroll)
Subject: Re: Question about MS C libraries
Reply-To: ted@mdbs.UUCP (Ted Carroll)
Organization: Micro Data Base Systems, Lafayette, Indiana
Date: Fri, 3 Apr 92 14:47:09 GMT

In article <harish.236@csar.uucp> harish@csar.uucp (Harish Pillay) writes:
>I've a question regarding MS C libraries.  When I compile a module (say
>an assembly language code) and incorporate it into a library, the module
>name does not have an underscore appended to it.
>
>However, if a MS C module is added to a library, there is an underscore
>appended to it.  We need to use some of these libraries with RealiaCobol
>and that cobol has difficulty with modules with underscores in them.
>
>I've not found a way to suppress the underscore with the MS C Compiler (
>ver6.0).  Am I overlooking something or is it just not possible?
>
>I'm told that Lattice C does it, but since our developers are standardized
>on MS C, we do not have too much of an option.
>
>Any suggestions?  E-mail harish%csar@uunet.uu.net and I'll post a summary.
>
>Thanks.
>--
>Harish Pillay             harish%csar@uunet.uu.net
>Singapore               "Psst!  Wanna buy some gum?"

	Try using the pascal calling convention.  There are no underscores.
	Names are converted to upper case.  The called function cleans up the
	stack, and parameters are pushed left to right instead of right to
	left.  You can make realia worry about most of this crud (If I remember
	right - it's been a while).

				Ted Carroll
				ee.ecn.purdue.edu!mdbs!ted
Newsgroups: comp.lang.c
From: man@magwien.gv.at (Andreas Manessinger)
Subject: Re: C beautifier
Organization: Gemeinde Wien, MD-ADV/Md Ref. EPS
Date: Thu, 9 Apr 1992 13:44:09 GMT

In article <1992Apr7.001701.28785@seas.gwu.edu> khatri@seas.gwu.edu (Anil Khatri) writes:

   Hi! netters, here is one simple question for you all. Are any of you guys using
   C Beautifier for your C programs. Do you find any other advantage
   of it apart from  easy readibility and debugging of code. 

I always use the `c-mode' of `Emacs' for editing, so my sources are always
pretty :-) Whenever I need to work on other people's sources I feed
them into `GNU indent'. With commandline options you can request a lot
of different indentation styles. There should also be a style for you.
You get `Emacs' and `indent' via anonymous FTP from `prep.ai.mit.edu'
and other major sites. Ports for Maso/Sado-DOS, Atari ST and other
exist.
--
    /\              | eMail: "man@magwien.gv.at"
   /  \ndreas       | pMail: Kaiserstra\3e. 30/26; A-1070 Wien; Austria
  /\/\ \            | Work : Gemeinde Wien MD-ADV/Ma; Ref. EPS
 / /  \anessinger   | Phone: +43 (1) 9350434 or 4039584/13, FAX: 4039584/18
Newsgroups: comp.lang.c
From: pjh@mccc.edu (P. J. Holsberg)
Subject: Looking for Advanced Textbook
Organization: The College on the Other Side of U. S. 1
Date: Thu, 9 Apr 1992 16:06:38 GMT

Can anyone recommend a C book that covers most or all of the following topics?

Structures, linked-lists, advanced pointers, DOS specific programming, 
memory management, debugging, some advanced topics such as sorting/searching
techniques and algorithms, a more detailed examination of recursion, etc.

Thanks,
Pete
-- 
Prof. Peter J. Holsberg      Mercer County Community College
Voice: 609-586-4800          Engineering Technology, Computers and Math
FAX: 609-586-6944            1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu       Trenton Computer Festival: April 11-12, 1992
Newsgroups: comp.lang.c,comp.lang.fortran
From: bm@nvuxr.uucp (B. Manseur, (908) 758-2505)
Subject: FORTRAN to C translator
Organization: Bellcore, Livingston, NJ
Date: Fri, 10 Apr 92 01:52:09 GMT
Followup-To: poster, comp.lang.c, comp.lang.fortran


Hello everyone:

Does anybody know if there is a program (FORTRAN or C)
that can translate FORTRAN code into C code.  
Any information would be appreciated.
Thanks.

B. Manseur (bm@nvuxr.cc.bellcore.com)
From: earec@cbnewsg.cb.att.com (rodney.e.conrad)
Newsgroups: comp.lang.c
Subject: Process Table
Date: 17 Apr 92 15:58:37 GMT
Article-I.D.: cbfsb.1992Apr17.155837.29318
Distribution: usa
Organization: AT&T

I need to be able to read the process table for a program I am writing.
If anyone can point me in the right direction, I would appreciate it.

( I am aware of /usr/include/sys/proc.h, but how do I attach to that
  area of memory ).

(Please send responses directly to me because I don't read the net that often)

Rodney Conrad
rec@addams.att.com
Newsgroups: comp.lang.c
Subject: Numeric to ASCII / REREAD
From: rdbrown@ualr.edu (Robert D. Brown)
Date: 8 Apr 92 18:24:04 GMT
Organization: University of Arkansas at Little Rock

After one day I've received a bazillion messages to use sprintf()
to make the conversion I requested (the opposites of atoi, atol, and
atof).

Now, one of two things are happening. Either I don't understand the
answer, or those who took the time to reply didn't understand the
question.

Case 1 (I don't understand the answer):
     How can I use sprintf() to take a floating point variable and
convert it to a char * variable?

Case 2 (Y'all didn't understand the question):
     atoi(), atol(), and atof() are functions that convert an ascii
representation of a number into either an integer, long, or float type.
What routines can I use that will convert an integer, long, or float
type variable into one of type char *?

This is _not_ a FAQ question, for those of you who evoked it.

For those of you who didn't evoke the FAQ thanks for the help
but it's not quite what I was looking for.

--Robert

Newsgroups: comp.lang.c
From: bboerner@novell.com (Brendan B. Boerner)
Subject: Re: QUESTION on suppressing warning message: unused parameter
Keywords: compiler warnings suppressing
Organization: Novell, Inc. --Austin
Date: Fri, 17 Apr 1992 14:05:12 GMT

In article <74057@netnews.upenn.edu> jim@heart.circ.upenn.edu (Jim Streicher) writes:
>I have a quick question about suppressing warning messages.
>
>I get a warning message in the following function:
[...]
>As I see it, I have three options:
> 1) ignore the warning message
> 2) take out the extra parameters in the functions that don't use it
> 3) do the c = c thing. So far I haven't seen any problems but it
>    sure looks silly.
[...]

Use #pragma argsused before the function definition.  It prevents
the message you're seeing.  Note that this is implementation
specific (i.e. Watcom C does it using a different #pragma, MSC may
not even have a way to turn it off (that is if the compiler warns
you about this case), etc...).

Hope this helps,
Brendan
-- 
Brendan B. Boerner		Phone: 512/346-8380
Internet: bboerner@sjfsmtp.novell.com	MHS: bboerner@novell
From: eric@pencom.com
Newsgroups: comp.lang.c
Subject: Re: passing structure to a function
Date: 7 Apr 92 20:42:30 GMT
Organization: Pencom Software

In article <52701@mimsy.umd.edu> dong@umiacs.umd.edu (Dong Chen) writes:
> Hello,
> 
> I have a lot of fuctions doing processing for some type of
> structures. Now as concern of efficiency, is it better to
> pass the structures as a pointer or just pass the structure
> itself ?
> 
> something like f(struct S a) vs. f(struct S *a).

Generally, it is better to pass pointers to structures, except
(maybe) if the structure is small (<= 1 word).

Some architectures will create a copy of the structure and pass
a pointer to the copy if you tried to pass a whole structure
in the first place.
Newsgroups: comp.lang.c
From: holen@xilinx.com (Victor A. Holen )
Subject: impossible in C ? -macro
Keywords: macro declaration return
Organization: Xilinx Inc.
Date: Mon, 6 Apr 1992 21:04:10 GMT

Is it possible to have a macro that declares local variables
and returns a value. Basically, so it can be called/used as
a function.
Something like
# define macfunc(v) \
     int a  \
     /*use a to compute some function of v (e.g.  a=v; ) */ \
     /* return a */
I tried some combinations of (,,){} but not the right ones...
Supposedly one can do anyting in C, but of course I'd be interested only
if its legal ANSI C, which may be harder to determine than to find solution...


-- 
 victor ....  ___  ._..  .  _.     holen@xilinx.com
Newsgroups: comp.lang.c
From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
Subject: Re: 64 bit integers
Organization: Jet Propulsion Laboratory, Pasadena, CA
Date: Wed, 15 Apr 92 22:32:45 GMT

In article <1992Apr15.174938.2663@cnmss.tredydev.unisys.com> kgs@cnmss.tredydev.unisys.com (Ken Salter) writes:
>
>Has anyone used, or even heard of, a library that supports double
>precision (8 byte) integers, preferably in a Unix System V Release 4.0,
>ANSI C environment?
>

Sure, GNU's gcc has 64-bit integers!  If the hardware doesn't support
native 64-bit integers, gcc supports 64-bit integers through library 
routines in gnulib2.  And, it's not very hard to yank the 64-bit stuff 
from gnulib2.c and make your own 64-bit arithmetic library.

You also might find you have multiple precision integer arithmetic on your 
system; try 'man mp'.

-- 

Kaleb Keithley                               kaleb@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.
From: rcrane@yoda.eecs.wsu.edu (Robert Crane - OTHER)
Newsgroups: comp.sys.imb.hardware,comp.lang.c
Subject: Timing problems on 486-33--delay() function in Turbo C
Date: 8 Apr 92 08:15:06 GMT
Article-I.D.: serval.1992Apr8.081506.22752
Organization: Washington State University
Originator: rcrane@yoda.eecs.wsu.edu


The delay() function in turbo c is not accurate on my 486-33.
It works much slower than it should.
When I removed the external and internal cache it seemed to work
correctly.  Has anyone else experienced this problem???
----------
-bob crane (rcrane@yoda.eecs.wsu.edu)
-- 
-bob crane
rcrane@yoda.eecs.wsu.edu
"Ah Limbo!"
From: mlawrence@leotech.mv.com (Mike Lawrence)
Sender: uucp@leotech.mv.com
Newsgroups: comp.lang.c
Subject: Graphics.h
Date: Wed, 08 Apr 1992 16:09:24

I'm sure this problem has been encountered by other Turbo C
programmers.
I have tried to resolve it myself, and am still sure there must be a
simple solution.  The Borland graphics library includes several *.BGI
graphics drivers, each of which has several supported graphics modes.
The list of twenty-nine graphics modes is shown in graphics.h, where
constants for each mode are defined.  There is no mode support or
defined constant for BIOS mode 13h, the VGA 320x200 256-color mode.
This same table is explained in the Waite Group's "Turbo C Bible,"
and
it is reproduced verbatim from the header file.  The 320x200x256 mode
remains forgotten.  Yet on page 685:

"Depending on the graphics mode and display adapter, the width and
height...can be one of: 320x200 (CGA 4-color mode and VGA 256-color
mode), 640x200 (CGA 2-color mode), [etc., etc.]"

This mode is mentioned also two pages earlier:

"The VGA can also provide 320x200 resolution graphics with 256 colors
(mode 13h)."

Nowhere is there any intimation of how to use this mode with the
Borland
graphics library.  I had used this mode extensively, through the
FastGraph library, before switching to the more-standard Borland one,
so it is NOT an incompatibility with my hardware.  I have tried using
just numbers to reference the drivers and modes in the statement:

initgraph (&graphdriver, &graphmode, "c:\turboc");

I have tried substituting numbers outside the range the constants
cover,
with similar failure.  Do I need a custom *.BGI driver in order to
utilize mode 13h?  There are no Borland drivers on the VGA driver
disk
that came with my VGA card.  I would certainly appreciate any
assistance.


 * Origin: Leo Technology (603)432-2517/432-0922 (HST/V32)
(1:132/189)
Newsgroups: comp.lang.c
From: bradb@comm.mot.com (Brad Bakke)
Subject: Re: Random Numbers
Reply-To: bradb@comm.mot.com
Organization: Motorola
Date: Wed, 15 Apr 1992 18:25:01 GMT

In article 13510@spruce.pfc.forestry.ca, shyatt@PFC.Forestry.CA (ARIAKAS) writes:
--->  Hi, I am writing a program in Turbo C++ which needs to generate random numbers
--->  but the random functions for IBM computers arn't true random. Is there a good
--->  algorithm or package that will simutale true random numbers?
---> 
--->  Steve Hyatt
--->
--->  STEVE HYATT                       Title: Coop Student - Computer Science
--->  Forestry Canada                   Phone: (604) 363-0600
--->  Victoria, B.C.                    Internet: SHYATT@A1.PFC.Forestry.CA

There are some good random number generators, Gaussian generators and random bit
generators, which can be modified to fit almost any need, in the book "Numerical
Recipes in C, The Art of Scientific Computing", by William H. Press, Brian P.
Flannery, Saul A. Teukolsky and William T. Vettering. 


---
/-----------------------------------------------------------------------\
| Bradley Q Bakke               The answer lies in our overwhelming     |
| <bradb@comm.mot.com>            faith in technology, a faith so       |
|                                 ingrained that neither rational       |
|                                  argument nor physical law can        |
|                              dissuade it from its ultimate triumph.   |
\-----------------------------------------------------------------------/

Newsgroups: comp.lang.c
From: dwh@vaxeline.ftp.com (David W. Hamaker)
Subject: Re: string representation
Organization: FTP Software, Inc., Wakefield, MA
Date: Wed, 15 Apr 1992 01:24:30 GMT

In article <1992Apr14.202451.13085@ima.isc.com> karl@ima.isc.com (Karl Heuer) writes:
>In article <1992Apr13.225124.22651@vaxeline.ftp.com> dwh@vaxeline.ftp.com (David W. Hamaker) writes:
>>By the way, MY favorite string format idea is a count byte, followed by
>>some string bytes...

>But this means that a substring of a string is not a string, so the cdr()
>operation (O(1) with standard strings) can't be done without either copying or
>destroying the original string; and you can't extend a string without having a
>pointer to its beginning (the existence of strcat() notwithstanding, I almost
>always extend a C-string by using strcpy() onto its end-pointer).

A substring of a C-string isn't a string either, only _trailing_ substrings
are.  A trailing substring can be expressed for "my" strings as a pointer to
the first char of the substring plus a pointer to the closest prior count
byte (note that this representation is easy to obtain for a "real" my-string
from the address of its first char).  A cdr() operation on this representation
which delivers the same representation is O(1) without copying or destroying
the original string.

And where, pray tell, did that end-pointer come from?  (I think its exactly
the kind of meta-representation I'm talking about above.)  The corresponding
thing for a my-string is a pointer to its last count byte.

>If I wanted a general-purpose string object, including the ability to
>non-destructively name arbitrary substrings (not just trailing substrings),
>I would probably use
>	class Buffer { int refcount; size_t alloclen; char *body; };
>	class String { Buffer *buf; size_t pos, len; };
>or something functionally equivalent to it.  (All of the size_t members could
>just as easily be pointers into body.)  I would prefer to do it in C++ (hence
>the "class" keyword), with appropriate protection on the members, but it's
>easy enough to emulate it with careful C.

If non-destructive means changing the parent affects its substrings, I'll
pass.  What I like about my-strings is that they're time/space-optimized
toward small (common) stuff, yet are somewhat general.

(Tastes great!  Less filling! :-)

-Dave Hamaker
 dwh@ftp.com
From: chiu
Newsgroups: comp.lang.c
Subject: Please Help on: float # to string conversion
Summary: Please help on: float # to string conversion
Keywords: string float conversion
Date: 17 Apr 92 02:04:31 GMT
Distribution: comp.lang.c
Organization: University of Toronto, Department of Mechanical Engineering




I am not familar the internal type conversion of C.
I know in C that there is a "atof" function, but it
only convert a string to floating point.

Could somebody kindly send me some C SOURCE code for converting
float # to a array of char?

Any help will be greatly appreciated.


Thanks in advance.

Henry Chiu
Dept. of Electrical Engineering
Graduate Office, University of Toronto
10 King's College Road, Toronto, Ontario M5S1A4, Canada
INTERNET: chiu@me.toronto.edu
TEL: (416)-975-5473