HDTenEightyP/NetNews huggingface dataset:
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 18 Nov 92 10:11:50 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <Bxtq6J.Br1@cs.uiuc.edu>, hasker@cs.uiuc.edu (Rob Hasker) writes:
> pdh@netcom.com (Phil Howard ) writes:
>> mat@mole-end.matawan.nj.us writes:
>>> Echoing my own favorite refrain: There is no circuit theory for
>>> software.
>> 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.

Which is natural enough: the computer scientists are doing computer
science, not programming.  They are different things, requiring
different talents and different skills.  That they are so often
confused is unfortunate and is probably part of the problem.  One of
the causes of this confusion may well be that some of the brightest
stars in each field are also famous in the other (Knuth comes to mind
as an example).

>> In EE you START from the bottom and work your way up.
> The question is, what is the "bottom" in CS?  Hardware?

What level of hardware?  The board level?  The VLSI chip level?  Gates?
Transistors?  Electrons tunneling through energy barriers?

Yes, knowing something about all of those is worthwhile.  But you must
know when you should *not* let yourself know what's actually going on
under the hood, or else knowledge of the lower levels is likely to do
more harm than good.

> Others would argue the case for the basis of CS being math.

It is, largely.  After all, CS is basically a branch of mathematics.

Programming, on the other hand, is not.  I don't know what it is.

Each of them is involved with the other in various ways, and a
knowledge of each is helpful to anyone interested in the other.  But
they are not at all the same thing.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: strange things with gcc
Date: 17 Nov 92 04:46:40 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <9232201.24197@mulga.cs.mu.OZ.AU>, carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer) writes:
> I've had some funny problems with gcc on SunOS 4.1.2 of late, it doesn't
> seem to handle fflush(stdin) very well (ie not at all).

The standard does not require a C compiler to do anything with fflush(stdin).
Calling fflush(stdin) may, as the saying goes, cause demons to fly out of
your nose.  Chris Torek's implementation quietly does nothing when you
fflush() a file that is not in write mode.

> my code works fine compiled under acc (SunOS 4.1.2), and microsoft QuickC
> on a 386 PC.  The relevant function is even straight from a book ...

Please tell us what the book is so that we will know never to buy it.


Since you explicitly mentioned SunOS 4.1.2, why didn't you check the on-line
manual?  It says

     fflush() writes any unwritten data for an output  stream  or
     an  update stream in which the most recent operation was not
     input to be delivered to the host environment to  the  file;
     otherwise it is ignored.  The named stream remains open.

That is the "BSD" interface.  The standard requires no more than that.
If you keep on reading, you find under SYSTEM V DESCRIPTION that the
System V version will discard unread input from an input stream.

So the answer is simple:  make sure that your program is linked with the
System V stdio.  How do you do that?  It is very clearly described in the
SunOS documentation.  Check LD_LIBRARY_PATH in the manual page for ld(1).
(Hint:  there is a /usr/5lib.)

If what you _really_ want is to flush buffered input from the terminal,
then beware:  there may be input buffered by the operating system that
stdio doesn't happen to have read yet.  Check the function tcflush() in
the "termios" manual page; you'll need that _as well as_ fflush(stdin).

Newsgroups: comp.lang.c
From: chambles@whale.st.usm.edu (John William Chambless)
Subject: Re: People's Criticism of C (was Re: Macros)
Organization: University of Southern Mississippi
Date: Sun, 22 Nov 1992 12:50:44 GMT

In article <By02nr.5E8@research.canon.oz.au> andy@research.canon.oz.au (Andy Newman) writes:
>
>Well in other environments where you have tools that can possibly be
>used incorrectly and cause damage you have regulatory bodies. Think
>about the USA's FAA, FCC, FDA, etc... Should there be a Federal
>Computer Language Authority that dictates what langauges can be used
>and in what situations? (Shades of the UK's DoD standards.)
>
 I don't think so, Andy.
The agencies you named all deal with issues of health and/or safety.
Governments need not interfere in choice of language, because:
	1) It is a semi-artistic decision.
	2) Different programmers use differnet languages for the same job.
	3) Government regulation is the most efficient way to foul
		anything up.

The point I was making about people criticising C is that C is a
super-effective tool for many programmers, provided they take the time 
to learn all the little quirks of the language.

In programming, as in real life, freedom implies responsibility.

Personally, I think the folks who dislike C should stick to another
language. COBOL is pretty safe :).

