HDTenEightyP/NetNews huggingface dataset:
From: "hans friedrich steffani" <GM08@DKAUNI2.BITNET>
Subject: problem with sin on MSC7.0 solved
Organization: University of Karlsruhe, Germany
Date: Thu, 15 Oct 1992 13:42:12 GMT

> > Im Artikel <1992Oct14.084222.14873@rz.uni-karlsruhe.de> schreibt hans friedr
ic
> h
> > steffani (GM08@DKAUNI2.BITNET):
> and c_entk.h contains
> #define L_4_SIN_TAB 400
> #define L_SIN_TAB (L_4_SIN_TAB)
^^^^^thats stupid, not right cited
and that was the problem: i wrote
#define L_SIN_TAB  4 * L_4_SIN_TAB
then I hade the code:
> > >       argument = (FLT)2.0 * (FLT)PI / (FLT)L_SIN_TAB
> > >                * (FLT)i;
and L_4_SIN_TAB becomes a Factor of the numerator, but not of
the denominator.
so it had to be:
#define L_SIN_TAB  ( 4 * L_4_SIN_TAB )
but I didnt tell you this though you couldnt realy help me.

hans friedrich steffani
gm08@dkauni2.bitnet
steffani@imbaibrs1.bau-verm.uni-karlsruhe.de
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Realloc failure when downsizing (was Re: Probably a simple realloc() question)
Date: 12 Oct 92 21:21:11 GMT
Organization: negligable


Just to clarify a little.  There seem to be two questions being
addressed here:

	1) good vs. poor library implementation
		(i.e. where realloc() should fail during a downsizing)

	2) good vs. poor programming practices
		(i.e. whether you should always check for NULL from realloc())

I have been discussiong item #1 above.  Most of my replies seem
to have been addressing item #2.  To me, there is a difference.

I do not advocate ignoring the return value from any memory allocation
routine (although I will admit that I have fallen into some poor practices 
since I've been working on a UNIX system (virtual memory y'know)).  If I
gave that impression I apologize for getting carried away.

I still maintain that in any well designed library implementation there
is no reason (barring reason #5 in the previous article) for a downsizing
realloc() to fail.  Aside from the invalid pointer mentioned above, the 
only other excuse suggested has been that the memory block scheme does
not allow altering the size of a block & putting the newly "unused" portion
back on the free list.  That, again, would point to a poor design and/or
implementation of the library memory management system.

With this in mind (which briefly lost sight of my self) I shall readdress 
the points above (briefly):


#1	not applicable, addresses the practices issue, not the implementation
	one.  yes realloc can fail, there is no way you can stop it on upsizing.
	yes you have to check.  the savings is NOT in code size, but in whether
	your program runs or not when you're near the edge.

#2	just how useful these things are is questionable.  if I can get the
	memory to satisfy my current needs, whether we are "tight" or not
	is immaterial.  when we have a "real" failure is soon enough to
	find that out.

#3	programming practices again.  I agree.

#4	doesn't address issue 1 again.  whether the design/implementation
	of the library that fails in downsizing is poor or not.  I still
	say it is.

#5	as I said in my other followup, this is the only valid reason I
	have seen for a downsizing realloc() to fail.

Now, since I seem to have irked some people w/ my opinons on library
design, I'll just leave it at this.

I would like to say again, though, that I think some of this "heatedness"
came from addressing (slightly) different issues.



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Work away today, think about tomorrow.		|
Never comes the day, for my love and me.	|	-Richard Hartman	
I feel her gently sighing			|	hartman@uLogic.COM
as the evening slips away....			|

Newsgroups: comp.lang.c,comp.unix.questions
From: dlgover@dlgsys.cuc.ab.ca (Donald L. Gover)
Subject: C source Shrouders?? (Where/How)
Organization: DLG Systems
Date: Thu, 15 Oct 1992 17:45:58 GMT

  I was woundering if anyone has had experince with these packages that 
render C source unreadable and still compile?? I would like any information
about usage or information as to where I could get such a beast.

  Don...


-- 
=============================================================================
Donald L. Gover                              New Era Systems Services
UUCP:      uunet!dlgsys!DLGover              PHONE: (403) 237-6141
INTERNET:  DLGover@dlgsys.cuc.ab.ca
From: cjw@dme.nt.gov.au
Newsgroups: comp.lang.c
Subject: How does free() work ?
Date: 12 Oct 92 09:20:06 GMT
Reply-To: cjw@dme.nt.gov.au

I am just curious about the function of free(). If
I have a linked list and I free the head of it ie.

free(first_name) ;

where name contains further linked lists called
say, male_friends & female_friends, does free() then 
de-allocate their memory as well ? Or is it necessary
to do something like the following :

free(first_name->first_male_friends) ;
free(first_name->first_female_friends) ;
free(first_name) ;

This is not especially crucial on my machine, but will be 
for the end users I suspect. 

Thanks,
	-Chris.

-----------------------------------------------------------------
Chris Wharton    cjw@celeste.dme.nt.gov.au      Darwin, Australia
Newsgroups: comp.lang.c
id <m0meeeR-0000WyC@crash.cts.com>; Mon, 12 Oct 92 22: 18 PDT
	id <jc80266@pro-amber.cts.com>; Mon, 12 Oct 92 22: 17 PDT
From: rsopicki@pro-amber.cts.com (Randy Sopicki)
Subject: test
Organization: ProLine [pro-amber] -- Spring Valley, Ca
Date: Mon, 12 Oct 92 21:54:14 PDT

endaround
From: mike@pacsoft.com (Mike Stefanik)
Newsgroups: comp.lang.c
Subject: Re: Strings and integer sizes
Date: 10 Oct 92 16:25:20 GMT
Organization: Pacific Software Group, Riverside, CA

In an article scs@adam.mit.edu (Steve Summit) writes:
>
>	zoe[3] = "123";
>
>is perfectly legal, although whether it's a good idea or not is
>an entirely different question.
>
>But along comes Mike Stefanik (mike@pacsoft.com), saying exactly
>the same thing in article <1417@pacsoft.com>:

Guilty, on all counts. Indeed, it is perfectly legal and I simply posted
without a) reading the Book of Truth, and b) looking at what my C compiler
was actually doing. I'll try to keep my stupid to myself next time ... :-)

