HDTenEightyP/NetNews huggingface dataset:
From: eaeu209@orion.oac.uci.edu (Rodney G. Ramos)
Subject: **BOOKS TO LEARN C: SUGGESTIONS NEEDED**
Newsgroups: comp.lang.c
Organization: University of California, Irvine
Distribution: usa
Date: 9 Jan 93 09:23:14 GMT
Followup-To: comp.lang.c

I've recently been interested in learning C. Can anyone suggest a good book
to get me started?

I already know Pascal, so it's important that I find a book that does not
assume the reader has no knowledge or experience with programming.

Any suggestions would be much appreciated. I would also like to compile
a list of the responses for future reference for others.

Please e-mail if possible.
Rodney
Newsgroups: comp.lang.c
From: chaplin@keinstr.uucp (Roger Chaplin)
Subject: Re: Looking for a debugger
Organization: Keithley Instruments, Cleveland, Ohio
X-Newsreader: TIN [version 1.1 PL8]
Date: Fri, 8 Jan 1993 13:30:34 GMT

Muhammad Masroor Ali (masroor@human.ai.kyushu-u.ac.jp) wrote:
: Hello all,

: I am looking for a source level debugger for the C programs.
: Right now I can use dbx or dbxtool, but the later needs an
: open window environment, and the former is not that convenient
: to use.

: Could anybody please let me know about a x window based
: source level debugger with convenient user interface (like
: dbxtool)?

Look for ups.  It built with no problem and runs just fine on my
Sparcstation (SunOS 4.1.3).

Here's the first bit of the man page:

----------------------------- begin included text -----------------------------
UPS(1)                   USER COMMANDS                     UPS(1)

NAME
     ups - X11 and SunView based source level C debugger

SYNOPSIS
     ups target [corefile|pid] [[:]srcdir[:srcdir]]  [-a  target-
     args]

DESCRIPTION
     Ups is a graphical source level debugger for the C  program-
     ming  language running under the X11 and SunView window sys-
     tems.  It supports both run time debugging with  breakpoints
     and post-mortem debugging from a core file.  On Suns you can
     attach ups to a running process.  Ups runs in its  own  win-
     dow,  thus  not  interfering  with the target program's I/O.
------------------------------ end included text ------------------------------

-- 
Roger Chaplin / Instruments Division Engineering / "Though I'd been lost now I
chaplin@keinstr.uucp / CI$: 76307,3506          / felt I was found when He
#include <disclaimer.h>                        / looked at me with His
#include "disclaimer.h" /* cover all bases */ / forgiving eyes." - Michael Card
Newsgroups: comp.lang.c
From: jrv@mbunix.mitre.org (Van Zandt)
Subject: Re: Finding the number of days between two dates
Organization: The MITRE Corp., Bedford, Ma.
Date: Tue, 5 Jan 1993 17:29:33 GMT

In article <27537@sybase.sybase.com> venky@sybase.com (Venky) writes:
>In article <1992Dec10.181940.10135@linus.mitre.org> jrv@truth.mitre.org (Van Zandt) writes:
>>In article <1992Dec9.011317.26944@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>>>pjh@cs.tut.fi (Haavisto Petri) writes:
>>>>1. When using mktime(), is it necessary to set all fields of the
>>>>tm-structure to correct values? 
>>>
>>>No.  tm_wday and tm_yday (and tm_isdst?) are computed by mktime based
>>>on the other fields.  In fact, the required fields do not have to be
>>>in their required fields either, mktime normalises them.  
>>
>>The Borland docs claim their mktime() normalizes those values, but
>>it doesn't.  (I'm posting a separate msg on that.)  My "Osborne McGraw-Hill
>>C the Complete Reference" doesn't mention the normalization.  Is it required
>>by the standard?
>>
>>                           - Jim Van Zandt <jrv@mitre.org>
>
>  
>  ANSI Standard requires that tm_wday and tm_yday be computed 
>  based on the other fields in the 'struct tm'. I have seen 
>  that most versions of Unix do not support that, though.
>  
>  The latest HP-UX 9.0 however, has got this fix and works 
>  well. I should know.....
>  Venky