-- 
* Billy Chambless   University of Southern Mississippi, USA 
*   chambles@whale.st.usm.edu
*    
*   Programming exclusively in (--(C++))
Newsgroups: comp.lang.c
From: rescorla@rtnmr.chem.yale.edu (Eric Rescorla)
Subject: Re: C for loop
Organization: Rescorla for himself.
Date: Fri, 20 Nov 1992 16:02:00 GMT

In article <1992Nov20.134343.4978@magnus.acs.ohio-state.edu> ckkoo@magnus.acs.ohio-state.edu (Chee K Koo) writes:
>I am new to C programming, while i was doing a numerical analysis
>program which uses many for loop
>here is the loop looks like
>for(i=1;i<=n;i++);
>{
>}
>i put the ";" after the loop header, when the program is excuted, the loop
>is skipped, however, it works fine when the ";" is removed.
>I just want to find out why the compiler does not catch it during
>compilation. It is compiled with UNIX gcc.
Because it's perfectly legal, and not even guaranteed to be stupid.
-Ekr




-- 
-------------------------------------------------------------------------------
Eric Rescorla, DoD#431 (Nighthawk S)              rescorla@rtnmr.chem.yale.edu
Former chemist now CM400 mechanic                 ekr@eitech.com(preferred)
                "Meet the new boss, same as the old boss."
Newsgroups: comp.lang.c
From: sca@gese.ge14.mdadv.gv.at (Petzi Schweda)
Subject: Re: Virtual memory Management Systems
Originator: sca@gese0n.ge14.mdadv.gv.at
Organization: MD-ADV, Vienna, Austria
Date: Tue, 17 Nov 1992 13:33:27 GMT


In article <1992Nov17.103746.20006@di.unipi.it>, Nico Tranquilli <ntranqu@caticsuf.cati.csufresno.edu> writes:
|> Could anyone please tell me how to call the Hardware/Software needed
|> to manage virtual memory ?
|> --
|> nico.

Huh ?

UNIX: don't know more then malloc/calloc ...
VMS: see lib$get_vm in your RTL-doc's
PC/WINDOWS: GlobalAlloc/GlobalLock 
WINDOWS NT: VirtualAlloc

Is it that you wanted to know ?

regards, Petzi
-- 
Petzi Schweda (sca@gese.ge14.mdadv.gv.at)
MD-ADV, Municipality of the City of Vienna, Austria
From: ori@ferrari.dsp.hellnet.org (Ori Chalak)
Newsgroups: comp.lang.c
Subject: C-compilers
Date: 17 Nov 92 13:20:03 GMT


Hi there,

  Is there any newsgroup of C-compilers ?
  Is there any available data on the net, regarding C-compiler writing ?


                  Thanks in advance

                                 Ori.
-- 
----------------------------------------------------------------------------
Ori Chalak                                 Telephone:    972 3 531 3282
Cad Programmer and System Administrator    Fax:          972 3 531 3303
DSP-Semiconductors  I S R A E L            Email:        ori@dsp.hellnet.org
Newsgroups: comp.lang.c
From: sumargoh@serss0.fiu.edu (H. Sumargo)
Subject: C source code for async/sync communcation using RS-232
Reply-To: sumargoh@fiu.edu
Organization: FIU Electrical & Computer Engineering
Date: Thu, 19 Nov 1992 22:07:51 GMT
Keywords: Communication

I am currently trying to write a communication project for a class.  I am looking for
the source code to send and receive data through RS-232.  If you can give some pointers
as to where I can get the souce code, please email your response to sumargoh@fiu.edu.
I prefer a C source code; however, IBM pC assembly source code is also welcome.

Thank you very much.
Newsgroups: comp.lang.c,gnu.gcc.help
From: sim@mdtf14.fnal.gov (Jim Sim)
Subject: Include file directory search path
Organization: Fermilab, Batavia, IL
Distribution: usa
Date: Wed, 18 Nov 1992 21:14:48 GMT

Is there a way to force the C preprocessor to use the same search path to
locate nested include files (files included by another include file) 
that it uses to locate non-nested include files. My motivation for doing 
this is to allow developers to make "test" changes to nested include files 
that don't affect "official" versions of those include files. Consider the 
following:

main.c:

#include "non-nested.h"

main()
{
  /* Statements that use variables / macros declared / defined in 
     nested.h. */
}

non-nested.h:

#include "nested.h"

nested.h:

variables/macros 

cc -c main.c -I/usr/local/official main.c

or 

