HDTenEightyP/NetNews huggingface dataset:
From: golbone@stein.u.washington.edu (Sima Hashemifar)
Newsgroups: comp.lang.c
Subject: Re: Rounding floating point numbers in C
Date: 22 Nov 92 04:01:45 GMT
Article-I.D.: u.1992Nov22.040145.6371
Organization: University of Washington, Seattle

In article <7959@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>This is not in the FAQ, but perhaps something should go there about the
>inexactitude of FP arithmetic and FP constants.
>
>In article <1992Nov20.215133.3271@enterprise.rdd.lmsc.lockheed.com> gumerman@aspen.ops.lmsc.lockheed.com () writes:
> > The way numbers are rouned is totally inconsistent.  Sometimes numbers are 
> > rounded up sometimes they are rounded down.  What is going on here?
>It is, in a way.  Note that not all numbers are exactly representable on
>the machine.
> > 
> > 1.15      1.1   /* round down */
> > 1.25      1.3   /* round up  */
> > 1.35      1.4   /* round up  */
> > 1.45      1.5   /* round up  */
> > 1.55      1.5   /* round down */
> > 1.65      1.6   /* round down */
> > 1.75      1.8   /* round up  */
> > 1.85      1.9   /* round up  */
> > 1.95      2.0   /* round up  */
>Of these only 1.25 and 1.75 are exactly represented on your machine, so the
>others have representations that are slightly larger or slightly smaller
>than the presented value.  This influences the rounding.  (Looking at the
>numbers, 1.15, 1.55 and 1.65 are represented slightly smaller; taking a
>lot of time it is even possible to deduce a lot of the properties of the
>fp system and fp conversion of your machine.)
>-- 
>dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
>home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl

No! No! No! You can not in any way deduce the properties of the floating
point system based on the rounding behavior. For one, most modern fp
units may be convinced to act in many way, affine ...
More impotantly, there are elementary rules for rounding in scientific
world. Any odd number followed by 5 is rounded down while even numbers
are rounded up. Based on this simple rule, the results printed above
are not valid in your laboratory notebook.
Thanks.
BTW, I ran the numbers through my fortran compiler on DEC/Ultrix, I got 
the scientifically correct results, BUT the C compiler generated the
results above. I can only say that "C" has a different floating point
model than Fortran.
Newsgroups: comp.lang.c
From: abuhr@owlnet.rice.edu (Aaron M. Buhr)
Subject: Help me track down memory leakage
Organization: Rice University
Date: Tue, 17 Nov 1992 06:47:14 GMT

     I've inherited a very large C program that I am trying to maintain and
expand, and I've come to the point where I HAVE to find out where the
program's leaking memory.  The program starts out with about 7MB virtual
mem usage, 6MB real, and grows over the course of 6-8 hours to around 20MB
virtual, 10MB real.  The program uses straight malloc() and realloc() calls.
I don't know where or how to start trying to track this down.  Any help
would be greatly appreciated.  Email is preferred, but I'll try to watch
the posts to this group as well.  Much thanks in advance.


Aaron Buhr
abuhr@owlnet.rice.edu
Xref: sparky comp.lang.c:16706 comp.software-eng:4362
From: ajackson@cs.ubc.ca (Ann Jackson)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 18 Nov 92 04:34:09 GMT
Article-I.D.: cs.1ech41INN6jj
Distribution: world
Organization: University of British Columbia, Vancouver, B.C., Canada
NNTP-Posting-Host: harpoon.cs.ubc.ca

In article <1992Nov13.211018.24360@novell.com>,
Duane Murphy <damurphy@wc.novell.com> writes:
[snip]
|> I recall my first software class.  Here is Fortran syntax; write a
|> program.
|> Not much training.  Not much experience. Compare that to the first _TWO_
|> years of hardware.
|> 
|> Here is a circuit.  How does it work.  There is _TWO_ years of this.  No 
|> design, just analysis.
|> 
|> I believe that we are not teaching programmers analysis before design.  
|> We teach them syntax and pretend that this is analysis.  Analysis is real 
|> and important.  How can you design a program that you cannot read!

