HDTenEightyP/NetNews huggingface dataset:
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: SWITCH Statement Question
Date: 17 Dec 92 22:17:38 GMT
Distribution: na
Organization: McGill Research Centre for Intelligent Machines

> Distribution: usa

Sigh.  I'm going to have to play with some scripts and complain to our
newsfeeds about their passing us bogus distributions...

In article <1992Dec15.122456.1776@hellgate.utah.edu>, u-mwong%peruvian.cs.utah.edu@cs.utah.edu (Michael Wong) writes:

> I have a question regarding the SWITCH statement in C.  I'm having
> conflicting answers from people at work and need some help.  How does
> the SWITCH statement process the CASE statements?  It's not clear to
> me how it works internally.

It varies, depending on machine, system, compiler, the sparsity of the
labels, and possibly other factors such as optimization tradeoff
options specified at compile time.

> Will using a SWITCH statement run faster if it had few CASE
> statements and IF statements were used to aid in the processing than
> using a SWITCH statement that had a very long list of CASE
> statements[?]

Maybe.  It depends on machine, system, compiler, the sparsity of the
labels, and possibly other factors such as optimization tradeoff
options specified at compile time.

A good compiler, told to optimize for speed, should make this
transformation automatically if it would speed up the resulting code
without changing the semantics.

> I'm worried about speed, but I also want to keep the code easy to
> understand.

Then write it whatever way is clearest.  If the time cost of the switch
turns out to be significant (not "is thought to perhaps maybe be
significant"), and the compiler you're using doesn't make simple
transformations that would speed it up, then (a) start looking for a
better compiler and (b) put in some sort of system-specific conditional
compilation in the meantime.

> I'd appreciate if someone could tell me exactly how SWITCH works
> internally!

Go read your compiler documentation, or failing that source, or failing
that go ask your compiler vendor.  If you want to know about some
specific example, look at the generated code, but be careful not to
jump to conclusions.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: ericwebb@blackwlf.gwinnett.com (eric webb)
Newsgroups: comp.lang.c
Subject: Inline ASM in Quick C/ MS C 5.1
Date: Thu, 17 Dec 92 16:41:33 EST
Reply-To: ericwebb@blackwlf.gwinnett.com (eric webb)
Organization: BlackWolf's Den (404)642-9933 v.32bis v.42bis 12/24/96/14.4

Hi...  Does anyone know if one can do inline ASM in Quick C?  How does 
one do it?  I have version 1.01, but tell me about it even if it's for a 
different version..   Can you do it with MS C 5.1?  I also have a copy of 
it, and if neccessary to do inline ASM, can use it.
 
Tks!!!

Eric Webb

ericwebb@blackwlf.gwinnett.com


---------------------------------------------------------
  From Eric Webb:  ericwebb@blackwlf.gwinnett.com
     * Party Hard, Life's Short... *
          Feel the shockwave? - TSR
---------------------------------------------------------
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 23:37:16 GMT

In <fjeske.0knf@amiganet.chi.il.us> fjeske@amiganet.chi.il.us (Felix Jeske) writes:

>>     int i = 2;
>>      i = ++i;
>>   What should the value of i be?
>>
>>>3.
>>
>>BZZZT.

>Double BZZZT!

Triple BZZZT!  [I normally find that kind of thing quite rude, but
I'll play when dealing with someone who has that kind of mindset.]

>The following:

>        i=++i;

>should be broken up like when taking operator precedence into account:

>        ++i;
>        i=i;

Look in the ANSI Standard.  Show me where the sequence point is that
lets you do the increment operator to 'i' first.  Note that '=' is NOT
a sequence point.

>i is incremented (changing it's value to 3) and then is assigned to itself (a
>no-op) so i=3 in the end.

Where have you BEEN for the periodic discussions of this one, son?  A
bit late in the year for incoming Freshmen, isn't it?

>>
>>       x = ++i;
>>
>>means that x is assigned the incremented value of i and
>>i is incremented, it in no way requires an ordering of
>>these two operations.

>Yes it does, the precedence of the = and prefix ++ operators defines the order
>of these operations quite clearly.  Since a prefixed ++ has a higher precedence
>(cf. K&R) than =, it (the ++) is performed first and the statement should be
>broken up as follows:

>        ++i;
>        x=i;

>No ambiguity whatsoever.

Wrong all the way.  See the ANSI C Standard.  Side effects are not
evaluated based on precedence.  Increment and decrement operators have
side effects.  Side effects are only guaranteed to have occurred after
a sequence point.  The assignment operation is not a sequence point.
Therefore, you have multiple references to 'i' in an expression
involving side effects with no sequence point between the references.

Can you say 'undefined behaviour'?

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
From: d_north@ondec.lonestar.org (David G. North, CCP)
Newsgroups: comp.lang.c
Subject: Re: Why does this produce a Divide Error?
Date: 8 Dec 92 14:21:11 GMT
Organization: onDEC systems, Dallas, TX

In article <92342.093824WILLARD@MAINE.MAINE.EDU>,
  WILLARD@MAINE.MAINE.EDU writes:
> I am using TurboC on a Gateway 2000, 486 DX2/50
> The following code will produce a Divide Error every other run!
> When I run it in Debug Mode I don't seem to get the divide error.
> Any Thoughts?
[...]
> 	clock_t start, end;
[...]
> 	start = clock();
[...]
> 	end = clock();
[...]
> (20000)/(end-start)/CLK_TCK);
Dunno 'zactly what clock() does, but I suspect it returns the current 'ticks'
of the 18ms timer... if so, your code may complete within 1 tick thus giving
the same end & start values.  That should produce a nice divide by zero error.
Try printing out start & end first, *then* do the divide and/or simply check
for that condition in the code.  If you need higher resolution timing... guess
what?  You'll probably have to pork around with the timer, multiply the
interrupt rate, then divide back down & pass off only 1/n ticks on to DOS.
Also, if that turns out to be the case, you may want to move your question
to the MSDOS groups instead of C.

Hope this helps.
-- 
David G. North, CCP
d_north@ondec.lonestar.org {...!texsun!montagar!ondec!d_north}
onDEC systems                                 "Everyone's crazy but you & me...
P.O.Box 795848, Dallas TX  75379-5848          and come to think about it, I'm
(214)985-1316 ... (214)902-3957                not so sure about you either!"
From: John.Gibney@f386.n632.z3.fidonet.org (John Gibney)
Newsgroups: comp.lang.c
Subject: Re: user input for inter
Date: Sat, 12 Dec 1992 16:50:06

 -=> Quoting Ejh@khonshu.colorado.edu to All <=-

 Ej> From: ejh@khonshu.colorado.edu (Edward J. Hartnett)
 Ej> Organization: CIRES, University of Colorado

[... text deleted ...]

 Ej> One specific C question that I have is what is a good way to read the
 Ej> user input. In FORTRAN I just READ(*,'(a)') whatever, but I hear that
 Ej> I shouldn't use scanf in C. Is that right? What should I use instead?

For simplicity, I tend to use "gets()"...  you can then
process it as a "string"or you can use the functions
"atoi()" and/or "atof()" to turn it into numbers.  The
formatting, et al with "scanf()" is a pain if the input
formats don't EXACTLY match... as well as a common error for
beginning C programmers is to leave out the "&" in "scanf()"
calls.

Hope this is useful...


John  :-)