I have posted a program (julcal) to alt.sources which converts between
a struct tm and a Julian day number (number of days since Jan 1, 4713 BC).
Clearly, this solves the days-between-two-dates problem.  It also does
the normalization and calculation of day-of-week and day-of-year (that is,
calculation of tm_wday and tm_yday).  Unlike mktime(), it also works for
dates in the distant past (before 1/1/1970, 1/1/1900, or even 4700 BC, with
user selectable date for transition between Julian and Gregorian calendars.

I wouldn't trust mktime() without testing it first.
The julcal package includes a test program which compares the normalization
and calculation of tm_wday and tm_yday with those found by mktime().
Since I found errors in both Sun and Borland implementations of mktime(),
the test program attempts to show which has the error.  Therefore, you
can use the test program to test your mktime().  I'd be interested in
learning of other implementation bugs, but of course messages to
your customer support people may do you more good :-).

                   - Jim Van Zandt <jrv@mitre.org>

Newsgroups: comp.lang.c
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Subject: Re: Is that ansi ?
Organization: UIUC SCS
Date: Fri, 8 Jan 1993 15:02:20 GMT

In article <1993Jan8.142730.20697@osf.org> daniel@moonshine.osf.org (Daniel Dardailler) writes:

>A compiler is reporting the following warning:

>  "void * and function pointers are not convertible to each other"

>when encountering:

>       void * p = (void *) func ;   /* func of any kind */


I'm afraid it's true, and one of the most serious faults of ANSI C.

Function pointers are orthogonal to everything else.  What you can do
is somehow convert them to an integer type and convert that to 
void * pointer and then go back. The standard itself does not 
guarantee that the conversion will get back the right answer however.
(For those who need a proof, checked with Doug Gwyn, that this can be done:
enclose the function pointer in a struct, write out the struct to a 
file using fwrite, then read back in into a char array of the correct size.
This is guaranteed to work.) Another way is to try and use unions. This
is not absolutely guaranteed to work.

Doug McDonald
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Problem with string processing.
Organization: TauMetric Corporation
Distribution: usa
Date: Fri, 8 Jan 1993 17:47:49 GMT

hartman@ulogic.UUCP (Richard M. Hartman) writes:

>What I was after was the rough equivilent difference between (Intel)

>	MOVSW	src,dst

>and a loop w/ 

>	MOV ax,src 
>	MOV dstax

>(so sue me if my assembly is wrong...)  The thing is that, yes
>each byte does have to get moved, but the one instruction moves
>'em a heck of a lot quicker than the loop of separate instructions.

>... if the CPU "knows" how to do this in microcode, then you don't have to
>waste CPU time loading all those instructions in the loop
>over and over again, you just have to load the data.

This is the CISC vs RISC argument.  For a given machine it is likely
that the single instruction, if available, will execute more quickly
than an equivalent loop of simpler instructions.  The argument arises
in comparing different machines.

If a machine has many instructions and complicated instructions, then
instruction processing is complicated.  All instructions are affected
by the requirement to handle complicated instructions, and simple
instructions take longer than they otherwise would.  The string search
instruction may execute relatively rapidly, but all the simple
instructions execute relatively slowly.  If your entire program
consisted only of searching strings for characters, you might have a
big win.  Real programs do lots of other things too (like what you do
when you find what you were searching for) and the overall performance
may be worse.  Please note:  "MAY be".

A machine with a simple instruction set may be able to execute
individual instructions so rapidly that it outweighs the cost of
needing many more instructions.  Maybe a RISC machine takes a little
longer to locate a character in a string, and maybe not.  Overall
performance on complete programs may be better.

Going back to the single-machine case, the presence of a complicated
instruction doesn't always mean a performance win.  A block-move
instruction may significantly outperform a tight loop to do the move.
But the block-move may require setup and use of special registers,
displacing other parameters.  By the time you do the setup and restore
displaced registers, you may have lost any advantage offered by the
special instructon.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c
From: quan@sol.surv.utas.edu.au (Stephen Quan)
Subject: Re: Unix equivalent to DOS kbhit() function?
Organization: University of Tasmania, Australia.
Date: Wed, 6 Jan 1993 06:26:49 GMT