gcc -c main.c -I/usr/local/official main.c

If /usr/local/official contains both nested.h and non-nested.h files, while 
the "test" directory contains only nested.h, the version of nested.h from the
/usr/local/official directory is used by the preprocessor.  I would prefer it 
to use /usr/local/official/non-nested.h and the version of nested.h 
in the "test" directory.

There is no problem if the "test" directory contains non-nested.h in addition
to nested.h.  In this case, the preprocessor uses both nested.h and 
non-nested.h from the "test" directory.  However, I would prefer not to
be required to copy /usr/local/official/non-nested.h to the "test" directory
when I am not making changes to that file.

There is also no problem if I delete /usr/local/official/nested.h. In this
case, because nested.h did not exist in the /usr/local/official directory,
the preprocessor looked for it in the "test" directory. However, since 
my make procedures have dependencies that force re-compilation of "official" 
code (after SCCS extraction of /usr/local/official/nested.h), this results in 
unnecessary recompilations.
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Appending To A File
Date: 24 Nov 1992 01:48:48 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <1992Nov20.192627.8533@nosc.mil> mitch@nosc.mil
(Ray Mitchell) writes:
>rewinding, then attempting to write to a file opened in the "a+" mode.

[various sample outputs deleted]

The UNIX version tested in the original article fails to conform; the
MS-DOS Borland and Microsoft outputs conform to the ANSI standard.

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

Stdio positioning functions have two effects:

	a) They reposition the file for the next input or output
	   operation.
	b) They reset `+'-mode files so that the next operation may
	   be either input or output.  Once I/O is begun, another file
	   position operation is needed to `change directions'.  (Some
	   implementations, such as my own, waive the right to demand
	   such a positioning operation, but other significant existing
	   C libraries required it, so it got put into the ANSI C
	   standard.)

Now, in the case of `a'ppend mode, all writes are supposed to be
appended to the file, regardless of any intervening fseek, fsetpos,
or rewind operation.  Thus, for "a+" mode, only effect (b) above
is relevant.

If you want to append to a file, with the option of replacing the
appended text within the same run, you must open the file in "r+" mode
(or "w+" if it does not yet exist), position to the end with fseek(),
remember that position with fgetpos, append, and then return to it with
fsetpos.  Note that some systems will impose strange restrictions on
`position to the end', such as requiring that `the end' always be a
multiple of 512 bytes.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.lang.c
From: jon@stekt.oulu.fi (Jouni Miettunen)
Subject: Re: Rounding floats to integers
Organization: University of Oulu, Dept. of EE, Finland
Date: Sun, 15 Nov 1992 21:57:38 GMT

In article <alien.010i@acheron.amigans.gen.nz> alien@acheron.amigans.gen.nz (Ross Smith) writes:

> >>Is there a C routine that will round off floating point numbers
> >>to the nearest integer.  K&R says that floats are converted to
> >>integers by removing the fractional part, however, I could not

I once needed a rint(3m) function when trying to port unix C to ANSI C
and this is what I used:

#include <math.h>
double rint(register double f)
{
	return (f >= 0) ? floor(f + 0.5) : ceil(f - 0.5);
}

It seemed to return correct values,

--jouni


--

* Jouni Miettunen  jon@stekt.oulu.fi  * Oulu * Finland * Europe *
*** Good fortune will find you, providing you gave directions ***
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: Multiple Parameter Passing (unspecified number)
Date: 18 Nov 92 07:53:50 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <92321.124834GNR100@psuvm.psu.edu>, <GNR100@psuvm.psu.edu> writes:

> I'm looking to write a function that accepts any number of
> paramerter.  There will be at least two, an int and a char[].  The
> rest will all be char[]'s.  I need to know how this is done.

In C Classic, <varargs.h>; in New C (ie, ANSI), <stdarg.h>.  You will
have to figure out how many arguments there are somehow - perhaps from
the arguments you know are present, perhaps by having some magic value
(nil pointer, for example) as the last argument or something....

For example, if we assume that the first arg is the number of extra
arguments, and the second arg is a buffer, and we're supposed to strcat
all the strings together into the buffer, assuming the buffer is big
enough:

C Classic:

	#include <varargs.h>

	void strcatall(va_alist)
	va_dcl
	{
	 va_list ap;
	 int na;
	 char *buf;
	
	 va_start(ap);
	 na = va_arg(ap,int);
	 buf = va_arg(ap,char *);
	 buf[0] = '\0';
	 for (;na>0;na--) strcat(buf,va_arg(ap,char *));
	 va_end(ap);
	}

