HDTenEightyP/NetNews huggingface dataset:
From: bketcham@stein.u.washington.edu (Benjamin Ketcham)
Newsgroups: comp.lang.c
Subject: Re: HELP!!! Converting strings to floats....
Date: 11 Nov 92 23:11:16 GMT
Article-I.D.: u.1992Nov11.231116.8398
Organization: University of Washington, Seattle

In article <1992Nov4.180414.24623@brtph560.bnr.ca> markham@brtph600.bnr.ca (Andrew Markham P205) writes:
>dnl@convex.is.macsch.com (David Lombard) writes:
>>
>>                 MY_COMMENTS = MY_OPINIONS = NOBODY_ELSES;
>>
>>David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp
>>dnl@macsch.com      Let's kill all the lawyers.    815 Colorado Blvd
>>(213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041
>
>I can see:
>
>(MY_COMMENTS == MY_OPINIONS) && ((MY_OPINIONS != NOBODY_ELSES) ||
>                                 (MY_OPINIONS == ONE_OR_MORE_PERSONS))
>
>But to say that MY_OPINIONS = NOBODY_ELSES implies that you have an
>opinion no one else has, not that your opinion is not necessarily that
>of someone else.  Are you sure your logic is correct?  Better yet, is
>my logic correct?
>

I don't think so.  The first person's logic looks good to me.  He has
simply set his comments and his opinions to equal nobody elses'.  It
might be a little contrary of an attitude, to define by exclusion, but
it ought to work (as long as all the opinions and comments are of the
same type;  I suppose you might have trouble if you tried to set your
nasty opinion equal to someone else's biased opinion...)

But in your logic, no opinions or comments actually change value at all,
they are simply tested, and nothing is done with the resulting boolean
value.  So your logic seems to be somewhat useless, although not wrong.

--ben
Newsgroups: comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: & of array - what does ANSI specify for resulting value?
Organization: Sequoia Peripherals, Inc.
Date: Thu, 12 Nov 92 21:19:18 GMT

In article <1992Nov12.174305.1901@ils.nwu.edu> engber@ils.nwu.edu (Mike Engber) writes:
>
>int foo[3];
>
>I know ANSI specifies the type of &foo will be an int**, how about
>the value? Is it unspecified - or - &foo[0].

No, ANSI doesn't specify this. 

foo is an array of the ints (int [3]), so its address is a pointer
to that type, a pointer to an int of 3 arrays (int (*)[3]), not
an (int **) which is a pointer to a pointer to an int. Array names
are converted to a pointer to their first element when used in an
expression; they are not converted when used as the operand of sizeof
or &.

I really don't understand what you mean by its value. &foo is clearly
a pointer which points to foo. This is, after all, the definition of
the "&" operator. But I'm sure you knew that. So what are you driving at?



-- 
Dave Eisen                               Sequoia Peripherals: (415) 967-5644
dkeisen@leland.Stanford.EDU              Home:                (415) 321-5154
       There's something in my library to offend everybody. 
          --- Washington Coalition Against Censorship
From: Josef Moellers <mollers.pad@sni.de>
Newsgroups: comp.lang.c
Subject: Re: Order of evaluation?
Date: 5 Nov 1992 11:49:59 +0100
Organization: Siemens Nixdorf Informationssysteme AG, Paderborn, Germany

In <1992Nov2.192805.17329@CSD-NewsHost.Stanford.EDU> amorgan@Xenon.Stanford.EDU (Crunchy Frog) writes:

>In article <josef.720691377@uranium> Josef Moellers <mollers.pad@sni.de> writes:
>>
>>Furthermore, as "boolean" operations are nothing special in C, I wonder
>>whether in
>>	a() || b()
>>b _should_ be called if a() returns TRUE.

>It shouldn't be.  C has short circuit evaluation for && and ||.

I'd like to clarify a mis-understanding.
I _do_ know, how || and && work under C.

The original thread was about whether a C-Compiler must arrange for
first calling all functions and then evaluating the expressions.

In my example, the original claim would mean that a() _and_ b() are
called first, then the left side was (trivially) evaluated using the
results of the call to a(), and if it was found to be TRUE, the result
of the call to b() was dropped.

My understanding was (and still is), that functions need only be called
as far as necessary.
E.g. in an expression like
	a() * b() * c() * e() * f() * g()
the compiler might decide to generate code to test the intermediate
result to be 0, in which case the rest of the expression might be
dropped.
-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |
From: wenner@einstein.eds.com (Rich Wenner)
Newsgroups: comp.lang.c
Subject: Re: Hows this for odd
Date: 10 Nov 92 22:38:38 GMT
Organization: Electronic Data Systems

In article <1992Nov10.161008.27590@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>In <1992Nov9.231340.10201@ptcburp.ptcbu.oz.au> michi@ptcburp.ptcbu.oz.au (Michael Henning) writes:

>>bena@yoyo.cc.monash.edu.au (Ben Aveling) writes:

>>>Just recently I saw the following fragment of code, and I thought I'd share
>>>it with you all.  (This is real code, part of a real program people will
>>>pay money for.)

>>>	... ,(i==0)?TRUE:FALSE,...

>>From the source code for a popular UNIX debugger:

>>	if (strncmp(p, "", 1) != 0) {
>>		...
>>	}

>>There are lots of gems like that around :-(

>Well, I generally do the explicit comparison on string comparisons,
>too, because ...

I think you missed the point.  The above code compares "p" and the null string
for a span of either 1 character or 1 more than the length of the shorter
string, whichever is less.  This is something a sane programmer would code

	if (*p)

or, for the more verbose (but still sane -- no flames, please),

	if (*p != '\0')

>I'm afraid I find this other idiom ("(i==0)?TRUE:FALSE") to be just a
>bit peculiar, though.

Just a bit peculiar?  My, but you are a kind-hearted soul.  :)

Why is it that nobody in this thread has yet mentioned that the above
expression reverses the logic?  Is this equivalent to

	!i

or have I been reading too much of my students' code?

	
-- 
Rich Wenner              | Subject and verb always has to agree.
wenner@csid.gmeds.com    | Consult a dictionary frequently to avoid mispelling.
                         | Hopefully, you will use words correctly,
#include <stddisclaim.h> |            irregardless of how others use them.
Newsgroups: comp.lang.c
From: yngvar@imr.no (Yngvar Foelling)
Subject: Re: Typedefing builtin... thanks.
Organization: Institute of Marine Research, Bergen, Norway.
Date: Fri, 13 Nov 92 17:20:05 GMT

In article <1992Nov11.061812.21905@sq.sq.com>, msb@sq.sq.com (Mark Brader) writes:
|> > The major arguments used to justify these techniques were about portability.
|> > A program is easier to port, when you can change some typedefs in a header
|> > file, instead of changing a lot of ints to longs all over the code.
|> 
|> There are good reasons for typedefs, but this is not one of them.
|> If the code was correctly written, those ints would have been longs
|> in the first place.  See item 10.1 in the FAQ list.

Yes, let's.  Particularly the last paragraph:

        If for some reason you need to declare something with an _exact_
        size (usually the only good reason for doing so is when
        attempting to conform to some externally-imposted storage
        layout, but see question 17.2), be sure to encapsulate the
        choice behind an appropriate typedef.

In this case, it seems like Jonatan Kutchinsky _was_ trying to match an
"externally-imposted storage layout".  He wanted to simulate a particular
processor.

Personally, I've used this technique several times, and for similar reasons.

BTW, does anyone know about a C-compiler with 64-bit longs?  Even if there
aren't any right now, it seems to me that one would have to be written to take
advantage of 64-bit architechtures.  In that case, using long instead of int
would be overkill.
-- 
Yngvar Flling (yngvar@imr.no)
Institute of Marine Research
Bergen
Norway
From: wjmc@unix.brighton.ac.uk (-*_Cuddly_Cactus_*-)
Newsgroups: comp.lang.c
Subject: Help: pointer declarations
Date: 11 Nov 92 12:14:43 GMT
Organization: University of Brighton, UK

I've looked in the last version of the FAQ that I saved but I can't figure
this one out: I want a variable which will hold a pointer to an array of
pointers to functions returning int, and a similar one for void. I can get
the int (*tbl[])() bit ok, but how do I declare a pointer to this array ?

Please e-mail as this is a pretty dumb question I'm sure ...
-- 
# Bill Crawford aka *Cuddly_Cactus*  BSc (Hons) Computer Science Year One #
# JANET wjmc@uk.ac.bton.{unix,vms} | Elsewhere wjmc@{unix,vms}.bton.ac.uk #
#  Have you read your Book In Basic Life Education today ? You should !!  #
#  Any views I express are not necessarily those of Brighton Polytechnic  #
                     ".surivorter erutangis. a ma I"
Newsgroups: comp.lang.c
From: bakowskr@wm-mercer.ca (Ron Bakowski)
Subject: **HELP** - BASIC language blues
Organization: William M. Mercer Limited, Toronto, Canada
Date: Mon, 9 Nov 1992 21:17:27 GMT


	Boss dumps 3000 lines of ahem, TRUE BASIC code on my desk and says,
	"We wanna see this run on the Unix box - in C - easy stuff, eh Ron?!"

	Does anyone know of a conversion program or some such utility?

	Or, since TRUE BASIC's grammar is *real* simple, should I try writing
	a sort of pre-compiler - LEX, YACC etc?

	THANK YOU in advance for advice and/or direction.

	Gratefully, Ron B.

	PS.  I know more is coming - my boss is *SO* predictable.
-- 
--------------------------------------------------------------------------------
Ron Bakowski	(416) 868-7688	                             |  Have Assembler
bakowskr@wm-mercer.ca                                        |   Will Travel
--------------------------------------------------------------------------------
Organization: Applications Software, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.lang.c
Date: Fri,  6 Nov 1992 19:14:58 -0500 
From: Richard Dale Romero <rickr+@CMU.EDU>
Subject: Re: To Recurse or NOT to recurse?

Excerpts from netnews.comp.lang.c: 6-Nov-92 To Recurse or NOT to
recurse? Stephen Schow@netcom.com (577)

> What is better to do when traversing a linked list..... SHould I use
> recursion to search down through the list for the last node, or should I
use a while loop?  What or the pro's and con's of each?

Some compilers are really smart, and they will turn your code into (if
it is tail recursion) into a while loop.  Others won't.  If it doesn't,
are you wasting space?  Yes.  How much?  Well, you're using O(N) space
when it can be done in O(1) space.  That's a lot as far as I'm
concerned.  And speed?  Bit trickier, and dependent on the machine you
use, but I'd lay odds on the while loop, say 10:1, that it'd be faster.

-rick


Newsgroups: comp.lang.c,comp.software-eng
From: Duane Murphy <damurphy@wc.novell.com>
Subject: Re: Will we keep ignoring this productivity issue?
X-Xxdate: Fri, 13 Nov 92 21:14:20 GMT
Organization: Novell, Inc.
X-Useragent: Nuntius v1.1.1d12
Date: Fri, 13 Nov 1992 21:10:18 GMT

In article Ralph Johnson writes:
>People have studied how good programmers work, and what they have
>found indicates (to me, at least) that the way we teach people design
>is faulty.  We usually teach people design by teaching them a design
>method that consists of a set of notations, usually graphical, and a
>set of rules that tell how and when to use each notation, how to link
>notations, problems that occur in a design and how to fix them, and
>how to evaluate designs expressed in these notations.  But good
>designers also depend on a large body of more domain specific
>knowledge about design, including algorithms, data structures, and
>design idioms.  This domain specific knowledge is just as important as
>the notations for recording design and the rules for using those
notations.

... Even more (good) stuff deleted.

I have not been following this discussion very long, but you have brought 
up a point that I have been noticing for a while.  My background is 
originally in Electronic Engineering (that's right the hardware that all 
of you use on a daily basis).  My interest in hardware was only slightly 
more powerful than my interest in software.  So I actually did a little 
(a lot) of both.  

Throughout my experience I have repeatedly noticed parallels between the 
two areas.  This is not unusual, they are both engineering problem 
solving based studies.  However, I seem to draw more from my training in 
hardware as I write software.  Hardware design is much older than 
software design (and to a limited extent easier), but the way it is 
taught is far more structured than software.

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!

Just one man's humble opinion,
Duane
Newsgroups: comp.lang.c
From: misar@rbg.informatik.th-darmstadt.de (walter misar)
Subject: Re: >>>> * Get keypress * <<<<
Date: Mon, 9 Nov 1992 09:51:47 GMT
Organization: TU Darmstadt

In article <1992Nov7.154748.24501@alf.uib.no>, singg@alf.uib.no (Kurt George Gjerde) writes:
>    How do I read a keypress (char) without having the user to 
>    press Return??
> 
>    System = Unix V.
> 
Hm, set the terminal to raw mode, on HP-UX it will look like this:

#include <sgtty.h>
...
{ char buf[1];
  struct sgttyb *ttyio;

  gtty(0,ttyio);
  (ttyio->sg_flags)|=(RAW); 
  stty(0,ttyio);
  ...
  read(0,buf,1);	/* read one char, don't wait for return */
  ...
}

Walter
From: bbrown@willamette.edu (Brian Brown)
Newsgroups: comp.lang.c
Subject: LZW Compression algorithm
Date: 12 Nov 92 19:17:22 GMT
Organization: Willamette University, Salem OR

Does anybody have any information on how to implement LZW
compression/decompression?  (The data compression technique used in GIF's.)

Code is fine, but well-described algorithm would be better.  I have some
information on it, but I do not know how to implement LZW compression and
expect to actually come out with properly compressed data.

Any help would be greatly appreciated!!

-- 
----------------------------------------------------------------------------
bbrown@willamette.edu  (Brian W. Brown, Hailing from Salem, Oregon)
Remember:  57% of the voters in the United States voted AGAINST Bill Clinton
----------------------------------------------------------------------------
Newsgroups: comp.lang.c
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Sizeof('\n')?
Date: Thu, 05 Nov 1992 17:36:51 GMT
Organization: Security APL, Inc.

In article <1992Oct30.110753.5055@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>frank@Cookie.secapl.com (Frank Adams) writes:
>>There is one case where changing the mode may be necessary: if you want to
>>read stdio in binary mode.  I have written utility functions which do this
>>(depending on what other arguments are present).
>
>I, too, used to struggle with reading and writing binary stdin/stdout
>but I gave up in disgust in the end, since [...] I couldn't e.g. force
>stdin/stdout to binary mode all the time, and when I could it depended
>on the input, so I had to read potentially a lot from stdin before I
>could make a decision, and buffer it so that I could re-process it
>appropriately.
>
>(Well, actually I solved my problem by switching operating systems.  I
>was trying to write [...] for MS-DOS [...])

I wrote the above-mentioned functions for MS-DOS using Borland's products
(Turbo C/Borland C++), and had no such problems.
Newsgroups: comp.lang.c
From: singg@alf.uib.no (Kurt George Gjerde)
Subject: >>>> * Get keypress * <<<<
Organization: University of Bergen, Norway
Date: Sat, 7 Nov 92 15:47:48 GMT

   How do I read a keypress (char) without having the user to 
   press Return??

   System = Unix V.

Kurt.

Newsgroups: comp.lang.c
From: champion@cch.coventry.ac.uk (Alun)
Subject: Re: Rounding floats to integers
Organization: Coventry University, Coventry, UK.
Date: Thu, 12 Nov 1992 15:30:29 GMT

In article <BxK7xK.7Ap@sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes:
~In <BxJx0s.6q8@cck.coventry.ac.uk> champion@cch.coventry.ac.uk (Alun) asks:
~
~>int round(float n)
~>{
~>    if(n < 0)
~>        return (int)(n - 0.5);    
~>    return (int)(n + 0.5);     // Doesn't the function do the cast automatically
~>}
~
~In C the fact that the function is declared to return an int makes the casts
~redundant.  I don't know about C++ (or whatever language it is that you use).
~Go and ask in the relevant group, if you really want to know.  Or look it up
~in a book.

This *is* C my apologies for the misleading comment.
The comment should of been.

/* Doesn't the function do the cast automatically ?? */

You answered my question anyway.

Cheers

    -Alun
    
-- 
A.Champion                |  That's an interesting point, in the sense of
(champion@uk.ac.cov.cck)  |    being very not interesting at all. - The Liar
Newsgroups: comp.lang.c
From: uyeno@subsys.enet.dec.com (Alice Uyeno)
Subject: Re: need to create a jump table 
Reply-To: uyeno@subsys.enet.dec.com (Alice Uyeno)
Organization: Digital Equipment Corporation
Date: Mon, 9 Nov 1992 14:45:50 GMT


I wasn't clear in my original note.

I have two callback tables.  Depending on a certain initialization flag, I use one or the other table, but the module that uses the call back table should not have knowledge of this flag.  This module only has a pointer to a callback table.  Unfortunately, all the routines do not take the same number of arguments.  

I have come to the conclusion that I cannot have a single jump table with functions with variable arguments.  After some discussion, I have decided to go ahead and embed arrays of pointers to functions within a structure.  The call back table pointer would just point to the correct structure.

  For example,

    
      struct CallTbl
       {
           void (* Error)(ulong);
           void (* Validate)(struct foo *);
           int  (* CalcDiff)(struct foo2, usigned int, struct foo *);
              .
              .
              .
        }

       where Table 1 is
             struct CallTbl Table1 = {Mod1_Error, Mod1_Validate, Mod1_CalcDiff,
                                       .......);
       and Table 2 is
             struct CallTbl Table2 = (Mod2_Error, Mod2_Validate, Mod2_CalcDiff,
                                        ......);

  and I use it as follows:

        
         (*(TblPtr->Validate))(&Record);

    where  struct CallTbl * TblPtr  and   struct foo Record


I'll go ahead and do this unless someone has any better ideas.

My other choice was to have to look at this initialization flag whenever a call back had to be made, but then this would violate the fact that the module is not supposed to know the value of the flag.
            
Newsgroups: comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: Hows this for odd
Organization: Sequoia Peripherals, Inc.
Date: Tue, 10 Nov 92 14:49:22 GMT

In article <BxGq4z.8oA@portal.hq.videocart.com> dfuller@portal.hq.videocart.com (Dave Fuller) writes:
>bena@yoyo.cc.monash.edu.au (Ben Aveling) writes:
>: 	... ,(i==0)?TRUE:FALSE,...
>: Am I going mad, or is this slightly redundant ?
>
>Not at all. Depends on what TRUE & FALSE are, and what they mean to the
>calling function. possible that TRUE is defined as -1, FALSE as -2. 

I think using anything other that 0 for FALSE and 1 for TRUE is
confusing. After all, I would hope that 1 < 3 yields TRUE. And
for this reason, I never use TRUE and FALSE in my code; 1 and
0 are quite clear enough. Besides any nonzero value is TRUE and
using #defines for TRUE and FALSE is going to lead *somebody*
to do something like:

   if (isdigit (x) == TRUE)

which while not a valid use of isdigit and TRUE, sure looks 
tempting.

That being said, I don't see anything wrong with the original
code. I have been known to write things like:

   (i == 0) ? 1 : 0

because even though we all know that boolean expresions are just ints
and they always have the value 0 or 1, I prefer the mental model of
booleans being either true or false --- I don't like to use the fact
that i == 0 is numerically 0 or 1. I've always thought that expressions 
like:

   (i == 0) + (x < y)

where abusing the language.



-- 
Dave Eisen                               Sequoia Peripherals: (415) 967-5644
dkeisen@leland.Stanford.EDU              Home:                (415) 321-5154
       There's something in my library to offend everybody. 
          --- Washington Coalition Against Censorship
Newsgroups: comp.lang.c
From: rhorn@csws8.ic.sunysb.edu (Robert Horn)
Subject: Re: Reasons for using C vs. Fortran or vice/versa
Organization: State University of New York at Stony Brook
Distribution: usa
Date: Fri, 13 Nov 1992 04:32:50 GMT

rons@hardy.u.washington.edu (Ronald Schoenberg) writes:
>  Fortran arrays are column echelon for a
>reason, and C arrays are row echelon slowing down matrix operations
>relative to Fortran.     

Wouldn't FORTRAN arrays actually be slower? consider the normal

  for(index = 0; index < kRows; index++) {
    for(jndex = 0; jndex < kColumns; jndex++) {
      myArray[index][jndex] ...
    }
  }

one normally accesses matrices in a row major fashion (index changes less
often than jndex), so if your array is stored row major, and your cache is
nice enough to bring in the words around what you need (since you may well
access these as well), the time to access each element should be slightly
faster with row major than column major (if you access like above (as does
nearly everyone)). Also, the compiler can compute myArray[index] at the top of
the loop and use an offset from that to compute the location of the jndexth
element. psuedo-assembly code might look like...

  lea        myArray,a2
  ;; asm for index for loop
  ;; asm for jndex for loop
  ;; assuming ints to be 2 bytes long
  move.w     2*jndex(a2),d0             ;; access myArray[index][jndex]
  ;; end jndex for loop
  add.l       #2*kColumns,a2
  ;; end index for loop

I've always heard that column major matrices were one of the stupidest aspects
of FORTRAN.


-- 
rhorn@ic.sunysb.edu         Never choose a college because it has a duckpond.
$@`                                             Send me hate mail, I love it.
Newsgroups: comp.lang.c
From: jth@infodyn.com (Jabba The Hutt)
Subject: Re: Forking and defunct processes
Keywords: fork, defunct
Organization: Information Dynamics, Saratoga, CA, USA
Date: Mon, 2 Nov 1992 22:38:21 GMT

In article <1992Oct31.162537.20305@tc.cornell.edu> reed@TC.Cornell.EDU writes:
>Netters:
>	I recently noticed a rather nasty problem with some code I wrote...
>Well, it appears that my child processes are not properly shutting down and
>leave "defunct" processes lying around.

Perhaps you have already crossed this bridge, but do you periodically
call wait() or wait3()?  If not, stick in a call or two and see if it
gets better.

jth@infodyn.com
Xref: sparky comp.lang.c:16103 comp.unix.programmer:5195