typhoon@stcon2.kaist.ac.kr (Han Yun-Su) writes:
>I wrote 'kbhit()' function for UNIX.
>It's very simple..

[...rest of C program omitted...]

>  while (c != 'q') {
>    count++;
>    if (kbhit()) {
>      c = getch();
>      mvprintw(1, 0, "%d: \'%c\' is pressed (count: %ld)\n", ++i, c, count);
>      refresh();
>      }
>    }

If your UNIX platform is like ours, I recommend you put a some kind of
delay in your while loop, [or perhaps in the kbhit() function] otherwise
your process may use large amounts of CPU time.  Otherwise not a bad
program for a Life Science Major!
--
Stephen Quan (quan@sol.surv.utas.edu.au)      Tel : 002 202844 (local)
Research Fellow, Computer Scientist,          Fax : 002 240282 (local)
Centre for Spatial Information Systems,       Tel : 61 02 202844
University of Tasmania, Australia.            Fax : 61 02 240282
From: wjmc@unix.brighton.ac.uk (-*_Cuddly_Cactus_*-)
Newsgroups: comp.lang.c
Subject: Re: a ? b : c = d; /* legal ? */
Date: 4 Jan 93 15:10:00 GMT
Organization: University of Brighton, UK

pod@sour.sw.oz.au (Paul O'Donnell) writes:
> In <BzDA4u.459@cdsmn.mn.org> wells@cdsmn.mn.org (Rich Wells) writes:
>
> [ Deleted (correct) discussion that a ? b : c = d; is equivalent to
>   (a ? b : c) = d; and is bogus. ]
>

 Wandering off the thread of discussion a bit but surely the following is
what was intended :

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

:-)
-- 
# Bill Crawford aka *Cuddly_Cactus*  BSc (Hons) Computer Science Year Two #
# JANET wjmc@uk.ac.bton.{unix,vms} | Elsewhere wjmc@{unix,vms}.bton.ac.uk #
#  Any views I express are not necessarily those of Brighton Polytechnic  #
Newsgroups: comp.lang.c
From: tim@unipalm.co.uk (Tim Goodwin)
Subject: Re: realloc (again)
Keywords: Realloc
Organization: Unipalm Ltd., 216 Cambridge Science Park, Cambridge CB4 4WA, UK
Date: Tue, 12 Jan 1993 12:34:18 GMT

scst81@csc.liv.ac.uk (Mr. I. Rowland) writes:

>Following my last communication I developed another smaller program that
>  uses REALLOC in the same way as my other code:

The same broken way, that is.

Michael Davidson (md@sco.COM) and Michael Henning
(michi@ptcburp.ptcbu.oz.au) between them explained that the first
argument to realloc() must be:

EITHER 1) a pointer previously obtained from malloc(), realloc(), or
calloc();

OR 2) the null pointer.

[ You can only rely on case 2 working if your compiler is ANSI
compliant; the following macro may be helpful for older compilers.

    #define REALLOC(p, l) ((p) ? realloc((p), (l)) : malloc(l))
]

It is not meaningful to hand anything else (e.g. an uninitialised
pointer variable) to realloc().  Why do you keep trying to do so?

>                                                                What can
>  to be done to prevent it [a core dump] from happening?

Use realloc() properly.

>  Again this program works on my Atari St using the Lattice C5 compiler.

Only by coincidence, I'm afraid.

Tim.
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Newbie Wants Advice on C-Programming
Date: 5 Jan 93 00:59:05 GMT
Organization: negligable