New C:

	#include <stdarg.h>

	void strcatall(int na, char *buf, ...)
	{
	 va_list ap;
	
	 va_start(ap,buf);
	 buf[0] = '\0';
	 for (;na>0;na--) strcat(buf,va_arg(ap,char *));
	 va_end(ap);
	}

(Of course, there are better ways to do this, like advancing buf and
using strcpy...it's the varargs stuff I'm trying to illustrate, not
string manipulation.)

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.lang.c
From: eager@eagercon.com (Michael J. Eager)
Subject: Re: Multiple Parameter Passing (unspecified number)
Reply-To: eager@eagercon.com
Organization: Eager Consulting
Date: Thu, 19 Nov 1992 17:39:22 GMT

In article 21867@henson.cc.wwu.edu, n8743196@henson.cc.wwu.edu (Jeff Wandling) writes:
>I'm trying to do a similar thing, except my function doesn't know what type
>to expect.  The next "variable argument" could be any simple type.  How
>do I deal with this?  Is there a way to switch on the type of the next
>argument? When using union's for example---

The function receiving the value has to know what to expect, or it has to be
told in some fashion.  Values in C do not identify their types.  So you have to 
pass the information in some form, perhaps in a control string like printf,
or in an array with type codes.


---
Michael J. Eager		Michael.Eager@eagercon.com
Eager Consulting		(415) 325-8077 
1960 Park Boulevard, Palo Alto, CA 94306-1141

Newsgroups: comp.lang.c
From: cs202144@umbc8.umbc.edu (cs202144)
Subject: Re: Pascal as C prelude?
Organization: University of Maryland, Baltimore County Campus
Date: Sun, 22 Nov 1992 23:05:14 GMT

<Much stuff deleted>

>There's just one drawback, when you do this: you'll end up writing
>ugly formatted code like:
>
>if (condition)
>	{
>	statement1;
>	statement2;
>	}
>
>instead of the proper:
>
>if (condition) {
>	statement1;
>	statement2;
>}

Why is this 'proper'? I never use it and find it harder to read...What I use is
closer to the first example except I would never indent so far. I would have
written it:

if (condition)
   {
   statement1;
   statement2;
   }

I find this very easy to read and nicely presented within the block so you
know exactly what is going on.
From: map@ratt.rutgers.edu (O. C.)
Newsgroups: comp.lang.c
Subject: write an int?
Keywords: why not
Date: 20 Nov 92 00:09:03 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


I want to write an integer to a text file using the Unix system call
write,

write(file descriptor,buffer,size);

but I can only seem to get it to work for strings and characters.

What am I doing wrong?
Newsgroups: comp.lang.c
From: isc40038@nusunix1.nus.sg (LIM FANG HOW)
Subject: How to implement mandatory locking
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 24 Nov 1992 02:30:26 GMT

I am working on a interprocess communication project. It consists of a
set of concurrent processes accessing a set of files. To achieve
consistency, I had tried to use advisory locking with the following
command :
        for (x=1;x<=2000;++x) {
           if ((flock(fd,LOCK_EX|LOCK_NB))==-1)
              print error messages;
            else break;
        }

However, it gives me a deadlock situation.

Thank you all.

Newsgroups: comp.lang.c
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: Reasons for using C vs. Fortran or vic
Organization: McGill Research Centre for Intelligent Machines
Date: Sun, 15 Nov 92 20:15:55 GMT

In article <1992Nov13.162451.13049@zia.aoc.nrao.edu>, cflatter@nrao.edu (Chris Flatters) writes:

> Storing arrays by column or by row doesn't make any difference
> whatsoever to the speed of matrix operations: it is merely a notation
> change.

This is true only in the abstract.  I have experienced (not just heard
about) multiple orders of magnitude speed differences, because going
through arrays "the wrong way" had catastrohpically bad VM behavior:
essentially, every access involved a page fault.  Doing it "the right
way" stepped through VM in a nice sequential way, with minimal paging.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Wanted: Supported equivalent of FileMerge
Date: 23 Nov 92 17:05:21 GMT
Organization: none, at the moment

