HDTenEightyP/NetNews huggingface dataset:
From: dat@thinkage.on.ca (David Adrien Tanguay)
Subject: Re: quick addition using char and shorts....
Organization: Thinkage, Ltd.
Date: Mon, 14 Dec 1992 18:28:03 GMT

scs@adam.mit.edu (Steve Summit) writes:
>Certainly, though, this is an example of a classic space/time
>tradeoff: if you care more about speed, store the size for which
>computation is most efficient; but if you care more about space,
>prepare to sacrifice some time spent doing conversions.

But be careful: the space saved by using the smaller size may be exceeded
by the space required by the extra instructions needed to do the conversions!
-- 
David Tanguay       dat@Thinkage.on.ca  dat@Thinkage.com  uunet!thinkage!dat
Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.lang.c
Subject: Re: Question to test general C knowledge
Date: 13 Dec 92 19:19:08 GMT

In article <1992Dec13.045828.1714@crd.ge.com>, volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe) writes:
> You miss the point. One of them will happen first. Does the second
> one constitute a modification? Look at it this way: When the "++" operator
> is evaluated, the machine throws a card up in the air with the words
> "put 3 in i" on it. That's the side effect associated with the "++" operator.

The specifications in the C Standard give the machine the right to use a
card that says "increment i" instead, which is where the indeterminancy
and thus undefinedness come from.

> A clearer example illustrating the issue I raise would be the following:
>     i = (i = 4)

That's a more interesting question.  My interpretation is that "modify"
is used in the standard in a generic sense of "replacing the current
value".  In this sense, "i = 4" modifies i, even if the current value of
i happens to be 4, because it's storing a "different" 4 into it.  So, I
would still call it undefined.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
I've got more brains than I know what to do with. -- Calvin
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: definition of strncpy stupid?
Date: 15 Dec 92 03:18:27 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1992Dec9.191804.3455@rti.rti.org>, jbs@rti.rti.org writes:
> Look, the whole point of the complaint is that it's *inconvenient* to have
> to write code to add a null to the target of strncpy() after 9 out of 10
> calls to it

If you find yourself doing that, the answer is that you are abusing strncpy.
If you want a substring function, write one.  strncpy is not and never has
been that function.  memcpy() is the appropriate library function to start
from.

> Most of us have. It's just that it seems really odd that every
> other package I've seen that deals with strings has a substr() function
> that copies N characters from the source to the target, and the result is a
> string that you can use in all the rest of the string functions.  Why
> doesn't C have one?

It has.  It's called sprintf().  The equivalent of
	(string-append
	    "foo"
	    (substring Bar 2 3)
	    "ugh"
	    (substring Zap 1 4)
	    "ooy")
in C would be
	sprintf(result, "foo%.*sugh%.*sooy", 3-2, Bar+2, 4-1, Zap+1);

If you can't stand that,  try

/* substr.h */
#include <stddef.h>
extern char *substr(char *, const char *, size_t, size_t);

/* substr.c */

#include <assert.h>
#include <string.h>
#include <substr.h>

char *substr(char *dst, const char *src, size_t offset, size_t length)
    {
	assert(offset + length <= strlen(src));
	memcpy(dst, src+offset, length);
	dst[length] = '\0';
	return dst;
    }

/*  A different approach would say that we want
    length .TAKE offset .DROP src.  For that we'd write
*/
char *substr(char *dst, const char *src, size_t offset, size_t length)
    {
	size_t srclen = strlen(src);

	if (offset > srclen) offset = srclen;
	if (length > srclen-offset) length = srclen-offset;
	memcpy(dst, src+offset, length);
	dst[length] = '\0';
	return dst;
    }

/* End of substr.h */
From: jhurwitz@access.digex.com (j. hurwitz)
Newsgroups: comp.lang.c
Subject: More File read problems. Help I'm new and confused...
Date: 15 Dec 1992 18:49:21 GMT
Organization: Express Access Online Communications, Greenbelt, MD USA
Distribution: all
NNTP-Posting-Host: access.digex.com
Keywords: case file help duh problems pain in the ass

Moving along on my syntax checking program, I have run into another dead end.
When I run this code, It seems that my problem is that once the program finds
a case and exits from the statement. it returns to the same point in the file
that it left from. What could I do to get the program to read through the 
file, then when it reaches a case to test, throws a swicth and reads without
checking for '{' or '}', then when it encounters matching case, continues on 
with the read after reading through that protion of the file and testing for 
'{}'s.

-------------------------- cut here -------------------------

//programm to read a C source file and verify # of left to right braces
#include <stdio.h>