-- 
Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike  (714) 681-2623
Pacific Software Group, Riverside, CA
From: yost@adobe.com (David Yost)
Newsgroups: comp.lang.c
Subject: Wanted: portable threads package
Date: 12 Oct 92 17:09:18 GMT
Organization: Adobe Systems Incorporated

I'm looking for a threads package that is either free
or can be bought for a one-time charge.  It must not
be entangled in a large system (e.g. DCE threads, or
PARC's Portable C Runtime threads).  Ideally it has
already been ported to several CPU architectures, a
few unixes, Mac and Windows, but this is not required.

Can anyone help?  Please respond to the net, not by
email if possible.

 --dave yost

P.S. I've been off this group for a while.  Is this a FAQ?
From: mxmora@unix.sri.com (Matthew Xavier Mora)
Newsgroups: comp.lang.c
Subject: Re: Productivity of a C programmer ?
Date: 12 Oct 92 17:02:56 GMT
Followup-To: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
Organization: SRI International

In article <BvvIK4.EuJ@news.cso.uiuc.edu>, rolf@geoserv (Rolf Wilson)
wrote:
>   And then double it. Most programmers are pretty good at estimating
> their programming time, but don't seem to realize that they may only
> get half of their day to program in.

They also forget to include the time for testing and debugging. :-)





--
----------------------------------------------------------------------
Matthew Xavier Mora                                mxmora@unix.sri.com
SRI International                                       (415) 859-5011
----------------------------------------------------------------------
Newsgroups: comp.lang.c
From: pjh@mccc.edu (Pete Holsberg)
Subject: Re: Strings and integer sizes
Organization: The College On The Other Side Of Route One
Date: Fri, 9 Oct 1992 14:59:39 GMT

In article <718167097snx@grendel.demon.co.uk> jes@grendel.demon.co.uk (Jim Segrave) writes:
=
=In article <9227705.8771@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
=
=> 
=> >Multiple choice question:
=> >
=> >A string is stored
=> >	a. in an array of characters
=> >	b. in an array of characters terminated with 0
=> >	c. in an array of characters terminated with '\0'
=> 
=> Well, the answer is:
=> 	d. all of the above
=
=What about:
=
=char zoe[3] = "123";
=
=neither b. nor c. applies here.