This reminds me of taking a course in educational theory last year.
There's a widely-accepted hierarchy of cognitive skills that goes:

       knowledge, ... analysis, synthesis, evaluation

Educators believe that we always learn our way up this hierarchy from knowledge to
evaluation. I commented to the course instructor that in computer software,
synthesis is normally taught before analysis and that analysis receives far
less attention. The instructor replied that he was aware of this, and also that
computer science appears to be unique in this regard. Makes one wonder if the
attractions of programming have distorted our educational policies.

The majority of students graduate and take up entry-level software development
jobs in which they spend more time reading code written by other people (in order
to maintain it) than in writing new code. Yet they've been far more thoroughly
trained in the latter than in the former skill.

Ann Jackson
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Newsgroups: comp.lang.c
Subject: Re: Is this ANSI?
Date: 23 Nov 92 19:40:53 GMT
Article-I.D.: unx.By6pC6.3u7
Organization: SAS Institute Inc.
Originator: sasghm@theseus.unx.sas.com


In article <1992Nov23.180808.19157@ncsu.edu>, jlnance@eos.ncsu.edu (JAMES LEWIS NANCE) writes:

|> I asked my C mentor about this once, and he pointed out that the compiler is
|> free to store the members of the structure in any order.  Thus the compiler 

Nonsense.  See section 3.5.2.1: "Within a structure object, the
non-bit-field members and the units in which bit-fields reside have
addresses that increase in the order in which they are declared."
-- 
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
Newsgroups: comp.lang.c,comp.software-eng
From: mat@mole-end.matawan.nj.us
Subject: Re: Will we keep ignoring this productivity issue?
Summary: Is the analogy flawed?
Organization: :
Date: Tue, 17 Nov 1992 01:23:11 GMT

In article <1992Nov16.091643.13590@netcom.com>, pdh@netcom.com (Phil Howard ) writes:
> mat@mole-end.matawan.nj.us writes:
 
> >... There is no circuit theory for software.  The theoretical computer
> >sciences ...  essential in the long run, but not a first-order theory
> >describing what you work with continually.
 
> The Computer Scientists are too busy trying to get people AWAY from
> thinking about the bits and bytes (and towards the abstract) to get
> people to properly understand how to deal with the bits and bytes.
 
> In EE you START from the bottom and work your way up.  You learn to
> understand the building blocks.  Computers SHOULD be taught the same
> way.  In fact I am awfully tempted to say that the circuit theory and
> digital circuits courses should be taught to even though wanting to
> become programmers.  At least some machine language should be.
 
I see a subtle dissonance here.

Going back to the EE analogy, you learn circuit theory _first_.  Circuit
theory is abstract; it deals with the models you write/draw/think in.  Only
then do you learn about various electronic devices.  Fortunately, passive
devices can often be treated as purely ideal devices, but active devices
generally cannot be; several models will be needed (small-signal + operating
point, for example).

In CS terms, this corresponts to learning E-R, etc., _first_ and then
learning the programming languages by which it the models are implemented.