int main(int argc, char *argv[])
{
   FILE *fptr;
   int l=0, r=0, b=0, j=0;
   char ch;

   fptr  = fopen("chkbrac.c","r");

   while ((ch =getc(fptr)) !=EOF)
	 {
	 j=0;
	 switch (ch)
	   {
	   case '{': b++;
		            break;
	   case '}': b--; 
		            break;
	   case '/*': while(j==0)
			    { (ch=getc(fptr)); if (ch='*/') j=1; }
			    break;
	   case '\'': while(j==0)
			    { (ch=getc(fptr)); if (ch='\'') j=1; }
			    break;
	   case '\"': while(j==0)
			    { (ch=getc(fptr)); if (ch='\"') j=1; }
			    break;
	   }                     /* Junk to test program */
	 }                       /* { {{{ '}' "}..."*/
   if (b==0)
	printf("\nBraces match !!!\n");
   else printf("\nBraces do not match\n");
   fclose(fptr);
}

--------------------- end --------------------------

Thanx to all the people who replyed to my prevous message. 
Newsgroups: comp.lang.c
From: carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer)
Subject: Re: Question to test general C knowledge
Organization: Dept. Engineering Computer Resources, Melbourne Uni.
Date: Sat, 12 Dec 1992 03:44:33 GMT

In article <1992Dec11.214128.1136@nb.rockwell.com> wade@nb.rockwell.com (Wade Guthrie) writes:
>
>One question that I particularly like, although few applicants ever get it, is:
>
>what does:
>
> printf("shop"+1); 

prints hop to stdout, assuming you've included stdio.h

-- 
 Annal  Natrach, Usthvah Spethed,         carl@ecr.mu.oz.au (IRC: Bleve)
 Dochoel Dienve                           carl@munagin.ee.mu.oz.au
					  carl@montebello.ecom.unimelb.EDU.AU
 Merlin, where are you?  Call your dragon, to weave a mist...
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: longjumping out of a signal handler
Date: 12 Dec 92 22:41:47 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <1992Dec11.120446.28991@cs.utwente.nl>, ahoekstr@cs.utwente.nl (Andre D. Hoekstra) writes:

> But if your implementation of signal handlers blocks overrun signals
> by setting a flag on entry in your signal handler, and clearing it on
> exit, you may get stuck with a masked signal, by not exiting from the
> handler.  (longjump prevents exit/return obviously).

Every implementation I know of that blocks signals during handler
execution also takes care to unblock signals correctly when longjmping
out of a handler.  Would anyone care to give an example of a system
that doesn't do this?

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: ayoung@vax.oxford.ac.uk
Newsgroups: comp.lang.c
Subject: Re: High resolution timing?
Date: 13 Dec 92 00:04:41 GMT
Organization: Oxford University VAX 6620

In article <RDORICH.92Nov30220930@jade.tufts.edu>, rdorich@jade.tufts.edu (Rob) writes:
> Ok, what you might want is clock().  It will return you the number of
> CPU time (in microseconds) used  since the _FIRST_ clock() in that
> program.  I actually just found about it today :)  I think it's kind
> of a pain that it always gives you the time since the first clock().

 Please read the manual again before implementing this bit of advice. The time
returned by clock() is NOT usually in microseconds - my VAX system uses units
of 10 miliseconds, whereas some of my PCs use units of 1/18.2 seconds!  You
need to look up the compiler-specific #definition CLOCKS_PER_SEC which will
tell you the unit that clock() returns.

-------------------------------------------------------------------------------
     ___
    /   \   /                 |    /      Alan Young @ uk.ac.ox.vax
   /____/  /  ___    __       |___/
  /    /  /  /   |  /  |         /           "The bigger they are,
 /     \_/\__\__/|_/  /_________/               the harder they fall on you."
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Question to test general C knowledge
Organization: Texas Instruments Inc
Date: Fri, 18 Dec 1992 18:18:06 GMT

In <BzGoGn.A93@cck.coventry.ac.uk> champion@cch.coventry.ac.uk (Alun) writes:

>In article <1992Dec18.093717.7661@jussieu.fr> fred@trot.ibp.fr (Frederic PETROT) writes:
>~d_north@ondec.lonestar.org (David G. North, CCP) writes:
>~>Or better yet, what is the type and value of the following expression:
>~>  "this is a test"[4]
>~
>~try this one (due to a friend of mine):
>~
>~main()
>~{
>~   printf("%c", unix["abc"]);
>~}
>~

>Why does this print 'b' ??
>I could understand the indexing with numbers but with [unix] ??

