HDTenEightyP/NetNews huggingface dataset:
From: jjwright@remus.rutgers.edu (   Jay)
Newsgroups: comp.lang.c
Subject: linked lists with structs please
Date: 3 Sep 92 16:07:17 GMT
Distribution: ny
Organization: Rutgers Univ., New Brunswick, N.J.



does someone have a handy example of code for utilizing linked lists
in c?  just a few examples on very simple structs would be great,
thanx.

jjwright
From: shafer@CS.ColoState.EDU (spencer shafer)
Newsgroups: comp.lang.c
Subject: True Portability?
Date: 31 Aug 92 14:57:02 GMT
Organization: Colorado State University, Computer Science Department

With 'C's touted portability, is it unreasonable for a user to expect
a vendor to offer "source code compatibility" across multiple hardware
platforms?  In other words, I would like to take the same program and
compile it on different machines and obtain the EXACT same results.
Keep in mind this includes POSIX, any API's for communications stacks
and for process to process communications.  Is it too much to expect?
Could the API's be different - parameter order, encoding, etc.?  Could
the runtime libraries be different?
How can a user require a vondor to provide this? (and then verify it?)

I'm interested in any opinions or experiences.
drlove
-- 
/\__________________________________________________________________/\
||                     SPENCER SHAFER                               ||
|| email:shafer@handel.cs.colostate.edu    Work Phone: 303-498-0901 ||
\/------------------------------------------------------------------\/
From: robertson@physc1.byu.edu
Newsgroups: comp.lang.c
Subject: Re: Novice Questions
Date: 31 Aug 92 15:37:41 GMT
 <1992Aug30.101121.4479@klaava.Helsinki.FI> <1992Aug30.221426.9849@umr.edu> <1992Aug31.070123.23997@klaava.Helsinki.FI>
Organization: Brigham Young University

In article <1992Aug31.070123.23997@klaava.Helsinki.FI>, wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
> Arrays and pointers are nowhere near equivalent.  Superficially they
> might look so, but that is only because arrays usually automatically
> become pointers in C (but sometimes don't).  For more information,
> please read the FAQ of this group, section 2 especially.
> 
> Btw, the person who said that array names are constant pointers might
> want to look at questions 2.6.

  Where is the FAQ?  I have dabled in this group for about 2 weeks
  and I haven't seen it in anyones signature yet.  Thanks.

      jim robertson
Newsgroups: comp.lang.c
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: Giles' Manual Mania (Was
Organization: /etc/organization
Date: Tue, 25 Aug 1992 19:58:19 GMT

In article <396.174.uupcb@ssr.com> dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin)  writes:
>
>Also consider the following two responses:
>        "What's the REAL question?"
>        "What have you tried?" or "What have you considered?"
>

Also  "Why do you want to know?  What are you trying to do?"  This is
a varient of "What's the REAL question?".  I have often regretted
answering the first question asked.
Newsgroups: comp.lang.c
From: pt@geovision.gvc.com (Paul Tomblin)
Subject: Re: New Comer - Please Help !
Keywords: Help NewComer
Reply-To: pt@geovision.gvc.com
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario
Date: Tue, 25 Aug 1992 20:45:45 GMT

Ketan.Deshpande@bbs.oit.unc.edu (Ketan Deshpande) writes:
>In article <1992Aug25.000613.3610@geovision.gvc.com> pt@geovision.gvc.com writes:
>>I would suggest you actually _buy_ TurboC instead of pirating it, and then
>>RTFM.  There is a huge library of functions already there, and FileExists

>I don't see how Doug's letter leads to Paul's statement about _buying_ TurboC.
>Can you help me out?


I made the stupid assumption that people who actually _have_ manuals would
actually _read_ them, before asking the world what was in them.  Silly, I
know, to assume that just because something is right, that people would do
it.

After 8 years on the net, I should know better...