In article <gglass07.726030598@ursa> gglass07@ursa.calvin.edu (Gideon Glass) writes:
>jimlynch@netcom.com (Jim Lynch) writes:
>>In article <1992Dec24.172333.7339@grebyn.com> malak@grebyn.com (Michael Malak) writes:
>
>[Much deleted]
>
>>>You should always start out with the official books:
>>>
>>>For C, it is _The_C_Programming_Langauge_ 2nd ed. by Kernighan & Ritchie
>>>For C++, it is _The_C++_Programming_Language 2nd ed. by Stroustrup
>
>>No no no no no no no no no no no no. These books are _unreadible_ to a beginner.
>>However, they can be quite valuable as a reference (whenever you get around to
>>learning how to read them...)
>
>It's been my experience that you have things backwards.  I taught myself
>C using K&R2 in about a month.  The only experience I had before that was
>1 semester of Modula-2 and a little BASIC.  I would recommend K&R2 to others
>who have programming experience and who want to learn C.  As they say,
>your mileage may vary.  As for reference, I've only used it occasionally.

That was exactly the point.  Starting from scratch you do NOT want to
attempt to learn language from K&R.  Your 1 semester of Modula-2 probably
emphasized structured (modular?) program design and introduced the
uses of data structures (I am just guessing, but Modula-2 is the direct
successor of Pascal, which was designed to be a language to teach just
those concepts...)

Therefore, you don't quite qualify as a "beginner".  Later on in that
post Jim stated this more clearly -- if you have experience w/ the
concepts, then you may be able to make use of K&R to just learn the
language (that's what I did, comming from Pascal a looong time ago).

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Moderation in all things....		         ....especially moderation.

Xref: sparky comp.lang.c:19502 comp.lang.c++:18902
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: C/C++ Speed
Date: 10 Jan 1993 21:31:31 GMT
Organization: U. C. Berkeley
Distribution: usa
NNTP-Posting-Host: forney.berkeley.edu

In article <1ipsk5INNf5m@aludra.usc.edu> dliao@aludra.usc.edu (David Liao) writes:
>	Two programmers are writing the same program but with different
>languages which are C and C++.  These two programmers are experts in 
>their own programming language.  Hmm... which program will run faster
>than the other?

Unknown.  It depends on design decisions, the quality of the compilers
each programmer uses, how much time is spent tuning the application for
speed, etc.

>	I've heard that the execution speed of C++ tends to be slower
>than C.

Sorry, this is not true.  Almost every C++ compiler either generates C
code or shares a back end with some C compiler.  This means that
equivalent constructs take the same amount of time.  While it is true
that a virtual function call takes slightly more time than a direct
call, it also does more than the direct function call does.  In many
cases, the C++ solution can be faster than the one that the C programmer
would most naturally come up with (because lots of if() and switch()
statements are eliminated).

>  I know that C++ can make the life of programmer easier, but
>I just want to know if the C program will run faster than the C++ program.

There's no reason to think so.

>	I also heard the size of C++ program is generally bigger than C.
>I am a C programmer trying to learn C++.  So, don't blame me if I have 
>created any misconception about C++.

C++ programmers typically tackle larger problems than C programmers;
there is no fundamental reason for C++ programs to be larger, unless
you consider the size of tiny programs.  That is, if you compare the
size of

#include <stdio.h>
int main() { printf("Hello, world\n");}

to

#include <iostream.h>
int main() { cout << "Hello, world\n";}

you are really comparing the size of the printf routine and the size
of the iostream class, and the latter will be a good bit larger.  But
this difference is inconsequential in any program of substantial size,
and once things start getting big the class libraries start saving on
code size if used properly.


--
Joe Buck	jbuck@ohm.berkeley.edu
Xref: sparky comp.lang.c:19496 comp.lang.c++:18889
From: dliao@aludra.usc.edu (David Liao)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: C/C++ Speed
Date: 10 Jan 1993 11:15:17 -0800
Organization: University of Southern California, Los Angeles, CA
Distribution: usa
NNTP-Posting-Host: aludra.usc.edu

	Two programmers are writing the same program but with different
languages which are C and C++.  These two programmers are experts in 
their own programming language.  Hmm... which program will run faster
than the other?

	I've heard that the execution speed of C++ tends to be slower
than C.  I know that C++ can make the life of programmer easier, but
I just want to know if the C program will run faster than the C++ program.

	I also heard the size of C++ program is generally bigger than C.
I am a C programmer trying to learn C++.  So, don't blame me if I have 
created any misconception about C++.


David Liao
dliao@aludra.usc.edu
University of Southern California
	


Newsgroups: comp.lang.c
From: michi@ptcburp.ptcbu.oz.au (Michael Henning)
Subject: Re: use of REALLOC under UNIX system
Organization: Pyramid Technology Corporation
Date: Tue, 12 Jan 1993 06:34:08 GMT

md@sco.COM (Michael Davidson) writes:
>The problem is that clast_str is uninitialised on your first call
>to realloc()

Yes.

>- the only valid thing that you can pass to realloc()
>as it's first argument is the pointer returned from a successful
>call to malloc(), calloc() or realloc(). In other words, you can't
>RE-allocate something that you have never allocated in the first place!

No. Under ANSI C, realloc() can be passed a NULL pointer, in which case
it behaves as if malloc() was called. Initializing clast_str to NULL
will fix the problem, if libc conforms to ANSI C.

							Michi.
-- 
      -m------- Michael Henning                 +61 75 950255
    ---mmm----- Pyramid Technology              +61 75 722475 FAX
  -----mmmmm--- Research Park, Bond University  michi@ptcburp.ptcbu.oz.au
-------mmmmmmm- Gold Coast, Q 4229, AUSTRALIA   uunet!munnari!ptcburp.oz!michi
Newsgroups: comp.lang.c
From: misar@rbg.informatik.th-darmstadt.de (walter misar)
Subject: Re: How to read without echo.
Date: Mon, 4 Jan 1993 17:29:45 GMT
Organization: TH Darmstadt

In article <1i9pi5INN972@taloa.unice.fr>, vyskocil@taloa.unice.fr (Vyskocyl) writes:
> Hi!
> I got a little question, which will certainly be just a 
> piece of cake for such talentuous programmers as you are.
> 
> I only want to read a word on the keyboard without any
> print on the screen. I mean, I want someone to answer
> a question on his keyboard without any echo of what he
> is typing. It will end just after he pressed 'return'.
> ex: do a little program which does perform this :
>  
>  What's the color of a pumpkin ? :
> (now the guy type something but it doesn't appear on
> his screen!)
>  then :
>  True! or False! whether the answer is light-blue or
> not 8-) .