After you've mastered both circuit theory and basic devices, you can
start to talk about systems (Control Systems, Filters, Comm Theory, etc.)
The corresponding part of CS would be data structures and `fundamental'
algorithms, multiprogramming/multiprocessing, file systems, programming
language translation and code generation, etc.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Xref: sparky comp.lang.c:17071 comp.software-eng:4489
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: Where are literals stored?
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Thu, 19 Nov 1992 13:53:47 GMT

richard@crowded-house.den.mmc.com (Richard Armstrong) writes:
: Are literals always stored in the same location in memory? (IBM-PC,Borland)
: 
: For instance, is the string a stored in the same place in the following
: two declarations?:
: 
: static char a[]="ABC"
: funca()
: {
: }
: 
: funca()
: {
: char a[]="ABC";
: }
: 

   No. The first 1 will actually take up space in the executable module,
and the second will be pulled of the stack at run time. Of course, I am  
curious why you would want to know where literals are stored. There may
be an answer to the bigger question here.

Dave Fuller
dfuller@portal.hq.videocart.com
From: ejd@cimage.com (Ed Driscoll)
Newsgroups: comp.lang.c
Subject: Re: Typedefing builtin... thanks.
Date: 20 Nov 92 16:47:32 GMT
Organization: Cimage Corp., Ann Arbor, MI

In article <1992Nov17.235519.24646@pure.com> rpeck@pure.com (Ray Peck) writes:
  >
  >The only problem with this is a WORD is not a portable concept (i.e.,
  >people in 68k's call 16 bits a word, while people on Real Machines ;-)
  >call 32 bits a word.  All modern machines use 32b and up.
  >
  >
  >For this reason, I prefer types int8, int16, int32, or (better) u1b,
  >u2b, u4b, (unsigned) and s1b, s2b, s4b (signed).
  >

I've been thinking about doing it that way myself, but it seems to me that
you would want two variants of each size: one for when you need EXACLTY
that number of bits, and one when you just need AT LEAST that number of
bits.  The former type would be used where the exact size matters (say,
something you're reading from a file, or something used for bit flags).
The latter type would be used for things like loop counters where you
wanted to use the most efficient size that is sufficient.  For instance,
the "at least 8 bit" type might be defined as a 32-bit int on a machine
that had that as it's "natural" word size.

Opinions on that idea?

  >-- 
  >Ray Peck						rpeck@pure.com
  >Pure Software						415-903-5100
  >

The guys who wrote Purify, right?  Awesome product!


-- 
Ed Driscoll
Cimage Corp.
ejd@cimage.com
Newsgroups: comp.lang.c,comp.software-eng
From: shanks@saifr00.cfsat.honeywell.com (Mark Shanks)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Honeywell Air Transport Systems Division
Date: Wed, 18 Nov 92 14:44:51 GMT

In article <Bxvq7z.DKs@cs.uiuc.edu> johnson@cs.uiuc.edu (Ralph Johnson) writes:
>shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
>
>>> Can love of programming be taught?
>
>>No, no more than fastidiousness can be taught, or leadership, or
>>to stretch, musical genius, superior athletic ability, or how to
>>write a best seller.
>
>>I maintain that superior programming ability is inherent; it can be
                  ^^^^^^^^

Please note I said "SUPERIOR" ability.

>You can teach fastidiousness (my wife teaches it to my children),

Poor kids.

>you can teach leadership,

That's wrong.  I went to the AF Academy, where they TRY to teach
leadership, but I assure you, some people can LEAD, and the rest
are fated to be managers at best.

>you can teach musical talent and athletic
>ability.  You can teach writing, you can teach playing tennis, you
>can teach how to be a stock broker, you can teach how to conduct
>an orchestra and how to be a neurosurgeon.   Sure, you can't teach
>EVERYBODY how to do it, and, in general, it takes so much time to
>be good at anything that people have to pick one thing and then
>spend most of their life concentrating on it.  But it is just silly
>to claim that all things in life are inherent and cannot be taught.

You miss my point entirely, and I suspect you teach. Sure, you can
teach the **fundamentals.** You can teach seals to blow horns, too,
but the Berlin Philharmonic isn't going to sign any up soon. I did not
say all things in life are inherent. I said superior ability, or
genius, is.                                 ^^^^^^^^^^^^^^^^^

> Practice, hard work, and desire are the main attributes
>necessary to developing skill.

>Becoming a good programmer requires lots of practice.  It also requires
>education in the fundamentals.  It also requires native ability.  That
>native ability is pretty much the same as that shared by all engineers
>and mathematicians.  I think the reason that so many engineers and
>mathematicians are poor programmers is because of poor training and
>lack of practice, NOT because of lack of ability.

There, you've said it: native ability. In some rare cases, genius.
You can't teach genius. That "love of programming" or piano
playing or, yes, anal-retentive fastidiousness is THERE or it is NOT
THERE. You can teach a stock broker how to play tennis, but you can't
make a star. And even if the "love", or some level of "native ability"
is there, you can't do anything to create genius. I thought that was the
gist of the question posed.               ^^^^^^ 

Mark Shanks
shanks@saifr00.cfsat.honeywell.com
Newsgroups: comp.lang.c
From: his@gese.ge14.mdadv.gv.at (Horst Hirnschall)
Subject: Re: fwrite & fread
Originator: his@gese0n.ge14.mdadv.gv.at
Organization: MD-ADV, Vienna, Austria
Date: Fri, 20 Nov 1992 08:02:05 GMT


In article <92324.000622U17868@uicvm.uic.edu>, <U17868@uicvm.uic.edu> writes:

[junk deleted]

|> Actually, it should have 194 bytes.
|> typedef struct activity{
|> 	int  id;
|> 	int  mm;
|> 	int  dd;
|> 	int  yy;
|> 	char day[10];
|> 	int  hour;
|> 	int  min;
|> 	int  end_hour;
|> 	int  end_min;
|> 	char location[25];
|>      char with_who[20];
|> 	char phone[11];
|> 	char subj[30];
|> 	char note[300];
|>      int  flag;
|> };

[more junk deleted]

How can you think a structure including a char-array with size 300 can have a size of 194 ?
This structure actually HAS size bytes and you don't need to wonder.

Sometimes I wonder why people not able to count further than three try
to program in C.

HIS Masters Voice.
Newsgroups: comp.lang.c
From: scs@adam.mit.edu (Steve Summit)
Subject: Re: Want function to eval. math expression string...
Organization: none, at the moment
Date: Mon, 16 Nov 1992 17:21:56 GMT

In article <bibhas.721411694@femto.engr.mun.ca>, bibhas@pico.engr.mun.ca (Bibhas Bhattacharya) writes:
> If you have a funtion which accepts a string of math expression and returns
> the value for a supplied x-value, I would like to use it...

Since this question seems to come up from time to time, I have
finally bundled up an expression evaluator of mine and posted it
to alt.sources, under the Subject: line "med -- expression
evaluator and stream-based math processor"; it is Message-ID:
<1992Nov16.160145.7707@athena.mit.edu>.

The package is really in two parts.  The first is an expression
parser and evaluator; because it seemed like a good idea at the
time, the parser produces an intermediate representation (a
simple RPN-like program) which is later executed.  The second
part is "med," a stream-based math processor built upon the
expression evaluator.  med isn't really an editor, but it acts a
bit like sed in that it is often inserted in pipelines.

See the README file for more information.

The code is copyrighted but may be freely redistributed.

					Steve Summit
					scs@adam.mit.edu
Newsgroups: comp.lang.c
From: scs@adam.mit.edu (Steve Summit)
Subject: Achilles and the Tortoise (was: The Correct Way To Write C if-Statements)
Organization: none, at the moment
Date: Mon, 23 Nov 1992 16:33:16 GMT

In article <hansg.722248402@risken>, hansg@risken.vd.volvo.se (Hans Granqvist) writes:
> goudreau@batman.rtp.dg.com (Bob Goudreau) writes:
>> The thing which I find objectionable is the silly testing against
>> TRUE or FALSE.  Certainly the practice of using
>> 	if (condition)
>> instead of
>> 	if (condition == 1)  /*  or == TRUE */
>> is well established in C; look at K&R1.  So why add needless
>> verbiage?
> 
> ...I must object strongly to your
> saying that there's only need to test 'if' or 'if not'. Some FAQ I think
> once said (it still does, I presume) that there is a LOGICAL difference
> to 0, '\0', and NULL. So why not test against the correct values?

The comp.lang.c FAQ list indeed discusses differences between 0
and NULL ('\0' is a red herring in that context), and suggests
that using NULL where appropriate may show good stylistic intent.
Testing a single (conceptually boolean) variable explicitly
against TRUE or FALSE is relatively harmless (depending on how
the variable was set).  Of the more general case "if(<expr> == TRUE)",
however, the FAQ list has this to say:

	...the test

		if((a == b) == TRUE)

	will work as expected (as long as TRUE is 1), but it is
	obviously silly.  In general, explicit tests against TRUE and
	FALSE are undesirable, because some library functions (notably
	isupper, isalpha, etc.) return, on success, a nonzero value
	which is _not_ necessarily 1.  (Besides, if you believe that
	"if((a == b) == TRUE)" is an improvement over "if(a == b)", why
	stop there?  Why not use "if(((a == b) == TRUE) == TRUE)"?)  A
	good rule of thumb is to use TRUE and FALSE (or the like) only
	for assignment to a Boolean variable, or as the return value
	from a Boolean function, never in a comparison.

						Steve Summit
						scs@adam.mit.edu
Newsgroups: comp.lang.c,comp.unix.misc
From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Subject: Re: portable UNIX programs
Followup-To: comp.unix.misc
Keywords: binary port unix
Organization: Department of Chemistry, University of Toronto
Date: Fri, 20 Nov 1992 18:46:39 GMT

In article <1992Nov20.174744.29876@daimi.aau.dk> u920496@daimi.aau.dk
(Hans Erik Martino Hansen) writes:
>I have often wondered why software packages for Unix, was
>distribuated as binary code. Why not distribuate it as 
>in a machine independant format. It is obvious that no software
>company wants their source code accessable for everybody.
>But if a standard was made for a sort of machine independent
>pseudo assemblercode, which could be compiled on any
>UNIX-installation then Unix became the true machine independent
>operating system, which was intended in the first place.

     Isn't that what COFF is supposed to be about?  (I don't know, I'm
asking.)

>If at the same time Unix became
>a smaller system, it would suddenly become very competetive
>to DOS/Windows, Machintosch and other microcomputer operating
>systems. And perhaps in the end become the one and only OS.

     I have always wondered why people wanted that.  When everyone is
doing the same thing, there is little room for innovation.  Besides,
"one size fits all" never does.

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca

P.S.:  I have added comp.unix.misc to the Newsgroups line and redirected
       all followups there since I fail to see the relevance of this to
       the C programming language.  If you disagree, you'll have to
       hand-edit the Newsgroups line.
Newsgroups: comp.lang.c
From: mitch@nosc.mil (Ray Mitchell)
Subject: Appending To A File
Organization: Naval Ocean Systems Center, San Diego, CA
Date: Fri, 20 Nov 1992 19:26:27 GMT


Here is the crux of a test program I wrote to check the effect of
rewinding, then attempting to write to a file opened in the "a+" mode.
My intial expectation was that a rewind within an "a+" file would only
rewind to the end of the data that was in the file when it was opened,
giving an output of:

First
xxxxx

However,

	Output on MS-DOS with both Borland and Microsoft
First
Second
xxxxx

	Output on UNIX with both cc and gcc
Second
xxxxx

	fp = fopen("ftest", "w");
	fprintf(fp, "First\n");
	fclose(fp);

	fp = fopen("ftest", "a+");
	fprintf(fp, "Second\n");

	rewind(fp);
	fprintf(fp, "xxxxx\n");

	rewind(fp);
	while ((c = getc(fp)) != EOF)
		putchar(c);

Although I didn't expect either output, the MS-DOS seems closer to
what I did expect.  I guess my question boils down to what the rewind
(and I assume all the other positioning functions) are supposed to do
in the "a+" mode.  I had assumed that at least data already in the file
when opened in that mode would be protected from overwriting but this
doesn't seem to be the case on UNIX.  Is such operation actually documented
anywhere?

Thanks,

Ray Mitchell
mitch@nosc.mil
Newsgroups: comp.lang.c
From: jutta@opal.cs.tu-berlin.de (Jutta Degener)
Subject: Re: const char *p == char const *p ?
Organization: Techn. University of Berlin, Germany
Date: Mon, 16 Nov 1992 01:08:20 GMT

bonak@herky.cs.uiowa.edu (Esmail Bonakdarian) writes:
> Is "char const *p" equivalent to "const char *p"?

Yes.  They are both pointers to constant character; you may
change the pointer, but not the character it points to.

Some programmers prefer "char const *" to "const char *".
They argue that C declarations are read "inside out":

   char const * p ;
                ^     p is a
              ^              pointer to
        ^^^^^                           constant
   ^^^^                                          char

But that's just a matter of style.

Jutta
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Memory Info.
Date: 21 Nov 92 12:54:31 GMT
Organization: AND Software BV Rotterdam

In article <1992Nov20.130913.20148@sifon.cc.mcgill.ca> vugranam@pike.ee.mcgill.ca (Vugranam Chakravarthy Sreedhar) writes:
|
|Given a pointer to a object that has been previously allocated using
|one of the allocation routine, how can I get the
|size of the object.

If you want to do that in a portable way, I have to disappoint you: there's
no way to determine the size of an allocated object. but read on ...

|char *c;
|long  x ; 
|
|c = (char *) malloc (100) ;
|x = mem_size(c) ;   /* x is block size of c, which in this case is 100 */
|
|I want to use this to keep track of memory statistics. Now what I do is
|to pass the size to my memory routines. Like
|
|int *mymalloc(size) ;  /* this is easy */
|int myfree(char *, long size)   /* I don't like this !!*/

Two solutions come to mind:

1. Use an array of the followingt objects:

typedef struct {
	void   *object;
	size_t size;
} object_t;

and write your own my_malloc and my_free routines. my_malloc has to
find an empty slot in that array and store the pointer and the size
of the allocated object into that slot. my_free has to find the 
specified slot and mark it as free again. The bad thing about this
solution is the fixed size array. You cannot allocated more objects
than there are slots in the array, without freeing at least one of
the other objects before. reallocating the array of slots seems a
bit clumsy to me, but it can be done.

2. Allocate a bit more memory than was requested and stick the size
into the additionally allocated bytes. my_malloc and my_free would 
look something like this:

void *my_malloc(size_t size) {

	size_t *object;

	size+= SLOTSIZE;			/* make room for size */

	if (object= malloc(size)) {
		*object= size;			/* register the size */	
		((char*)object)+= SLOTSIZE;	/* step over size slot */
	}
	return (void*) object;
}

void my_free(void *object) {

	if (object) {
		((char*)object)-= SLOTSIZE;	/* object points to size */
		free(object);
	}
}

SLOTSIZE is a manifest constant that has to obey to the following rules:

- SLOTSIZE >= sizeof(size_t)

- SLOTSIZE is the smallest multiple of the most stringent alignment
  size needed on your machine, e.g. on a SPARC the alignment of a double
  is 8 bytes (the most stringent alignement), where the alignment of a
  size_t is 4 bytes, so SLOTSIZE would be 8 in this situation. 

Your wanted function mem_size would look something like this:

size_t mem_size(void *object) {

	if (object) 
		return *((size_t*)((char*)object)-SLOTSIZE);
	else
		return 0;		/* or whatever */
}

All this casting and byte fiddling works just because malloc always
returns a pointer to a chunk of memory that is always suitably aligned
for all types of objects.

I hope this helps a bit.

kind regards,

Jos aka jos@and.nl