HDTenEightyP/NetNews huggingface dataset:
From: troyf@microware.com (Troy Frericks)
Subject: Re: How to test a programmer
Organization: Microware Systems Corp., Des Moines, Iowa
Date: Thu, 17 Dec 1992 22:03:30 GMT

This is getting old!  There is more to being a programmer
than, as others have pointed out, C trivia.  Why not simply
check references, and ask for a sample of the person's
code.  If somebody has a BSCS from a school that uses 
C, that's another plus.

You should also find out if this person can work as part
of a team, if he/she can read and write, if their social
skills are ok (did they wash their hair this month?), can
they communicate, will they fit in with your organization.

-
Troy Frericks                      Internet: troyf@MICROWARE.COM
Microware Systems Corporation          UUCP: uunet!mcrware!troyf
1900 NW 114th St                      Phone: (515)224-1929
Des Moines, IA 50325-7077               Fax: (515)224-1352
Newsgroups: comp.lang.c
From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Subject: Re: Question to test general C knowledge
Organization: Department of Chemistry, University of Toronto
Date: Sat, 12 Dec 1992 22:09:02 GMT

In article <1992Dec11.180939.20726@crd.ge.com> volpe@ausable.crd.ge.com writes:
>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:
>|> > "After
>|> > 	int i = 2;
>|> > 	i = ++i;
>|> >  what does i equal?"
>|> 
>|> "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.)

     Or how about a modern compiler with all the optimizations turned
on?  If the compiler doesn't actually catch this as an error, it's not
hard to imagine that instruction rearrangement on a pipelined architecture
might produce highly unexpected results.  (Any number between 2 and 4
seems equally likely to me.)  Have you ever looked at the assembly
language generated by a RISC compiler?  Some of it is truly twisted.

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca
From: rick.joseph@filebank.cts.com (Rick Joseph) 
Newsgroups: comp.lang.c
Subject: Purchasing C
Date: 13 Dec 92 12:38:00 GMT
Distribution: world
Organization: The File Bank BBS - Fallbrook, CA  619-728-4318
Reply-To: rick.joseph@filebank.cts.com (Rick Joseph) 

To: gjkirk@napier.uwaterloo.ca

|I am looking at possibly purchasing a C compiler.
|I would like something that has a debugger and a
|decent library, but that does not cost hundreds
|of dollars.

I've been using Microsoft Quick C for about two years now and I
really like it - but it may not have everything you're looking
for.  It doesn't have Windows support, or mouse support (although
I think you can get it for an extra $50).  It's got a very good
debugging interface and quite a few compile options.

I'd recommend it as a good place to start.  That's why I bought
it originally (intending all along to upgrage to something more
powerful - but I haven't yet felt compelled to go out and get
anything else).

BTW - our board just recently got an internet gateway.  I'd be
most grateful if you'd send back a short reply just so I know
this stuff is working.  Thanks!

rick.joseph@filebank.cts.com

                                                                                                                          
Newsgroups: comp.lang.c
From: eager@eagercon.com (Michael J. Eager)
Subject: Re: Dynamic Linked Libraries
Reply-To: eager@eagercon.com
Organization: Eager Consulting
Date: Sun, 13 Dec 1992 01:18:46 GMT

In article 5833@unix.brighton.ac.uk, ipj@unix.brighton.ac.uk ((( Fleg Software ))) writes:
>Would anybody care to explain the concept of a dynamic linked library?

Care to offer the name of the operating system you are interested in?  Or
would a description of DLLs on SVR4 help you with your MS Windows system?


---
Michael J. Eager		Michael.Eager@eagercon.com
Eager Consulting		(415) 325-8077 
1960 Park Boulevard, Palo Alto, CA 94306-1141
From: tom@smart.bo.open.de (Thomas Neumann)
Newsgroups: comp.lang.c
Subject: Re: a ? b : c = d; /* legal ? */
Date: 20 Dec 1992 14:06:18 GMT
Organization: News at smart
NNTP-Posting-Host: smart.bo.open.de
X-Newsreader: Emacs 18.59.1, GNUS 3.14.1
In-reply-to: wells@cdsmn.mn.org's message of Wed, 16 Dec 1992 19:29:17 GMT

>>>>> Regarding a ? b : c = d; /* legal ? */; wells@cdsmn.mn.org (Rich Wells) adds:

  wells> Is the statement:

  wells>     a ? b : c = d;

  wells> where a, b, c, and d are all integers, a valid C expression?