I would suspect that thec compiler in question does a '#define unix 1'
to indicate to itself (and programs) that it is in a UNIX environment.
So what you're really doing is indexing the [1] element of the  string
"abc", which gets you the character 'b'.

>Please help a confused individual.

>I consider myself competent with the C and find it difficult to understand
>why anyone would ask these type of questions in an interview - surely these
>don't show someones level of competence.

I consider such quizes to be a waste of time in general, and quizes
over 'tricks' to be even more worthless.

[I've always considered myself competent, but certainly no guru; yet I
can answer pretty much all of these.  See what reading comp.lang.c and
the FAQ for a long time will do for you?  Or should that be 'to you'?
;-)] 

-- 
"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
From: rfries@sceng.ub.com (Robert Fries)
Subject: Re: Question to test general C knowledge
Organization: Ungermann Bass
Date: Thu, 17 Dec 1992 16:57:34 GMT

In article <1992Dec16.231449.22903@cs.uow.edu.au> davidr@cs.uow.edu.au (David Ian Raymond) writes:

>d_north@ondec.lonestar.org (David G. North, CCP) writes:

>>Or better yet, what is the type and value of the following expression:
>>  "this is a test"[4]

>I give up. What is it?

The value is ' '. 
An even more bizarre way of writing it is:
	4["this is a test"]

Yes, it works, and yes, this is another example of the useless things
you can learn by reading news articles.

Robert

//////////////////////////////////////////////////////////////////////////
Robert Fries
Ungermann-Bass Inc.

DISCLAIMER:
    Opinions contained herein are my own, and are not necessarily those
    of Ungermann-Bass.
//////////////////////////////////////////////////////////////////////////
From: h8915726@hkuxb.hku.hk (Medusa)
Subject: Re: Variable argument list question
Reply-To: h8915726@hkuxa.hku.hk
Organization: University of Hong Kong
X-Newsreader: Tin 1.1 PL4
Date: Thu, 17 Dec 1992 14:18:11 GMT

bjornw@colargol.edb.tih.no (Bjoern Wennberg) writes:
: Hi!
: 
: I am trying to make a function that 
: 	1. Has an variable argument list
: 	2. Manipulates the arguments that the argument list points to
: 
: 
: Here is an example which illustrates the problem:
: 
: int main(void)
: {
:   char *flag;
:   func(flag);
:   /* flag == "test" */
: }
: 
: void func(...)
	^^^^^^^^
	I'm not sure if it's gonna work, in PC, args should initially
	point to the last _fixed_ argument. If there is not fixed argument,
	I don't know. In fact, probably you may want to pass how many
	parameters in the variable argument list.

	e.g. func (int n, ...)
	
	Otherwise, you never know when to stop. (Or you give a extra NULL as
	terminating signal).