In article <1992Nov19.052343.14116@netcom.com>, mcgregor@netcom.com (Scott Mcgregor) writes:
> In article <19921118.105028.391@almaden.ibm.com> dougv@vnet.ibm.com writes:
>> Does anyone know of a "FileMerge" type program which allows you to visually
>> merge two files into a third one with selected parts from each of the
>> originals?  SUN used to distribute such a program, but it's only SunView
>> (I'd like OpenLook), and it's no longer supported.
> 
> My company, Prescient Software Inc. sells such a product, Merge Ahead.
> The 2.1 release is based upon Motif widgets, but runs fine under Open
> Windows...

This has little to do with either of these newsgroups, but I
can't resist a suggestion.  If there is anyone out there running
neither Motif nor Open Windows, or who does not have money to
spend on tools like this, or who simply prefers using existing
tools to get the job done when reasonably possible, and who is
running something like Unix, just do

	diff -DBLORT oldfile file > newfile

The output will be a merge of the two input files, with
differences indicated by easily-located lines of the form
"#ifdef BLORT" [note 1].  Use your favorite text editor to locate
these differences and select which alternatives should appear in
the final output.

(Of course, if you find this technique cumbersome, you are more
than welcome to pursue more "elegant," special-purpose solutions.)

					Steve Summit
					scs@adam.mit.edu

Note 1. Early versions of diff, however, did not support the -D
option.
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: ANSI C document required (FAX or e-mail)
Organization: Texas Instruments Inc
Date: Mon, 16 Nov 1992 16:16:22 GMT

In <1e89stINNbvk@usenet.INS.CWRU.Edu> ah739@cleveland.Freenet.Edu (Leslie J. Somos) writes:


>In a previous article, broglia@ghost.dsi.unimi.it (marco broglia) says:

>>
>>We are researchers of the Computer Science Department, University of
>>Milan (Italy), and we're interested in getting a copy of the Standard
>>document about ANSI C (maybe X3.159-1989 from last FAQ).
>>Our problem is that we're looking for a fax number or e-mail address on
>>which ask for detailed info about this.
>>Thanks in advance and
>>    Best regards.
>>
>>/*
>> * Marco Broglia    broglia@mars.usr.dsi.unimi.it
>> * Stefano Gobbo    gobbo@ipmel2.elet.polimi.it
>> */
>>

>Read the group comp.std.c

>From what I remember, what you are asking for is not
>available electronically, because it costs money ( ~$50 ).
>You have to contact ANSI directly (in New York City).
>(But don't wait too long.  I understand that the next
>version from ANSI will be 'synchronized' with the ISO
>standard, meaning mostly that it will omit the 
>commentary giving the reasons behind everything.)

Let me see if I have this straight.  ANSI is going to DEGRADE the
current version of the standard to get a version that is
'synchronized' with how ISO does things?  Do they have any plans on
publishing a separate Rationale document or something so that people
who are interested in 'why' don't lose all that information?  Do they
plan on dropping the price, since the document will contain a subset
of the current information in the document?

-- 
"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,comp.software-eng
Newsgroups: comp.lang.c
Subject: Curoius
Date: Thu, 12 Nov 1992 21:18:58

I think I recognized your name. Did you go to UTA? As I recall that there was a fella by your name in  Phi Delta Theta around about 1980 or so. We met once or twice. Is this You????


 * Origin: This Message Leached from CyberVille... (1:130/78)
Newsgroups: comp.lang.c
From: wells@cdsmn.mn.org (Rich Wells)
Subject: Re: the abs() function in C
Organization: Dicomed, Inc
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 20 Nov 1992 22:45:54 GMT

Michael Maurer (maurer@nova.stanford.edu) wrote:
: In <pebi.722223424@zephyr.aem.umn.edu> pebi@aem.umn.edu (Peter A. Bidian) writes:
: 
: >Isn't abs(-2)=2 in C?
: >I always get 0.

Your compiler sounds seriously broken.  Care to let us know what
compiler it is, so we can avoid it?  (Some code showing how to
reproduce the problem may be handy, too, in the outside chance
that it is a cockpit error.)

: you probably want to say abs(-2.0), if the abs() function expects a
: floating point argument.  or abs((double)-2).

Wrong.  abs() takes and integer argument, and returns an integer.
(Thus, it should even work without including stdlib.h.)  fabs()
is the equivalent for floating point numbers.  (And, just to be
complete, labs() for long integers.)  If the original poster's
C compiler expects abs() to take a floating point argument, it is
as seriously broken as if it returns 0 for abs(-2).
-- 

Richard Wells  wells@cdsmn.mn.org  or  ...!tcnet!cdsmn!wells
Xref: sparky comp.lang.c:16877 comp.software-eng:4427