-- 
Paul Tomblin, pt@geovision.gvc.com (Not an official statement of GVSI)
"All rights and all wrongs have long since blown away/For causes are ashes
were children lie slain/Yet the damed UDL and the cruel IRA/Will tomorrow go
murdering again" - Stan Rogers "The House of Orange"
Newsgroups: comp.lang.c
From: fjh@cs.mu.OZ.AU (Fergus Henderson)
Subject: Re: strcpy implementation question
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 27 Aug 1992 17:45:03 GMT

curt@watson.ibm.com (Curt McDowell) writes:

>> The code to implement strcpy() does NOT have to be ansi-conformant - hell,
>> it doesn't even have to be written in C! It IS allowed to read
>> uninitialised memory locations, so long as that doesn't stop it doing its
>> job correctly.
>> 
>> The following function correctly implements strcpy on my machine:
>> 
>> 	#define MINDLESS_USE_OF_UNITIALIZED_MEMORY 
>> 
>> 	char *strcpy(char *dest, const char *src) {
>> 	    char *retval = dest;
>> 
>> 	#ifdef MINDLESS_USE_OF_UNINITIALIZED_MEMORY
>> 	    char unused[4];
>> 	    unused[0] = (unused[1] *= (unused[2] += unused[3]));
>> 	#endif
>> 
>> 	    while (*dest++ = *src++) ;
>> 	    return retval;
>> 	}
>> 
>> It might not work on *your* machine, but that's irrelevant.
>
>It better work on your machine.  "unused" is legally allocated local stack
>space, so of course you can reference it.  Since the initial contents are
>undefined, the result unused[0] is undefined.  Fine.

Well, NOT fine, if you were trying to write strictly conformant ANSI
C code. An ANSI C implementation is well within its rights to dump core
if you reference uninitialised memory - the idea is that some machines may
have a special bit-pattern to represent uninitialised memory, and referencing
this causes a trap.

>> If the compiler can determine that there referencing memory past
>> the end of the string will not cause any side-effects, then it is perfectly
>> entitled to do so.
>
>No compiler can determine this for the general strcpy().

Yes it could!

>A good, portable strcpy MAY NOT access extra bytes before or after the
>source string, just the exact bytes of the string.  That's because the
>memory outside the string may be illegal address space, particularly
>where virtual memory or hardware parity checking is concerned, and you'd
>trap trying to read it.

As I said above, even simply accessing uninitialized memory may cause a trap.

On the other hand, if you are NOT concerned with writing a portable strcpy,
and you (or the compiler) know that accessing memory after the string will
not causes a trap (or any other similar problem) then you are quite
entitled to access that memory. There are machines that have neither
virtual memory nor hardware parity checking, and for which READING memory
NEVER causes any side-effects.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Xref: sparky comp.lang.c:13054 comp.os.msdos.programmer:8925
Newsgroups: comp.lang.c,comp.os.msdos.programmer
Subject: Re: file positioning with buffered/unbuffered I/O
From: dueck@brandonu.ca
Date: 31 Aug 92 15:08:50 CST
Organization: Brandon University, Brandon, Manitoba, Canada

In article <1992Aug25.153322.13793@jhunix.hcf.jhu.edu>, gregg_c@jhunix.hcf.jhu.edu (Christopher H Gregg) writes:
> Hi, I am writing an assembly language program and I am having some
> problems with it.  The program is memory resident and it traps int 1Ch.
> After it traps the interrupt, it checks if a certain amount of time
> has passed and then it deletes a certain file on a directory.  The
> problem is that when I try to use either DOS function 13h (delete file)
> or DOS function 41h (which I would prefer), the program crashes.
> 
You have become stuck on one of the worst problems in DOS: its not
re-entrant. However, you can tell when its safe to call DOS by checking
the DOS-safe flag. This is a one-byte value located one byte past the 
address returned in DS:SI by interrupt 21 function 5D06 and it is zero
when it is safe to call DOS. Unfortunately the flag lies: It is safe to call
DOS if DOS is busy with a call <= 0x0C, mostly standard input and output
calls. However, when DOS is in a keyboard-polling loop, it invokes
interrupt 28, the DOS-idle interrupt.