... The VMS MasterHarper!
___ Blue Wave/QWK v2.10

 * Origin: Eastern Mail Centre [PEP] OZ. +61-3-725-1621 (3:632/386)
Newsgroups: comp.lang.c
From: kjlee@mtu.edu (KONG-JIN  LEE)
Subject: array of file pointer ?
Organization: Michigan Technological University
Date: Wed, 16 Dec 1992 02:17:38 GMT

Does anyone know how to declare an array of file pointer in GCC

I have tried :

FILE *filptr[10];



???? ---> is this ok ?  FILE **filptr;
if (0k)

then ??? ---> filptr = malloc(10*sizeof(FILE));
     ??? ---> *(filptr+10) = fopen(......);
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Calling convention: C vs PASCAL
Date: 12 Dec 1992 18:34:11 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.15

In article <1992Dec12.171137.17577@taumet.com> steve@taumet.com
(Steve Clamage) writes:
>Neither the C nor Pascal language specifications require the parameter
>ordering mentioned, but they are common implementation techniques.

(For that matter, these days it is common to pass the first two-to-six
parameters in registers, except on the 80x86 where the registers are
far too precious to be used this way.)

>C allows a function to be called with more parameters than were declared
>for it.

In ANSI C, this is only true of `, ...' functions, such as printf().
Moreover, these must be declared in advance as such.  This gives IBM PC
C compilers license to use the variant of `return' that adds to the
stack pointer, except when calling or returning from one of these
`special' functions.

In particular, this means that:

	/* incorrect version of `hello world' */
	int main(void) { printf("Hello world\n"); return 0; }