You can do it like this

  int a, b, c, d;
  *(a ? &b : &c) = d;

to force the lhs to be an lvalue.

  wells> So that I don't have to go out and buy an asbestos suit, I
  wells> want to make it very clear that I would never even consider
  wells> writing code like this. 

Why not ? It's a nice shortcut in some situations, and nobody with
some knowledge of C should have problems reading the code.

bye  -- Thomas
Newsgroups: comp.lang.c
From: stuartj@esg.mentor.com (Stuart John)
Subject: Re: Getting input from the keyboard
Date: Wed, 16 Dec 1992 11:26:20 GMT
Reply-To: stuartj@esg.mentor.com
Organization: Mentor Graphics Corporation
Keywords: 
Followup-To: 

In article <pal.724501355@regent.e-technik.tu-muenchen.de>, pal@regent.e-technik.tu-muenchen.dbp.de (Peter Loibl) writes:
|> paulk@garfield.cs.mun.ca (Paul E. King) writes:
|> 
|> [stuff deleted]
|> 
|> >I want to know how C  can obtain input from the keyboard directly,
|> >without my having to type a carriage return. I know that the vi editor 
|> >works on this principle (that is what I am using now). 
|> 
|> [stuff deleted]
|> 
|> >I am using a UNIX-based System V Berekley C compiler.
|> 
|> [stuff deleted]
|> 
|> Hi!
|> 
|> getc(FILE *stream) reads one single character from a certain stream.
|> Streams are: open files, stdin and stderr (stdout is also one, but
|> this makes little sense here).
|> 
|> You should try getc(stdin).
|> 
|> More details are on the manual pages.
|> 
|> Peter Loibl
|> pal@regent.e-technik.tu-muenchen.de