Your program should acquire its data via int 1C and write it out from a
routine called via int 28.

This solution will break if you have hot-keyed back into a TSR, thereby
activating via int 28. The TSR can't use int 21 subfunction <= 0C, and
int 28 can't be re-entered. Does anyone know the solution to this problem?

Gery Dueck
dueck@brandonu.ca
Newsgroups: comp.lang.c
Subject: pointer to multi D array. How?
From: clin@zeus.calpoly.edu (Chihtsung Jeffrey Lin)
Date: Wed, 26 Aug 1992 05:00:53 GMT
Organization: California Polytechnic State University, San Luis Obispo

Hello,

Can someone help me with this? I just started programming in C, I've been
programming in ADA for a while. How do you declare a pointer to a
multi-dimensional array? here is what I did.

int A[5][5]:={1,2,3,......}, **x;

x=A;

here is the error I get from Meta C compiler:

|    Type "int[5][5]" is not assignment compatible with type "int**".

I thought a M-D array IS a pointer to pointers. If not, how can I make a
pointer point to that array? The only reason I want to use a pointer is so
that I can change the array's values inside functions. God I hate C (just my
opinion :).

Thanks.

Jeff :)
Newsgroups: comp.lang.c
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Giles' Manual Mania (Was - Re: About the 'F' in RTFM)
Organization: Los Alamos National Laboratory
Date: Thu, 27 Aug 1992 00:37:46 GMT

In article <1992Aug26.210446.13402@mksol.dseg.ti.com>, mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
|> In <1992Aug25.161037.29594@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
|> 
|> >In article <1992Aug13.175711.27749@mksol.dseg.ti.com>, mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
|> >|> [...]
|> >|> Find another job, Jim.  One that lets you use something nice and
|> >|> simple like MS-DOS.
|> 
|> >This is an example of UNIX-speak.  This comment is frequently encountered,
|> 
|> No, Jim.  This is an example of how to speak to someone who is without
|> a clue and whining about that state.

Oh, so your intent was not to commit a logical fallacy (an appeal to an
irrelevant alternative), but to make an ad-hominem attack.  The latter
hurts your credibility more than the former.

-- 
J. Giles
Newsgroups: comp.lang.c
From: cee1@ra.msstate.edu (Charles Evans)
Subject: main()
Organization: Mississippi State University
Date: Wed, 2 Sep 1992 06:43:02 GMT

Ok, I thought supposadly in ANSI C/C++ one was to declare main() as such:
either:

int main(void)
 or
void main(void)

BC++ books say int main(void) but what is the benefit of 'return 0' at the
end.. seems like wasted space.

Now in VERY new C++ books or VERY new C books, they usually have either

int main()
or void main()

so what is wrong with 'main()' .. ANSI i suppose

so what should i use

void main(void) looks best (to me)?

any htoughts?
'

-- 
+--------------------+-----------------------+------------------------+
|  Charles E. Evans  |  cee1@ra.msstate.edu  |  All things are green  |
|    iDLE CHATTEr    |  cee1@MSSTATE.BITNET  |  unless they are not.  |
+--------------------+-----------------------+------------------------+
Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: Why should POINTERS be so damn hard to understand ?
Date: Sun, 30 Aug 1992 19:07:37 GMT
Organization: D'Arcy Cain Consulting

chas@castle.ed.ac.uk (C Spencer) writes:
>Why does a pointer need to know what it's pointing to? Surely it's just
>an address - if there was only one kind of pointer, there wouldn't be so
>much to learn, and be confused by.

If you want assembler you know where to find it.

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |
Newsgroups: comp.lang.c
Subject: Re: MS-C fread bug
From: a_rubin@dsg4.dse.beckman.com (Arthur Rubin)
Date: 3 Sep 92 20:04:22 GMT