Why do you guys never mention the OS you use ? (sigh)

Ok, let's assume U use Unix:
If the answer were only up to 8 bytes long, you could have
used getpass():
#include <unistd.h>
...
answerstring=getpass("What's the color of a pumpkin ?");
....

But since the answer is longer, you have to use something like this:

#include <sgtty.h>
main()
{ struct sgttyb *ttyio;
  ...
  gtty(0,ttyio);
  (ttyio->sg_flags)&=(~ECHO);	/* echo off	*/
  stty(0,ttyio);   
  ...   /* read without echo */
  (ttyio->sg_flags)|=(ECHO);	/* echo on	*/
  stty(0,ttyio);
  .....
}
  
-- 
Walter Misar                        It is impossible to enjoy idling thoroughly
misar@rbg.informatik.th-darmstadt.de       unless one has plenty of work to do.
Newsgroups: comp.lang.c
From: goudreau@batman.rtp.dg.com (Bob Goudreau)
Subject: Re: Exact-sized types (was Re: Typedefing builtin... thanks.)
Date: Wed, 6 Jan 93 21:46:25 GMT
Organization: Data General Corporation, Research Triangle Park, NC

In article <F9I0BER@math.fu-berlin.de> rene@hamel.uucp (Rene Mueller) writes:
>In article <84931@ut-emx.uucp>, jamshid@ut-emx.uucp (Jamshid Afshar) writes:
>|> 
>|> I don't understand the purpose of the "at-least-N-bits" types.  C
>|> already has those -- char (>=8), short (>=16), int (>=16), and long
>|> (>=32).  What does your extra level of indirection buy you?
>
> You are'nt correct:

Actually, he is.