: {
:   va_list args;
:   va_start(args, "%s");
:   
:   va_arg(args, char *);
:   
:   /* allocate space for 'flag' by using 'args' */
:   /* manipulate 'flag' by using 'args' */
:   
:   /* *args = new char[10];  doesn't work*/
:   /* args = new char[10];  doesn't work*/
:   /* memcpy() / strcpy() and friends doesn't work */
: 
:   /* 
:    * debugger show me that 'args' points to the same address as 'flag'
:    * does. But I cannot insert anything inside this address.
:    */
:   va_end(args);
: }
: 
: Any comments are welcome.
: 
: bjornw>
: --
: bjornw@edb.tih.no     Bjoern Wennberg     Trondheim College of Engeneering
: 


	You can also try, directly, if you have:

	func (int n, ...)

	double	*f;

	f = &n;

	and then manipulate f...(but I think it's not very safe).

	Any comment welcome.


--
Medusa
University of Hong Kong
H8915726@hkuxa.hku.hk
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: Problems with Case statements HELP!
Keywords: case help lost c not
Date: 17 Dec 92 22:05:16 GMT
Distribution: na
Organization: McGill Research Centre for Intelligent Machines

> Distribution: usa

Hm, someone is leaking usa distribution outside the USA....

In article <Bz18KA.MCv@access.digex.com>, jhurwitz@access.digex.com (j. hurwitz) writes:

> Okay, I'm new to C so you'll have to forgive my lame question.
> Anyhoot, I'm trying to write a program that will check for balanced
> braces in my C source code.  I have no problem when I do this:

> //programm to read a C source file and verify # of left to right braces
>    while ((ch =getc(fptr)) !=EOF)      //gets chars

This program may read C code, but it's not written in C; those double
slashes are syntax errors in C.  You'd probably be better off asking in
a group appropriate for whatever language it is written in.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Xref: sparky comp.lang.c:18478 gnu.gcc.help:2759
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.lang.c,gnu.gcc.help
Subject: Re: How precise is preprocessor math? (I'm using gcc)
Date: 16 Dec 92 18:54:00 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <EJH.92Dec15111402@khonshu.colorado.edu>, ejh@khonshu.colorado.edu (Edward J. Hartnett) writes:
|> 
|> Hi! I had some calculations in my program to arrive at a constant that
|> I need to map some latitudes and longitudes to an i j grid. I was
|> wondering if I could use a #define and save my cpu the task of
|> repeatedly calculating this. Here's the code in which it is computed
|> both with a #define and in the code:

You misunderstand how the preprocessor works. A "#define" causes textual
substitution that takes place long before expressions are parsed and 
evaluated, even when the expressions are evaluated at compile time.

|> 
|>   double q, x, y, rho, Rg;
|> #define Q1 2.*6371.0/GRIDSPACE_KM*(1.+sin(70.))

Q1 is not being defined as the value of that expression, it's being
defined as the expression itself.

|>   Rg = 6371.0/GRIDSPACE_KM; 
|>   q = 2.*Rg*(1.+sin(70.));
|>   printf("Q1=%g  q=%g\n",Q1,q);

This simply expands to:
     printf("Q1=%g q=%q\n", 2.*6371.0/GRIDSPACE_KM*(1.+sin(70.)), q);

And then the compiler evaluates it, or more likely, just the
constant expression part of it. (It probably isn't likely that it
evaluates sin(70) at compile time, but it's allowed to.) Both expressions
are being evaluated at the same translation (or execution) phases. 
The fact that you use a "#define" doesn't cause any more of that expression
evaluation to be evaluated at compile time.

|> 
|> and the result of the printf:
|> Q1=113.015  q=113.015
|> 
|> So it seems I can do this in define. I was suprised. My question is,
|> to what precision is this calculation done? I looked around in the
|> preprocessor info file but couldn't turn up anything that seemed to
|> bear on this question. Any help appreciated.
|> --
|> 	Don't blame me, I voted against Amendment 2!
|> 
|> Edward Hartnett				ejh@khonshu.colorado.edu

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.lang.c,comp.lang.c++,comp.misc
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: What is Object Oriented Programming? Is C doomed?
Date: 14 Dec 92 21:57:26 GMT
Organization: Microsoft Corporation

In article <eskoVB2w165w@quest.UUCP> srhqla!quest!kdq writes:
|    This is the heart of the matter:  OOP is another device which
|helps mediocre programmers to produce good code.  Good programmers can
|also make use of it, but they've *always* produced good code.

Mediocre programmers write functional code in whatever language
they use.  On the contrary OOP is a device for needing fewer mediocre 
programmers, cranking out the same old bug-laden code time and time again.

Xref: sparky comp.lang.c:18591 comp.lang.pascal:7557
From: ray@philmtl.philips.ca (Ray Dunn)
Newsgroups: comp.lang.c,comp.lang.pascal
Subject: Shape fitting
Date: 18 Dec 92 04:29:48 GMT
Organization: Not Philips.

There doesn't seem to be an appropriate newsgroup to ask general algorithm
questions so please excuse this here (didn't I see some talk about
comp.algorithms in news.groups a few months ago?)

Can someone point me in the direction of a good reference for algorithms to
fit shapes - I came up dry in a scan of the local univ library index.

My application is a simple one, to fit rectangles optimally inside another
rectangle, but I'm also interested in general solutions.

Thanks for the help.
-- 
Ray Dunn at home        |  Beaconsfield, Quebec  |  Phone: (514) 630 3749
ray@philmtl.philips.ca  |  ray@cam.org           |  uunet!sobeco!philmtl!ray
From: robert@isgtec.com (Robert Osborne)
Newsgroups: comp.lang.c
Subject: Re: How to test a programmer
Date: 18 Dec 92 15:20:23 GMT
X-Newsreader: TIN [version 1.1 PL8]

Jarmo Raiha (jarmo@ksvltd.fi) wrote:
: I believe that testing a C programmer's abilities by asking some
: nitpicking details is wrong. Totally wrong!

I agree.  Most programmers don't need to know the language in this
kind of detail.   I'd be more concerned that they understand the
basics of the language,  structures, pointers, strings, arrays,
etc.,  and knew how to use them.   Getting the person to write a couple
of simple routines should be more than enough to show C competence.

Then get on with the real test:  does the person understand programming.

: I'm also beginning to think that especially programmers with a knowledge of
: compiler techniques will be lousy programmers. They tend to use
: too much shortcuts.

I've been told that my code is very clean,  easy to understand, and
simple to extend or modify.   I'm also the 'C' expert here at ISG.

Of course I came by my knowledge by porting more than 300,000 lines
of code to 11 different compilers on 10 different architectures.

You should watch your generalizations.

Rob.
--
Robert A. Osborne   ...!uunet.ca!isgtec!robert or robert@isgtec.com
From: Ty.Roden@f2112.n363.z1.fidonet.org (Ty Roden)
Newsgroups: comp.lang.c
Subject: Zmodem source
Date: Thu, 17 Dec 92 00:57:00 PDT
Organization: FidoNet node 1:363/2112

 > Hello.  I lost your message in a HD crash, but I was able to
 > read part of it. You said something about you knew where I
 > could get 'C' source for Zmodem? And as a trade, I would give
 > you the VAX/VMS version?  Am I correct?  Thanks.

Although I may be able to get the 'C' source for you... you must be thinking of someone else. I have no use for VAX/VMS stuff at all...

-Ty

--  
        Ty Roden  -  via FidoNet Node: 1:363/42
             UUCP:  -  ...tarpit!tous!business!2112!Ty.Roden
             ARPA:  -  Ty.Roden@f2112.n363.z1.fidonet.org
Xref: sparky comp.lang.c:18349 comp.lang.c++:17946 comp.misc:4592
From: dak@kaa.informatik.rwth-aachen.de (David Kastrup)
Newsgroups: comp.lang.c,comp.lang.c++,comp.misc
Subject: Re: What is Object Oriented Programming? Is C doomed?
Date: 14 Dec 92 22:43:46 GMT
Organization: Rechnerbetrieb Informatik - RWTH Aachen
NNTP-Posting-Host: kaa.informatik.rwth-aachen.de

bs@alice.att.com (Bjarne Stroustrup) writes:

>Sigh. No that is not the case at all. OO techniques and the tools and
>languages that support them help all programmers. The programmers who
>have the best grasp of the principles and their practical application
>get the most help. In practice, this means that the best programmers
>get the most out of OOP (just as they have out of every other effective
>technique over the years); they are the ones who have the best understanding
>of their applications and of the technique available to build them.
>Mediocre and poor programmers also get significant help, but that is
>neither the primary aim of OOP nor its main effect. OOP is not a technique
>for dumming down programming or deskilling programmers.
> _

I tend not to agree. Mediocre programmer can make a mess of any source
code, once they start maintaining it. OO is a way that makes it possible
for good programmers to write source that mediocre programmers can
use WITHOUT messing it up.

I have already had nicely modularized, well commented code "extended"
into tattering shreds (finally the extensions worked, alright) by
somebody taking up work on my basis. This was (also) caused by
a complete lack of trying to understand the documentation tool used
in the project (Cweb) and annoyed hell out of me.

OO programming gives you the possibility to create sealed classes
which won't be touched and messed up in such a way, leaving open
the possibility of switching to a newer version without having to
try to join the messes.
Newsgroups: comp.lang.c
From: silvia@rcf.rsmas.miami.edu
Subject: graphics.h
Reply-To: silvia@rcf.rsmas.miami.edu
Organization: RSMAS
Date: Sat, 19 Dec 92 16:27:31 GMT

I am trying to run a program which inits routines in graphics.h, but at link it gives me errors of undefined symbol such as circle. It is included like so #include<graphics.h>. Any help would be appreciated.


         Manolo
Newsgroups: comp.lang.c
From: behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens)
Subject: Re: Peek/Poke in C
Organization: Technische Universitaet Muenchen, Germany
Date: Fri, 18 Dec 1992 11:59:35 GMT

>ericwebb@blackwlf.gwinnett.com (eric webb) writes:
>>Hi again.. does anyone know how to do equivalent of BASIC's PEEK & POKE
>>statements in C?

Very implentation-specific. Some architectures allow something along
the lines of

char *address;

address = 0x678090;
*address = 80; /* poke $678090,80 */
printf ("And peek gives us: %d\n",*address);

This will, of course, only work on those architectures where a pointer
actually contains a physical address, which is a rare case anyway.

My advice: Stay away from PEEK and POKE. If you absolutely have to do
it, at least put it in its own source file and comment it heavily.

Soenke
-- 
===========================================================================
More than silver, more than gold, I need   !    behrenss@informatik.
electricity. I need it for my dreams.      !    tu-muenchen.de
(RACTER)                                   !  FIDO: 2:246/13 Soenke Behrens