In <1992Sep3.141100.28778@wuecl.wustl.edu> drm4005@wuee1.wustl.edu (David Russell Maffitt) writes:

>Here is a simple piece of code that does not work under MS-C versions 6.0 or
>7.0.  WHY?  Just save the file as main.c and compile with "cl main.c".

>What is magic about the value 70.689651???  This works fine if I change
>the value slightly (70.689600 works but 70.689650 does not).  Is this a
>horrible bug or do I have more brain damage than I realize??
>I'd appreciate a sanity check.  I'd like to hear how this runs on similar
>and different hardware with the Microsoft compiler.  

>----- start file main.c --------------------------------------------------
>#include <stdio.h>

>#define MAGIC   70.689651

(rest of code ommitted)

MAGIC has a byte which has the value 0x1A, which is processed as an end of
file by MS-DOS.  If you open fp2 in mode "rb" instead of "r", there is no
problem.
--
Arthur L. Rubin: a_rubin@dsg4.dse.beckman.com (work) Beckman Instruments/Brea
216-5888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal)
My opinions are my own, and do not represent those of my employer.
My interaction with our news system is unstable; please mail anything important.
Newsgroups: comp.lang.c
From: daavid@bohra.cpg.oz.au (Daavid Turnbull)
Newsgroups: comp.lang.c
Subject: Re: Why should POINTERS be so damn hard to understand ?
Date: 28 Aug 92 12:00:10 GMT
Organization: Computer Power Software

In article <25233@castle.ed.ac.uk> chas@castle.ed.ac.uk (C Spencer) writes:
>
> Why does a pointer need to know what it's pointing to? Surely it's just
> an address - if there was only one kind of pointer, there wouldn't be so
> much to learn, and be confused by.
++ptr;	/* yields a different result if :- */

char *ptr;	/* as opposed to :- */

struct humungous *ptr;
>

.... so what  happens when you do 

void *ptr;

++ptr;	/* ? */
-- 
	Daavid Turnbull
	daavid@bohra.cpg.oz   +61 3 823 0222    (fax) +61 3 824 8068
	uunet!munnari!bohra.cpg.oz!daavid
	CP Software Export Pty Ltd                   ACN 006 640 133
Newsgroups: comp.lang.c
From: gml@ositech.fi (Mikael Lonnroth)
Subject: Re: Question about code in Kernighan and Ritchie book
Organization: Ositech Oy
Date: Mon, 24 Aug 1992 00:40:55 GMT

In article <66653@hydra.gatech.EDU> gt5870c@prism.gatech.EDU (Noah White) writes:

>do not appear to work, when I run them it takes in the input fine but doesn't
>print anything out. As I am new to c I thought one of you net guru's could
>help me out:
.
.
.
>	while ((c = getchar()) != EOF)  {
.
.
.
>        printf("%d %d %d\n", nl, nw, nc);

The program does not exit from the while loop before you type an EOF on
your keyboard (MSDOS ^Z, UNIX ^D). Maybe that is the problem?
--
gml@ositech.fi
Georg M. Lnnroth
Espoo, Finland
Newsgroups: comp.lang.c
From: mcastle@mcs213e.cs.umr.edu (Michael R Castle)
Subject: Re: How to link in .BGI files? (TC++ v1.0)
Date: Wed, 2 Sep 1992 20:23:30 GMT
Organization: University of Missouri - Rolla

In article <1992Sep2.161847.19590@cs.umb.edu> cteague@ra.cs.umb.edu (Charles F. Teague II) writes:
>It's no help to me, though.  I've ransacked all four manuals I got with
>TC++ v1.0 (Getting Started,User's Guide,Prog. Guide, + Lib. Ref.), and all
>I've found said that I have to have the bgi files in the current directory.

Programmer's Guide, p.233

Happy reading.
mrc
From: shaouyw@cse.fau.edu (William Shaouy)
Newsgroups: comp.lang.c
Subject: Integer-to-Character-Conversion
Date: 31 Aug 92 16:03:58 GMT
Distribution: USA
Organization: Florida Atlantic University, Boca Raton, FL, USA

I am looking for a function that converts an integer to a string of characters,
e.g converts integer 100 to character string "100". I know that stdlib.h has
a function called atoi that does the reverse of this, but I can't find what
I'm looking for.

My email address is "shaouyw@sol.cse.fau.edu"

Thanks,
Bill Shaouy
Xref: sparky comp.lang.c:13244 comp.sys.sun.misc:4102
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: How to randomly access files in C?
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 1 Sep 1992 01:46:59 GMT

emarkp@ocf.berkeley.edu (E. Mark Ping) writes:

>  The subject line pretty much says it all.  Basically, I'm reading a file
>with fgets, and I want to be able to 'go back' a few lines if a certain
>condition is true.

Some files (eg. stdin) may not be seekable, in which case you would probably
have to store the last few lines in memory. However for most files,
ftell() and fseek() should do what you want (RTFM ;-).

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: pjh@mccc.edu (Pete Holsberg)
Newsgroups: comp.lang.c
Subject: Re: Why should POINTERS be so damn hard to understand ?
Date: 28 Aug 92 16:37:24 GMT
Organization: The College On The Other Side Of Route One

In article <1992Aug27.135946.6622@infonode.ingr.com> henders@infonode.ingr.com (Greg Henderson) writes:
=Well one reason that pops to mind is the nice ability to use a pointer 
=to traverse an array more efficently than the 'normal' way.  For ex...
=
=You could do this normally:
={
=    int a[1000], i; 
=
=    for ( i=0; i<1000; i++ )
=	a[i] = get_some_arbitrary_value();
=}
=
=Or you could do this w/ a pointer:
={
=    int a[1000], *_i;
=
=    for (_i=a;  _i<a+1000; _i++ )
=	*_i = get_some_arbitrary_value();
=}
=
=These two pieces of code do the exact same thing, but if you are 
=worried about low-level efficiency the second version is a little
=tighter, as each reference to the array value in the pointer version
=requires less work to come up w/ that address.

Isn't that a function of the compiler? In fact, let me ask why don't we
have compilers that produce the most efficient code even when array
notation is used? Is it that they would be too slow? I recall a FORTRAN
compiler for a 16-bit digital computer used in a hybrid computer system
back in the 60s that produced wonderful code, but took a very very long
time to do it.
From: ted.jensen@spacebbs.com (Ted Jensen)
Newsgroups: comp.lang.c
Subject: Re: Pointer/address
Date: 28 Aug 92 14:36:00 GMT
Reply-To: ted.jensen@spacebbs.com (Ted Jensen)
Distribution: na
Organization: SPACE BBS - Menlo Park, CA - 10 Lines + 4gB - 415-323-4193



steve@taumet.com (Steve Clamage) writes (in answer to my article)

TJ>Thus I think that by virtue of the fact that we have two
TJ>different words for describing the a variable type (pointer) and
TJ>the contents stored in such a variable type (address) a
TJ>description of what is actually taking place when using pointers
TJ>_can_, in a sense, be made clearer than when using integers or
TJ>floats.

> Finally, a pointer variable need not contain a machine address.
> It might contain more than an address, as on capability
> architectures, or less than an address, as on some segmented
> architectures, or something which only describes an address, as
> when part of the pointer is an index into a table of segments or
> addresses.

Finally!  I have posted my reasons for preferring the use of
"address" over "pointer" in certain contexts many times on
various BBS's.  I have often received criticism based on the fact
that virtually no author (including of course the ANSI standard,
K&R1, and K&R2) was in agreement with me.  That, in itself, would
not make my usage incorrect IMHO.  None of the books I have ever
seen have been explicit about why their phrasing was preferred or
even correct.  However, here, finally, you have clearly and
explicitly stated why my usage of "address" was incorrect.

I bow to your more reasonable explanation and thank you for
pointing out my error.

Ted Jensen
---
 * SLMR 2.0 *
Newsgroups: comp.lang.c
Subject: Re: Password encryption?
From: pgut1@cs.aukuni.ac.nz (Peter Gutmann)
Date: Fri, 4 Sep 1992 07:32:01 GMT
Organization: Computer Science Dept. University of Auckland
Keywords: password, encryption

In <18574tINNoh@darkstar.UCSC.EDU> noesis@ucscb.UCSC.EDU (95016000) writes:

>In article <julian.715516516@sun-1> julian@sun-1.cs.uct.ac.za (Julian Hansen) writes:
>>Hi world,
>>
>>I need to do some password encryption and maybe data encryption to. Anyone
>>out there like to help me. Some code would be nice and maybe a few pointers
>>on what not to do (and what to do). Any help would be most appreciated.
>>
>here's what i use with some success:

>long encrypt(char *s)
>{
>  long result=1;
>  char *ptr;

>  srand(0x1234);
>  for (ptr=s; *ptr; ptr++)
>    result+=(*ptr)*rand();
>  return result;
>}

Don't rely on this for security.  What you're doing is xor-ing your data
stream with a LCRNG (linear congruential random number generator).  These are
quite easy to break, for example the paper "How to Predict Congruential
Generators" presented at Crypto '89 gives much information on this (plus a lot
of references to other papers).  This approach is enough to keep the plebs
out, but won't withstand any real attack.  If you want to perform password
encryption you really should use a one-way hash function such as MD5, Snefru,
or the NIST SHA (by an amazing coincidence :-) I posted SHA source code to
sci.crypt about 15 minutes ago, you could grab that and use it).