THANK YOU! At last, someone understands my question. :-) :-)
Newsgroups: comp.lang.c
From: yho@otto.carleton.ca (Y. Ho(S.Kennedy))
Subject: Fortran_+C+Cplusplus, How to link?
Organization: Carleton University
Date: Wed, 7 Oct 1992 23:47:38 GMT

I have a program written mainly in "C" with some Fortran subroutines.
In sun, they are linking together by "f77 ...". Now I want to add
some C++ functions to this program, if there are no Fortran routines
involved, CC is right command to use, but with Fortran routines, I
do'nt know how to do?

Any ideas?

Yushang

Newsgroups: comp.lang.c
From: tim@shovel.Prime.COM (Tim Cantin)
Subject: Re: gif && X-window
Keywords: gif,X11
Organization: Prime Computer R&D
Date: Mon, 12 Oct 1992 13:16:31 GMT

The 'xv' program will do it... if you have it, do this:

	% xv your.gif

your gif will pop up on the screen, then put the cursor in the window and:

	hold Shift and press your right mouse button
	click on Save
	click X11 bitmap
	click Ok

Ta-da

-- 
#include "stddisclaimer.h"
/* Tim Cantin          {uunet, csnet-relay}!primerd!tim || tim@s35.prime.com
   Prime Computer Inc. 10-21, 500 Old Conn. Path, Framingham, MA 01701 (USA) */
flames > /dev/null 2>&1
From: kdq@quest.UUCP (Kevin D. Quitt)
Newsgroups: comp.lang.c
Subject: Re: How does free() work ?
Date: Tue, 13 Oct 92 16:48:52 PDT
Reply-To: srhqla!quest!kdq
Organization: Job quest  (805) 251-8210,  So Cal: (800) 400-8210

pal@regent.e-technik.tu-muenchen.dbp.de (Peter Loibl) writes:
> wkaufman@us.oracle.com (William Kaufman) writes:
> [stuff deleted]
>
> A freed pointer is not necessarily set to NULL! So the best way is to
> set the pointer after free() to NULL and ask, if the pointer is NULL
> before freeing it. You will get some major damages, if you try to
> free a NULL-pointer.

    Actually, trying to free NULL usually doesn't hurt.  Most of the
libraries I looked into check for NULL before they try to free the
memory: no harm, no foul.  I'm not sure I'd count on it if portability
were one of my goals, since I'm pretty sure this isn't actually
mandated behaviour,


 _
Kevin D. Quitt                                 Job Quest (805) 251-8210
srhqla!quest!kdq                               Learn How to Get a Job in SoCal

                96.37% of all statistics are made up.
Newsgroups: comp.lang.c
From: kyp@stsci.edu (Mark Kyprianou)
Subject: Wanted: C source for conversion of integer seconds since 1980
Organization: Space Telescope Science Institute
Date: Thu, 15 Oct 1992 20:25:13 GMT

I'm looking for some C source to convert integer seconds since 1980 to/from 
year, month, day, hour, minute and seconds.  

I've looked at the C run time routines and they do not provide what I need.

Please e-mail any information.

	thanks

-- 
     Mark        Space Telescope Science Institute, Baltimore, MD 21218
     Kyprianou   Internet: kyp@stsci.edu       UUCP: ...!noao!stsci!kyp
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Newsgroups: comp.lang.c
Subject: Re: Is there is (pascal) WITH equivalent in C?
Date: 12 Oct 92 17:05:45 GMT
Article-I.D.: mksol.1992Oct12.170545.21474
Organization: Texas Instruments Inc

In <1992Oct12.110939.16407@rz.uni-karlsruhe.de> ae24@iamk4516.mathematik.uni-karlsruhe.de (Peter Januschke) writes:

>mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>> And just how many totally non-optimizing Pascal compiilers do you know
>> of in the real world that are being used for anything where 'better
>> and faster code' would matter?

>Nowadays any compiler should do some optimisations, but as a "normal"
>user would say : You never know...

Well, if you are writing something where "better and faster code"
matters, that 'normal user' *better* know; I most certainly would.  If
it matters, I'm going to check.

>By the way, some compilers really do "great" optimisations. Sometimes
>your optimised programs calculate other ( and wrong ! ) results than
>the non-optimised version....