I was trying to do this at uni last year, and in the end i had to use
a couple of curses structures to turn 'cooked' mode into 'raw' mode
on the terminal, so it didn't buffer input lines.
-- 
  _
 ( `/_
(_)(_(/                  stuartj@esg.mentor.com
Mentor Graphics Corporation, BRACKNELL, England

#include<std.disclaimer>
Newsgroups: comp.lang.c
From: ies@access.mbnet.mb.ca (Integrated Engineering Software)
Subject: Problems freeing memory using "free"
Keywords: malloc,free,panic.
Organization: University of Manitoba, Winnipeg, Canada
Date: Fri, 18 Dec 1992 21:03:46 GMT


Hi ,
    My question is:
    When is dynamically allotted memory using c(m)alloc freed after
     calling "free"?

    Using os_view() on a SGI, I am able to monitor the RAM available
     before a call to c(m)alloc and after a call to free(). The OS
     indicates that the dynamic memory has been allotted from the
     available RAM(a test problem) and but then does not release the
     allotted memory even after a call to free. After the test program
     is completed and the prompt is back, then the memory is indicated
     as available.

   The available RAM is critical for my app, but future malloc's
   will allot memory from the swap space which I do not want to access.

   Have I misunderstood some concepts here or is there a technique by
   which i can access the RAM after a "free".
   Please forward your responses to support@integrated.mb.ca.

  Girish Bhat







Newsgroups: comp.lang.c
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: TSR sources : request .
Organization: McGill Research Centre for Intelligent Machines
Date: Fri, 18 Dec 92 02:12:41 GMT

In article <1992Dec16.031008.25313@unislc.uucp>, thayne@unislc.uucp (Thayne Forbes) writes:
> Jan Wieck (wieck@jwminhh.hanse.de) wrote:
>> rodnay@chen.bgu.ac.il (guy rodnay) writes:

>>> I would very much apreciate any help on TSR's

Well, it's got little to do with C, but from my AD&D Players Handbook
cover:

	TSR Hobbies, Inc.
	POB 756
	LAKE GENEVA, WI 53147

This is probably out of date, though, as the logo accompanying it is
different from the logo I've seen in ads recently.

Seriously, *please* keep the OS- and machine-specific stuff in the OS-
and machine-specific groups.  You'll get better information and you
won't clutter up c.l.c with stuff that doesn't belong here.

>> So, where is the Problem? And if there is anyone, it isn't a
>> C-problem!!!

> Of course any smart-ass who recognizes the acronym TSR knows that Guy
> was refering to DOS.

Then what was it doing posted in comp.lang.c, hm?  rec.games.frp seems
more appropriate to me...oh foo, wrong TSR again.  Gotta be careful
with acronyms out of their context...like "TSR" in a non-DOS context.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.c
Subject: Re: Question to test general C knowledge
Date: 18 Dec 92 03:19:35 GMT

:::::    i = ++i;

: From: dsbb@ns1.cc.lehigh.edu (D. SPENCER BEECHER)
: Message-ID: <1992Dec16.180117.72534@ns1.cc.lehigh.edu>
: After reading much discussion on this matter, I have only
: one question:
: On what page of the white book does it indicate precedence in
: evaluation of the above statement?

What's precedence got to do, got to do with it?  What's prescedence
but a syntax-related notion?  What's prescedence got to do, got to
do with it?  Why study parseing when semantic constraints are broken?

: I would compare this to the line:
: putchar(c)=getchar();
: (which, by the way, does NOT work on any but the most forgiving compilers)

It's hard to see how the two illegalities are comparable, other than
that they are both illegal.

But more importantly, which compilers DOES this "work" on (whatever
"work" might mean in this context, which is a puzzle in itself)?  I ask
mainly so that, armed with this information, I can make a mental note
never to use them.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.lang.c
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Subject: Re: Questions about token merging and trigraphs
Organization: UIUC SCS
Date: Thu, 17 Dec 1992 15:53:00 GMT

In article <mcdonald.610@aries.scs.uiuc.edu> mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:


>BECAUSE OF THEM, it is **IMPOSSIBLE** to write code that is both
>K&R I and ANSI!!!


I'll retract that statement. It's not impossible, due to the presence of
octal escapes in strings and/or the possibility of putting spaces
where the offending characters go and then using assignment statements
to fix them. KLUDGE. I should have known better than to say that,
as octal escapes are what I used!

Doug McDonald
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: Thu, 17 Dec 1992 22:26:36 GMT

In <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:

>>In article <Bz0A46.Cvu@watserv1.uwaterloo.ca>,
>>  dmeister@mansci1.UWaterloo.ca (Darren Meister) writes:
>>> this but, if you could ask someone one question to test if they
>>> generally understand C what would it be. Thanks for your responses.
>>After all the recent hubbub under the topic 'what do you say?'
>>How about:
>>  What's the difference between '=' and '=='?
>>:):):)
>>Or better yet, what is the type and value of the following expression:
>>  "this is a test"[4]



>I give up. What is it?

You're kidding, right?

[In case you aren't, it's a character ' ']

-- 
"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: carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer)
Subject: Re: Peek/Poke in C
Organization: Dept. Engineering Computer Resources, Melbourne Uni.
Date: Sat, 19 Dec 1992 01:52:19 GMT

In article <pal.724673747@regent.e-technik.tu-muenchen.de> pal@regent.e-technik.tu-muenchen.dbp.de (Peter Loibl) writes:
>ericwebb@blackwlf.gwinnett.com (eric webb) writes:
>
>>Hi again.. does anyone know how to do equivalent of BASIC's PEEK & POKE
>>statements in C?
>
>I am sorry for my ignorance, but what are PEEK and POKE doing? If you
>describe their task, then this would be lots of help for all the
>"C-Gurus" here.

Peek used to be used to read direct memory addresses, and poke to
put data into a direct memory address.  

it's not portable, and C does not support it  (as far as I know :) )

-- 
 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: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Is this ANSI?
Date: 18 Dec 92 13:18:51 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1992Dec15.204100.4293@thinkage.on.ca>, atbowler@thinkage.on.ca (Alan Bowler) writes:
|> In article <Byr66A.A2A@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
|> >
|> >Huh?  Why should you do this?  What do you gain by doing so?  Would
|> >you care to justify these "rules of thumb"?  (There are some pretty
|> >silly consequences to supposing that a compiler might really *not*
|> >enforce the standard in this respect.  But right now I leave these
|> >as an exercise for the reader.  As it is, the suggestion that one
|> >ought to suppose that the compiler *fails* to implement an explicit
|> >part of the standard is puzzling enough.)
|> >
|> Because at a later time you may want to reorder the structure so that
|> it gives you better performance on a different machine.  If you have
|> done things that depend on the order of objects within the struct,
|> you will find it difficult to locate these dependancies.

I think there's a big difference between the following two dependencies:

1) Having your code depend on the particular order in which you specified
   struct members.

2) Having your code depend on the fact that, whatever order you specified,
   the compiler will generate the same order.

-Chris
-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Testing competence of potential hires
Date: 11 Dec 92 21:32:35 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1g9pm5INNosg@almaak.usc.edu>, ajayshah@almaak.usc.edu (Ajay Shah) writes:
|> 
|>    Write a test program which will tell you whether min is a true function,
|>    or a #define.  You are not allowed to know anything about how your
|>    program is linked; you are only allowed to write this program, and
|>    see it's execution results.
|> 
|> Answer 1:
|>    {
|>         int i, j, s;
|>         i=2; j=4;
|>         s = min((++i), j);
|>         printf("%d\n", s);
|>    }
|> 
|> Answer 2: try compiling
|>    { 
|>         char p,q,s;
|>         s = min(p, q);
|>    }
|> 
|> A1. If it's written as #define min(a,b) a<b?a:b then ++i will get
|> executed twice, giving 4.  Otherwise the min will be 3.

What if it's written as:
#define min(a,b) \
   (__a = a, __b = b, (__a<__b?__a:__b))

where __a and __b are file scope statics declared in min.h??


|> 
|> A2: if this program compiles it's a hash-def, else it's a true function.
|> 

Why? The chars will be promoted to int and the resulting int stored in
a char. There's no reason why this won't compile if it's a function.

My solution:

#include <stdio.h>
#include "min.h"
int main()
{
#ifdef min
  printf("min is a macro\n");
#else
  printf("min is a function\n");
#endif
  return 0;
}



|> 
|> 5. After
|> 	int i = 2;
|> 	i = ++i;
|>    what does i equal?
|> 
|> Answer: Nothing prevents the compiler from interpreting this as:
|> 
|> 	 i = i + 1;
|> 	 ++i;
|> 
|> i.e., there is no reason the compiler can't decide to find what value
|> is to be assigned to the i on the LHS side of the equation and only
|> then look at the right hand side to increment i by 1.

The example may be illegal, but your reasoning is wrong. The "++i" 
attempts to store 3 in i. The value of the "++i" expression is 3, regardless
of when the side effect takes place. Thus, the effect of the "=" is to
attempt to store 3 in i also. Both side effects attempt to store 3 in i.
This may violate the standard, depending on the definition of "modified"
in section 3.3, but I don't see why any reasonable implementation would
not put 3 in i. Note this is different from "i = i++" (postfix), where the
"++" wants to put 3 in i, but the "=" wants to put 2 (the value of the
"i++" expression) in i.

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
From: kdq@quest.UUCP (Kevin D. Quitt)
Newsgroups: comp.lang.c
Subject: Re: Calling convention: C vs PASCAL
Date: Sat, 12 Dec 92 09:27:17 PST
Reply-To: srhqla!quest!kdq
Organization: Job quest  (805) 251-8210,  So Cal: (800) 400-8210

> the C pushs the args from right to left onto 
> the stack when calling a function.
> the PASCAL pushs the args from left to right.
> I was told that the C convention results in
> larger as well as slower program.
> (due to some cleanup work of the stack
> after call??)

    In Pascal, subroutines clean up the stack from the function call.
In C, the calling routine cleans up the stack.  This makes it possible
to call a function with a variable number of parameters, since the
calling routine "knows" how many parameters it pushed.  It does make
things larger, since every call is followed by a pop.  The order of
pushing left-to-right or right-to-left doesn't make any size
difference, but the former does guarantee that you know where the first
parameter is no matter how many items were pushed.

    A quick question to others:  It has always been "common knowledge"
that these two things are at the heart of C (right-to-left pushing and
the caller clearing the stack).  I've read the ANSI standard, but I
couldn't find a mention of these things.  I assume it's got to be
there, but where?


 _
Kevin D. Quitt      96.37% of all statistics are made up.     srhqla!quest!kdq
Newsgroups: comp.lang.c
From: dan@cae.prds.cdx.mot.com (Dan Breslau)
Subject: Re: Question to test general C knowledge
Organization: none
Date: Tue, 15 Dec 1992 18:19:26 GMT

volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe) writes:
>In article <1992Dec14.150401.1283@cae.prds.cdx.mot.com>, dan@cae.prds.cdx.mot.com (Dan Breslau) writes:

>|> No, really, you're missing the point.  The point is that you can't
>|> assume that the compiler will behave rationally just because common sense
>|> says it should.  The compiler will behave rationally _only_ where the
>|> ANSI standard says it should (modulo bugs and/or non-compliance.)
>|>
>|> Dan Breslau
>|> dan@codex.com

>No, you're missing the point. Real compilers don't go out of their way
>to take advantage of undefined behavior and cause trouble.

As someone else has suggested, I'd LOVE to see a compiler which did this --
that is, it caused real, obvious errors when it encountered constructs whose
effect is undefined.  (Of course, a warning message would be much nicer, but:
1) warnings often are ignored, and 2) The compiler may find it much easier
to issue bad code than to issue an accurate warning.)

Real _programmers_ don't go out of their way to take advantage of undefined
behavior and cause trouble.

> In general, this would
>leave the final value indeterminate, but when those two side effects are
>identical, why would one expect a rational compiler to leave anything
>other than the """right""" answer in the variable?

(Pipelining |  Multiple instruction issue |  Register scoreboarding |
Massively parallel processing) + optimizing compilers.

Why would you expect the compiler to issue anything at all?

Dan Breslau
dan@codex.com
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: curses.h dirent.h
Date: 14 Dec 1992 03:09:36 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
Distribution: usa
NNTP-Posting-Host: 128.3.112.15

(Note that dirent.h is a POSIX thing, not a C thing.  Similarly,
discussion about stat() belongs elsewhere.  This correction goes to
comp.lang.c only because the article quoted below was posted there.)

In article <Ef9Yx2i00WB=A3GkIJ@andrew.cmu.edu> Tod McQuillin
<tm8t+@andrew.cmu.edu> writes:
>	  if (statbuf.st_mode & S_IFDIR) /* Is it a directory? */

The `file type' in a stat `st_mode' field is not a set of individual
bits, but rather a number.  This is something like testing the bit
(1<<2) to see if a value equals four: it will give false positives.
The Official POSIX Method is to use S_ISDIR(statbuf.st_mode).  The
Classic Unix method is ((statbuf.st_mode & S_IFMT) == S_IFDIR); the
test quoted above happens to give false positives for block devices
and sockets on traditional Unix boxes.

We now return you to appropriate comp.lang.c material (I hope) :-) .
-- 
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: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Calling convention: C vs PASCAL
Organization: Texas Instruments Inc
Distribution: usa
Date: Mon, 14 Dec 1992 17:51:12 GMT