Peter.
--
     pgut1@cs.aukuni.ac.nz || peterg@kcbbs.gen.nz || peter@nacjack.gen.nz
		  (Email is currently not terribly reliable)
Xref: sparky comp.lang.c:13024 comp.unix.questions:10571
From: markd@werple.pub.uu.oz.au (Mark Delany)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: cursor input on curses (new prob.)
Date: 30 Aug 92 02:58:18 GMT
Organization: werple public-access UNIX, Melbourne
NNTP-Posting-Host: localhost.pub.uu.oz.au

atmtjkv@vax.oxford.ac.uk writes:

>In article <1992Aug25.220112.1@hamp.hampshire.edu>, jmolinari@hamp.hampshire.edu writes:
>> 
>> 	A while ago I posted a question dealing with the curses library
>> package.  I asked how I could handle cursor input, e.g., "cursor-up, down,
>> etc."  Several people replied with variations of "use the keypad() function".
>> Problem is, keypad() doesn't seem to be implemented in our package of curses
>> (which is installed on a sun3 system).  It's not in the curses.h file, nor in

Assuming SunOS, it surely is. You may however, be looking in the wrong
place.

Try using the Sys V compiler and many of your problems will disappear.

Eg:	/usr/5bin/cc

This compilers searches /usr/5include first and in there you will find
a curses.h with keypad().

>It's a tricky problem.  To be really portable and terminal
>independent, you have to parse the keystrokes and compare them
>with the values given in TERMCAP or its equivalent.  I haven't seen
>a version of curses that includes this, and most termcap files have

This is precisely what the keypad() function does - if your curses has
it.

>*very* scanty information about key codes, particularly for function keys --
>they normally stop with up, down, left and right.

Agreed that this is very variable depending on the origin of the
curses. But most of the ones I have seen have at least some function
keys.

>I have a routine to
>do this parsing, and some fuller termcap entries, if you're interested.
>It reads the termcap file at run time, so it can cope with changes of
>terminal type.

Most curses have tgetstr() which returns the strings in question, thus
avoiding the need to parse the termcap file.

Those that don't should be boycotted given that it's pretty close to
the 21st century and all that...


--
Mark Delany                                          markd@werple.pub.uu.oz.au
                                         (Soon to be markd@werple.apana.org.au)