> int is as long as a single machine word on the machine (on some
> machines this means 12bit), on this machines also a short is 12bit
> long and a long is 24bits long...

Such compilers do not conform to the ISO C language standard, which
mandates the minimum type sizes that he listed above.

----------------------------------------------------------------------
Bob Goudreau			Data General Corporation
goudreau@dg-rtp.dg.com		62 Alexander Drive	
+1 919 248 6231			Research Triangle Park, NC  27709, USA
From: bketcham@stein.u.washington.edu (Benjamin Ketcham)
Newsgroups: comp.lang.c
Subject: Re: adding strings together
Date: 4 Jan 93 21:45:49 GMT
Article-I.D.: shelley.1iab6dINNsq9
Organization: University of Washington, Seattle
NNTP-Posting-Host: stein.u.washington.edu

In article <83017@mavenry.UUCP> nider@mavenry.UUCP writes:
> can't you just add strings together with a +, like:
> 
> string3=string1+string2
>  

Can't you just read the FAQ before posting questions like this?

It's illegal to perform addition on pointers.  Even if it was legal,
the result would not be what you are probably looking for.  *string3
would be garbage.  You would have to use one of the string functions
available, write one yourself, or use structures.

That's one of the things I like about C.  It doesn't let you "just"
add two strings together, without realizing what you are doing.

--ben
Newsgroups: comp.lang.c
From: norlin@prowler.ecn.uoknor.edu (Norman Lin)
Subject: Re: Problem with Turbo-C: calculating with pointers
Date: Thu, 7 Jan 1993 16:05:18 GMT
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA

derijkp@reks.uia.ac.be (Peter De Rijk) writes:

>I am porting a program (working on different platforms such as VAX and DEC) to
>the PC. I am using Turbo C++ v.3.0. I compile using the huge memory model.
>I seem to have tracked down the problem (well, one of the problems.) I don't
>know what to do about it though. Here's a little program to illustrate the
>problem:

>I would expect end - begin to return 71800. However it seems to return 6264.
>This is exactly 64K less.

In the "huge" memory model in Turbo C++, all pointers default to "far"
pointers.  Far pointers, it says in the TC++ manual, should not be used
for pointer arithmetic because they are not segment aligned.  Declare the
pointers to be huge pointers (e.g. char huge *begin, huge *end), and the
math should work, because huge pointers are segment aligned.

In general, if you're doing ANY pointer arithmetic, you should not use far
pointers, and remember, the huge memory model defaults to using far pointers.
You should be aware that using huge pointers incurs slight performance
overhead (due to the necessity of normalization).

Norman Lin
norlin@mailhost.ecn.uoknor.edu
From: bhoughto@sedona.intel.com (Blair P. Houghton)
Newsgroups: comp.lang.c
Subject: Re: NH-- > NH
Date: 10 Jan 1993 23:14:45 GMT
Organization: Intel Corp., Chandler, Arizona
NNTP-Posting-Host: stealth.intel.com

In article <C0JMw6.680@netnews.jhuapl.edu> bandy@netnews.jhuapl.edu (Mike Bandy) writes:
>In article <1993Jan4.140735.11269@wisipc.weizmann.ac.il> fedimit@wisipc.weizmann.ac.il (Dan Nabutovsky) writes:
>
>>   Do you know that the expression NH-- > NH is always true in C ?
>>The reason is that NH-- returns NH before decrementing, and then
>>NH returns NH after decrementing.
>>   Similarly, NH++ < NH--
>
>So what you're saying is that NH > NH.  I don't believe it.  Your 
>compiler (or your logic) has some serious problems.

The order of evaluation of operands in a binary expression
is implementation defined.

Some implementations will get NH-- on the left before
getting NH on the right; some will get NH on the right
before getting NH-- on the left.

In the case of an ANSI conformant implementation, writing
this line of code results in undefined behavior (say
goodbye to your Guccis).

This is in the FAQ; Q 4.1.

				--Blair
				  "I'm in the FAQ, too, but
				   nobody asks me any more..."
Newsgroups: comp.lang.c