In <1992Dec11.225756.26780@eng.ufl.edu> zzang@stat.ufl.edu (zzang) writes:

>Hello,
>the C pushs the args from right to left onto 
>the stack when calling a function.
>the PASCAL pushs the args from left to right.
>I was told that the C convention results in
>larger as well as slower program.
>(due to some cleanup work of the stack
>after call??)

The order that things are pushed onto the stack (assuming your machine
has a stack, of course) are irrelevant.  The difference between the
two is who pops them back off when the function call ends.  In C the
caller cleans up the stack on return; in Pascal the callee is assumed
to know how many arguments were put on the stack and can clean up
before it returns.

-- 
"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: schoudhu@ucunix.san.uc.edu (Spandan Choudury)
Subject: header re-definitions (+ Re:character pointer function calls posting)
Organization: University of Cincinnati
Date: Wed, 16 Dec 1992 12:01:37 GMT

  Please ignore that earlier posting on char type pointer function calls.
  A temporary answer has been obtained...

  Actually I had tried all obvious attempts at defining f() 
  including the obvious char *f() {...} but my compiler(s) mentioned
  that as an error, plus the 2 other warnings were there too. So I 
  had deliberately removed specifying the type of f() {knowing that
  the default integer type will be converted to the pointer type} and
  it worked -- however with those warnings. One simple solution is 
  "extern"ally declaring f() as a char* function in addition to defining it 
  as char* at the time of describing it (thanks to the one who hinted on this).

   I was wondering if there was a way of sequentially including header
   fils in a manner that will prevent overriding any definition in any 
   earlier (included ... sequentially speaking) header file.
   (this is just to avoid having to rewrite standard header files,
   with certain definitions from all of which being needed..)


Newsgroups: comp.lang.c