may well malfunction on an IBM PC.  To correct it, you *must* add at
least one of the following two lines:

	#include <stdio.h>
	int printf(char *, ...);

It is then guaranteed to work on any ANSI-conformant hosted system,
including all IBM PC C compilers.  Without the `advance notice' that
printf() is a `special' function, it need not work properly.

Of course, if one happened to go to your nearby mall and buy an IBM PC
C compiler, and it failed to compile and run the incorrect version, one
would be tempted to advise others against buying this particular
compiler---not necessarily believing that it is `wrong' or `buggy', but
perhaps only because one knows just how much old, nonconformant code
exists.  In other words, market forces pretty much guarantee that *your*
IBM PC C compiler by default uses the so-called `slow method' (which,
as Steve pointed out, need not actually be slower: there is no reason
that one *must* clear the stack after every function call).
-- 
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: "peter curran" <peter.curran@canrem.com>
Subject: question to test general
Reply-To: "peter curran" <peter.curran@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 19 Dec 92 09:40:38 EST

dkeisen@leland.Stanford.EDU (Dave Eisen) writes...

...
DE>I can't think of a legitimate reason why you'd want to use x[y] where
DE>x is an integer and y a pointer. And a compiler is certainly capable
DE>of checking types before it replaces x[y] with *(x + y). Or is there
DE>a reason, other than the obvious need for fodder for Obfuscated C
DE>contests, why this construct should be in the language?

The simplest explanation for this is that it was a standard
construct in B, the predecessor of C, and carrying it across to the
new language no doubt helped facilitate the original acceptance of C.

B did not have structs or pointers.  (Originally C did not have
structs either.)  One simulated structures with something like this:

#define FIELD1  0           /* Define the fields.  All are words. */
#define FIELD2  1           /* B had no types.                    */
#define FIELD3  2

(I don't think that was the syntax for a macro, but I don't
remember exactly.)

To allocate a structure, an array of the appropriate size was
declared:

x[3];

Finally, field references were done with expressions such as

FIELD1[x]

Actually, x[FIELD1] would have worked just as well, but the former
syntax became conventional, to emphasize that one was working with
structures, not arrays.

There are several features of C that are carry-overs from B (the
most obvious is the useless keyword "auto") that were no doubt
included to help in porting software, to encourage acceptance of C.
C was a lot more B-like originally, but a lot of the rough edges
that resulted from that have been cleaned up over the years.
A few still remain.

Peter Curran
Usenet: peter.curran@canrem.com     RIME: CRS (#118)
---
  DeLuxe 1.25 #12339  
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.lang.c
From: sgccmch@citec.oz.au (Mark Christopher Hagan)
Subject: Use of insert delete ops in CURSES
Organization: CITEC
Date: Thu, 17 Dec 1992 09:11:23 GMT

I am currently working on a project to view large reports on screen using C
and CURSES.

I seem to have problems with curses trying to use the Insert-Delete functions
of my terminal but can't seem to disable it.

Does anyone know of any Quirks with the "idlok()" function that would
cause it not to work?

NB: Running 4.3 BSD on a PYRAMID MIS.

Thanks. 
Newsgroups: comp.lang.c
From: wieck@jwminhh.hanse.de (Jan Wieck)
Subject: Re: Source for compressor
Organization: Private Site under Mach386
X-Newsreader: Tin 1.1 PL4
Date: Mon, 14 Dec 1992 21:46:48 GMT

peter@stycx.hacktic.nl (Author) writes:
: Help!! Is there somebody out there who happens to have source for a 
: compression program which allows me to archive directories and create 
: self extracting files. 

This must be a very OS-dependent job forever (so this might not be the
correct newsgroup).

The only way, to produce an executable in a portable way, is to create
the archive in constants included in a source and then compiling it.
But at this point, most archives wouldn't be executabel (or able to
get compiled) any longer due to their size.

Look for some compression algorithm, where the decompression part is
so smart that it wouldn't matter, to redistribute a separate decompressor
any time.


Until later, Jan

-- 
# Any language keeps its own misunderstandings; #
# why shouldn't programming languages do?       #
#                                               #
#            wieck@jwminhh.hanse.de (Jan Wieck) #
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Question to test general C knowledge
Date: 11 Dec 92 18:09:39 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1992Dec11.091819.26636@thunder.mcrcim.mcgill.edu>, mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
|> In article <19980@ksr.com>, jfw@ksr.com (John F. Woods) writes:
|> > dmeister@mansci1.UWaterloo.ca (Darren Meister) writes:
|> >> [I]f you could ask someone one question to test if they generally
|> >> understand C what would it be[?]
|> 
|> > "After
|> > 	int i = 2;
|> > 	i = ++i;
|> >  what does i equal?"
|> 
|> > If they answer, do not hire them.
|> 
|> Hm?
|> 
|> "Anything or nothing.  3 seems most probable, with 4 next."
                                                 ^^^^^^^^^^^^

Why? The effect of the "++" is to assign 3 to i. And since the value of
the "++i" expression is 3, the effect of the "=" is to assign 3 to i. 
Under what conditions would any other value be expected? (Other than,
of course, a vindictive compiler that detected violations of the letter
of the law and went out of its way to give you garbage.)


|> 
|> 					der Mouse
|> 
|> 			    mouse@larry.mcrcim.mcgill.edu

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.lang.c
From: bandy@netnews.jhuapl.edu (Mike Bandy)
Subject: Re: Help!!!!!!!!!!!!
Organization: JHU/Applied Physics Laboratory
Date: Mon, 14 Dec 1992 17:58:29 GMT

jcontro@engws10.ic.sunysb.edu () writes:

>Hello--

>I wonder if there is anyone out there who can answer a quick question:

>In a function, I declare a pointer to a structure, say:
>   SOME_STUCT  *Ptr;

>let SOME_STRUCT have a field which contains a Next pointer, etc...

>I pass it to a function, like this :

Since you expect fn to be able to change the value of Ptr, you need to
pass the *address* of Ptr, not it's value.  Think about how to pass an
int by reference, same thing here.  Hence add the '&' as shown.
          v
>fn( ..., &Ptr );

Likewise, you're receiving a pointer to a pointer, hence the additional
'*' as shown.
                                    v
>recieve it like :  fn( SOME_STRUCT **Ptr ) { ...

>The problem is that inside the funciton I create a linked list,
>of which Ptr is the head. I know it does this correctly.

Additionally, you have to add a level of indirectness to all references
to Ptr in your function fn.  So all references change:
	from		to
	----		--
	Ptr->next	(*Ptr)->next

Note that the parens are required above due to the operator precidence.
You can update the head of the list by assigning a new list value to the
caller's Ptr by using the construct:
	*Ptr = new_head;

-- 

	Mike Bandy
	bandy@aplcomm.jhuapl.edu
	Johns Hopkins University / Applied Physics Lab
From: ericwebb@blackwlf.gwinnett.com (eric webb)
Newsgroups: comp.lang.c
Subject: Peek/Poke in C
Date: Thu, 17 Dec 92 16:43:34 EST
Reply-To: ericwebb@blackwlf.gwinnett.com (eric webb)
Organization: BlackWolf's Den (404)642-9933 v.32bis v.42bis 12/24/96/14.4

Hi again.. does anyone know how to do equivalent of BASIC's PEEK & POKE 
statements in C?  My guess is that you need to use a far pointer to the 
type of data (i.e., char, int, etc.), and then stuff the ptr with the seg 
& offset.  How does one do this stuffing?  Does anyone know of any other 
way to do it??  I need to go both ways, esp. POKE.
 
Tks..

Eric Webb

ericwebb@blackwlf.gwinnett.com


---------------------------------------------------------
  From Eric Webb:  ericwebb@blackwlf.gwinnett.com
     * Party Hard, Life's Short... *
          Feel the shockwave? - TSR
---------------------------------------------------------
Newsgroups: comp.lang.c
From: bketcham@stein.u.washington.edu (Benjamin Ketcham)
Subject: Re: WHAT WENT WRONG?
Organization: University of Washington, Seattle
Date: Thu, 17 Dec 1992 17:50:08 GMT

In article <10441.107.uupcb@cutting.hou.tx.us> david.brooks@cutting.hou.tx.us (David Brooks)  writes:
>The following code is intended to compute the factorial of a given
>number. Unfortunately it gives weird results for numbers larger than 12
>or so... Does anyone have an idea why? I tried compiling it under Huge
>memory model and still the same effects.                          ^^^^
 ^^^^^^^^^^^^

AAAAAAAAAAAAGGGHHHHHHH!!!!!!!

>
>#include <stdio.h>
>
>main()
>{
>    double x, y;
>
>    printf("\nEnter number to factorialize:");
>    scanf("%d", &x);
>
>    for(y=x-1;y>1;y--) x*=y;
>
>    printf("\nFactorial= %d\n", x);
>}                        ^^ 

AAAAAAAAAAAAGGGHHHHHHH!!!!!!!

>
>
>Undoubtedly the problem comes from playing with numbers that are too
>big. Is there something obvious that I am overlooking here? Or is there
>some hidden secret for dealing with big numbers that only rocket
>scientists and C gurus are aware of? Any help is appreciated!
>
>   David
>                                                   
>----
>+---------------------------------------------------------------------+
>| The Cutting Edge BBS (cutting.hou.tx.us)    A PCBoard 14.5a system  |
>| Houston, Texas, USA    +1 713 466 1525          running uuPCB       |
>+---------------------------------------------------------------------+


Newsgroups: comp.lang.c
From: Ron Wichers Schreur <ronny@cs.kun.nl>
Subject: Re: Another C palindrome puzzle
Organization: University of Nijmegen
X-Useragent: Nuntius v1.1
Date: Fri, 18 Dec 1992 13:51:04 GMT

Hello,

Manus Hand, manus@evolving.com writes:
>fjh@munta.cs.mu.OZ.AU  (Fergus James Henderson) writes:
>>
>>   Next challenge: Write a palindromic "hello world" program in C without
>>   using comments, #if, or #ifdef.  I think it should be possible.

Yes, this is possible. Hint: you can use #define to eleminate the garbage
you get from reversing C code.

    # define ignore(s)  /* empty string */
    ignore (egabrag si sihT)

>Challenge accepted!  As Henderson did, I assert that new-line characters are
>not significant when determining palindromism (palindromicity?).

In this puzzle, new-line characters are significant. Your solution should
also compile with 'gcc -ansi -pedantic -Wall'.

>Now I suppose I have to come up with the NEXT challenge.  Okaaaayyyy....
>how about a palindromic "Hello world" program, with no comments, #if's,
>#ifdef's, <<<OR #define's!>>>

This looks a real challenge (I don't think there's a solution).


Regards,

Ronny Wichers Schreur
ronny@cs.kun.nl
From: dhunt@infocom.UUCP (David Hunt)
Newsgroups: comp.lang.c
Subject: Re: ZModem source code:  VAX/VMS to DOS possible?!?
Date: 11 Dec 92 23:09:33 GMT
Organization: INFOCOM Public Unix Server, +44 [0] 734 340055
X-Newsreader: TIN [version 1.1 PL7]

Mike Tedder (Mike.Tedder@f181.n363.z1.fidonet.org) wrote:
> I recently received some ZModem source code on a board.  It was for VAX/VMS (U
nix, I presume), and not DOS.  Nowhere have I been able to find such source code
 for DOS, as of an exception, where it was in Turbo Pascal, not C. 

Why is it that Chuck Foresberg won't release any DOS ZModem for C?  

This is not what you are looking for, but maybe this is an insight into 
CAF@omen.UUCP (Chuck A. Foresberg)

You should contact him with a simple question on using his zmodem (sz/rz), 
this product is shareware and one would think that since he expects you to 
pay a per port licence fee, that assistance would be forthcoming, not so.

This guy is the most arogant b*****d I have ever come across, he is not 
very helpful, downright rude, but would like you to send him money (!)

I would hate to see how his Omen Technology Customer Services Department 
Works :-))

Regards
--
dhunt
From: dw3u+@andrew.cmu.edu (Daniel C. Wang)
Newsgroups: comp.lang.c
Subject: Re: a question about if and case
Date: 14 Dec 92 10:08:01 GMT
Article-I.D.: andrew.Mf=CaVW00aw4QDV2dx
Organization: Freshman, MCS general, Carnegie Mellon, Pittsburgh, PA

GM08@DKAUNI2.BITNET (hans friedrich steffani) writes:
> i have something like
> 
> int i;
> 
> if( i == 1 || i == 25 || i == 125 )
>  {
>   /* do something sophisticated */
>  }
> if( i == 2 || i == 30 || i == 244 )
>  {
>   /* do something different */
>  }
> 
> or should i use
> 
> switch( i )
>  {
>   case 1:
>   case 25:
>   case 125:
>   /* do something sophisticated */
>   break;
> 
>   case 2:
>   case 30
>   case 244:
>   /* do something different */
>   break;
> 
>   default:
>   break
>  }
> 
> or is there a third way??
> i need contructions like this very often so i need a GOOD
> solution.
> 
> hans friedrich   steffani@imbaibrs1.bau-verm.uni-karlsruhe
> steffani         gm08@rz.uni-karlsruhe.de
>                  gm08@dkauni2.bitnet

The first way is more readable the second probably marginaly faster
during compile time.  Can't think of a third way off hand that would
be worth mentioning.  I'd stick with readablity over 'speed.'
Newsgroups: comp.lang.c