Yes, there are broken optimizers and there are optimizers that make
'bad assumptions' about what is going on.  Once again, if it matters
I'm going to make a point of knowing.  If I need the speed and my
compiler is broken, I'm going to get another compiler.  How, after
all, can you trust the compiler to get 'with' right if you feel you
need with because the compiler might be broken?  Can you spell
'tautology'? 

-- 
"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.
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Strings and integer sizes
Date: 12 Oct 92 21:48:50 GMT
Organization: negligable

In article <9228521.24288@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>hartman@ulogic.UUCP (Richard M. Hartman) writes:
>
>
>Didn't you read Jos Horsmeier's post, Richard?
>The one that you just replied to? Jos even quoted the standard
>for you, so you don't have to rely on Jos' opinion.

Apparently I MISread it.  Mea culpa.

>>	char zoe[4] = "123";		// good
>>	char zoe[3] = "123";		// possibly not flagged by compiler,
>>					// but dangerous.
>
>This is comp.lang.c, not comp.lang.c++, so the // comments are of course
>illegal. Furthermore the second comment should read "legal, and
>definitely accepted by the compiler, but possibly not what the programmer
>intended".

Unfortunately so.

Sorry about the ++ comments,  they're much more convenient
to type for lazy typists (which is probably why ANSI allows
this misleading form of initializion for char arrays....)


		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Who knows what evil lurks in the hearts of men?"

Newsgroups: comp.lang.c
From: chupchup@ferkel.ucsb.edu (Robert Earl)
Subject: Re: Volatile variables and optimization
Organization: (EVIL!)
Date: Fri, 16 Oct 1992 09:16:06 GMT

votava@fndaud.fnal.gov (Margaret Votava) writes:

| 	I've got a simple question about the correct behavior of the ANSI
| C compiler regarding volatile variables. I have a memory location that I 
| simply want to read. I don't want to do anything with the result; it is
| just a hardware location that needs to be touched.

| 	The following piece of code will access the location when compiled
| without optimization, but is optimized out when optimization is turned on in 
| the compilation command.

| 	I thought the point of volatile was to *always* fetch the value
| from memory.

| int junk()
| {
| 	volatile unsigned short *mem_addr;

Your problem is that the pointer object itself is volatile, rather
than what you wanted, which is the object to which "mem_addr" points.
Try this instead:

unsigned short *volatile mem_addr;


-- 
robert earl          |
rearl@ucsd.edu       | "I got a bottle of tequila, baby, who needs friends?"
rearl@piggy.ucsb.edu |   --Johnette Napolitano, Concrete Blonde
From: mcs@goblin.caltech.edu (Martin Shepherd)
Newsgroups: comp.lang.c
Subject: Re: Dynamically varying the # of args passed to a function (help!)
Date: 10 Oct 1992 20:44:57 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: goblin.caltech.edu

In article <1992Oct9.221204.1825@Trirex.COM> bmehlman@trirex.com writes:
>
>Hello All.
>What I am trying to do is the OPPOSITE of what is usually done:
>
>I am trying to implement a remote procedure call kind of thing, where a  
>name of a function, along with one or more blocks of data to be passed as  
>arguments comes to me through a communications channel.  
>
>I then find the ptr to that function in a table.  I then wish to call that  
>function with my data items as arguments, ie, I want to push my stuff onto  
>the stack, then call the function.  The function would take it's arguments  
>and return as if it were called locally.
>
>If I hard coded each function call into a big switch, then this problem  
>would not exist.  I really don't want to do that.  I want all information  
>to be kept in the table.
>
>Is there any way to do this using some twisted manipulation of the vargs  
>stuff etc??  I could accomplish this relatively easily by resorting to  
>assembler, but that is not acceptable because I have to be portable.
>
>Thanks for any advice, examples, etc!  Feel free to email or post!
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
>    \|/        Ben Mehlman                      Indigo..
>   ^   ^       Trirex Systems Inc      
>   #   #       bmehlman@trirex.com                   Indigoing..
>     @
>   \___/       >NeXTMail Welcome<                           Indigone.

This may not be the best way to resolve your difficulty and I am
interested in alternative suggestions if anybody has any, but in the
past I have attacked this sort of problem by implementing a
pseudo-stack. 

One simply assembles a dynamic array or linked list of pointers to the
blocks of data and sends this along with a count of the number of
blocks to the function. If the called function doesn't know the types
or dimensions of the data blocks at compile time, then one can either
pre-pend an extra simplified printf-like format string argument and
make the array an array of 'void *' pointers (to be cast back to the
appropriate type in the called function) or make the array an array of
descriptors (or pointers to descriptors). These variants require some
extra work on the part of the called function to pull the arguments
out of the array, but little more than with varargs. 

If one doesn't wish the interface to intrude on the original source
code then wrapper functions can be written for each function.

Since all the (wrapper) functions have the same declaration, their
pointers can now be stored in a table and only one function call
statement is needed to call any one of them. For safety it is best to
add type information in the table of functions to ensure that the
functions are called with appropriate arguments. 

I would appreciate comments on whether this is a common or (un)wise
approach.

Martin Shepherd  (mcs@phobos.caltech.edu)
Newsgroups: comp.lang.c
From: Hans Ridder <ridder@zso.dec.com>
Subject: Re: problem with sin on MSC7.0
Originator: ridder@zowie.zso.dec.com
Organization: Digital Equipment Corporation - DECwest Engineering
Date: Thu, 15 Oct 1992 17:28:05 GMT

In article <1992Oct14.191531.3329@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes:
>Im Artikel <1992Oct14.084222.14873@rz.uni-karlsruhe.de> schreibt hans friedrich steffani (GM08@DKAUNI2.BITNET):
>> i have this funktion to build a sin-tabular.

>Es ist ein bisschen schwer,		It is a bit difficult to
>Ihre Frage zu antworten, aus		answer your question, for two

[Lots of bilingual reply deleted....]

>		Stefan Gipfel				Steve Summit
>		scs@adam.mit.edu			scs@adam.mit.edu

Wow!  I'm impressed.  Steve (Stefan) manages to out-do himself again.
It's people like Steve that make it worthwhile to keep reading news....

-hans
-- 
  Hans-Gabriel Ridder				Digital DECwest Engineering
  ridder@rust.zso.dec.com			Bellevue, Washington, USA
  {pacbell,pyramid,uunet}!rust.zso.dec.com!ridder
Xref: sparky comp.lang.c:14776 comp.software-eng:3698 comp.sys.mac.programmer:16761
From: sbill@informix.com (Bill Stackhouse)
Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
Subject: Re: Productivity of a C programmer ?
Date: 10 Oct 92 18:18:43 GMT
Organization: Informix Software, Inc.

In article <qX3DsB2w165w@comtch.spk.wa.us> mhughes@comtch.spk.wa.us (Mark Hughes) writes:
>cjh1@ellis.uchicago.edu (chi ju huang) writes:
>> Could any one show me the light on
>> "Average productivity of a C programmer in today's industry in terms of
>> number of lines of source code produced per day."
>> 
>> What I need is the number (lines/day), the conditions and the assumptions
>> under which the number is derived, and the reliable source of this model.
> 
>  "There ain't no sech animal."  The number of lines per day a programmer 
>turns out can vary incredibly.  Much of the programmer's work is thinking 
>- and that reduces the number of lines, usually.  Other times, the 
>programmer will spew out a hundred or a thousand lines in a day.  One 
>good rule of thumb is that the time to program a project increases 
>geometrically with the size of the program, not linearly.  A small 
>program can be written in 15 minutes...  but a program 20 times larger 
>may take a month...  Etc.
> 
>  The best thing to do is to ask a programmer to evaluate how long it 
>will take a team to write your project, and then add 20% or so...
> 


SLOC does tend to be constant because it is measured across the
total development life cycle (requirments, design, code, test).

Bill
Newsgroups: comp.lang.c
From: ctaylor@sparc7.cs.uiuc.edu (Conrad W Taylor)
Subject: Errors using the memcpy function...???
Organization: University of Illinois at Urbana-Champaign
Date: Fri, 9 Oct 1992 19:00:50 GMT

         I'm receiving the following error messages:

warning: parameter names (without types) in the function declaration
conflicting types for 'bubble_sort'  
previous declaration of 'bubble_sort'

The function prototypes for bubble_sort looks like this:

void bubble_sort(int (*a)[2]);

I'm using memcpy in main to make a temp copy of array a.  My memcopy in main
looks like this:

memcpy((char *) temp, (char *) alpha, sizeof(temp));

I'm making  copy of alpha and sorting temp.  Thanks in advance to all that
reply to this post.

-Conrad