HDTenEightyP/NetNews huggingface dataset:
From: ptran@envmsa.eas.asu.edu (Phi-Long Tran)
Subject: Re: structure question
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: Arizona State University, Tempe, AZ
Distribution: usa
Date: Tue, 21 Jul 1992 07:39:00 GMT

In article <1992Jul21.053858.26677@vuse.vanderbilt.edu>, 
leegye@vuse.vanderbilt.edu (Gyesung Lee) writes...

>typedef struct a_struct {
>       char            *name;
>       int             mark;
>       struct a_struct *next;
>} *A_Type;

>A_Type Global_Root;

..

>main  ()  /* create a global root and set next ptr to NULL */
>{
>  Global_Root = (A_Type) malloc (sizeof(A_Type));
>  Global_Root->next = NULL;
>  abc();
>}

>The right answer should be:
> 
>In abc:  is  NULL
>In abc1: is  NULL

>But, the result turns out as follows:

>In abc:  is  NULL
>In abc1: not NULL
>Segmentation fault (core dumped)

>If I modify 'A_Type' structure as follows by switching `mark' and `next',
>...
>then, it works correctly.

>I rearranged the elements of `struct a_struct' and ran it.
>In some case it works, in other cases no luck.
>Could anyone tell me what is wrong with this program ?

     I can see one major problem -- you allocated a pointer, not a whole
data structure.  You declared A_Type as a pointer, so sizeof( A_Type ) is
the size of a pointer to your type (however many words that may be for your
machine).  Malloc returns you a pointer to an area in the system heap for
you to store an address, but what you really want is to allocate the whole
structure.  I suggest the following:

struct A_Struct_Tag { ... };
typedef struct A_Struct A_Type; /* This is what you really want. */
typedef A_Type *A_Type_Ptr;     /* Declare a type for a ptr. to A_Type. */
..
A_Type_Ptr global_A_Ptr;
..

     The call to malloc would then be:

global_A_Ptr = (A_Type_Ptr) malloc( sizeof( *global_A_Ptr ) );

     Originally, when you allocated a pointer with just sizeof( A_Type ),
you were pointing to an address, not the data structure that you were
hoping to get.  Your random errors reflect de-referencing random locations
stored in Global_Root.  Changing field declaration order does not make that
much of a difference (usually).  I suggest you read a good C book and jump
to the pointer chapter -- K&R's "The C Programming Language."

---
Phi-Long Tran
ptran@asuvax.eas.asu.edu
Arizona State University
Newsgroups: comp.lang.c
From: mat@mole-end
Subject: Re: About the 'F' in RTFM
Summary: Or Fungible
Organization: :
Date: Wed, 22 Jul 1992 20:36:04 GMT

In article <1992Jul18.163941.24358@dartvax.dartmouth.edu>, mozart@coos.dartmouth.edu (Sting) writes:
> In <1992Jul17.202448.19848@wyvern.twuug.com> Joe Wright writes:
> 
> >Proposed change to 'standard' practice.  'RTFM' is now 'RTM'.
> >The 'F' does not relate to any known adjective for Manual.
> >'Read The Manual' should suffice.
 
> There was once when a user had overheard a conversation in the Consultants'
> Office here at the college, and came in wanting to know what this "RTFM"
> thing they kept saying meant.
 
> The head consultant thought fast and, handing the user a Microsoft Word
> manual, said "Read the manual..."
 
> The user said "Ohhhhh...a Microsoft thing!" and left happy.

Of course, since the fusty manuals are often neglected until they are
about to crumble into dust, it could also mean

	Read The Fungible Manual

-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c
From: henkp@cs.ruu.nl (Henk Penning)
Subject: Re: C-Programming FAQ
Summary: C FAQ is available via anonymous ftp from ftp.cs.ruu.nl
Date: Wed, 29 Jul 1992 14:03:19 GMT
Organization: Utrecht University, Dept. of Computer Science

In <1992Jul29.002305.27779@athena.mit.edu> ankleand@mtl.mit.edu (Andrew Karanicolas) writes:

>Hi,
>
>Where can I find a FAQ list pertaining to this newsgroup?
>
>Thanks.
>
>-- 
>Andrew Karanicolas
>MIT Microsystems Technology Laboratory
>ankleand@mtl.mit.edu

________________________________________________________________________
  We, Computer Science department, Utrecht University,  are  running  an
anonymous  FTP  server  on  one  of  our systems. In addition to the FTP
service we're also running a mail  server,  for  those  of  you  without
direct Internet access.


--> How to get 'C FAQ' via anonymous FTP:

    Site:     ftp.cs.ruu.nl  [131.211.80.17]
    Login:    "anonymous" or "ftp"
    Password: your own email address (you@your_domain)
    file:
      /pub/NEWS.ANSWERS/C-faq/abridged
      /pub/NEWS.ANSWERS/C-faq/diff
      /pub/NEWS.ANSWERS/C-faq/faq


--> How to get 'C FAQ' via e-mail from our mail-server:

    NOTE: In the following I have assumed that your mail address is
	  "fred_flintstone@stone.age.edu"; of course you must substitute
	  your own address for this.

	  | Please use a VALID DOMAIN ADDRESS.
	  | Use 'hip!hop!user' if you must.
	  | Never use an address which has both '!' and '@' in it.
	  | Bitnetters use user@host.bitnet


    Send the following message to
		mail-server@cs.ruu.nl
    or the old-fashioned path alternative
		uunet!mcsun!sun4nl!ruuinf!mail-server


    begin
    path fred_flintstone@stone.age.edu (SUBSTITUTE _YOUR_ ADDRESS)
    send NEWS.ANSWERS/C-faq/abridged
    send NEWS.ANSWERS/C-faq/diff
    send NEWS.ANSWERS/C-faq/faq
    end


The path command can be deleted if we receive a valid from address in your
message. If this is the first time you use our mail server, we suggest you
first issue the request:

      send HELP


  A complete "ls-lR" listing of the archive is  kept  in  the  top-level
directory, it will be updated every night. To get it, issue the command:

     send ls-lR.Z



  That's all for now. If you encounter problems using  the  FTP  service
and/or the mail-server, feel free to drop me a line (by e-mail, please).


Henk P. Penning, Dept of Computer Science, Utrecht University.
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31-30-534106, NIC-handle: HPP1.
e-mail   : henkp@cs.ruu.nl (uucp to sun4nl!ruuinf!henkp)
Newsgroups: comp.lang.c
From: Ross Ridge <ross@zooid.guild.org>
Subject: Re: HIgher problems at hand. HELP!
Organization: ZOOiD BBS
Date: Mon, 27 Jul 1992 21:23:11 GMT

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>>/*
>> * strstr - find first occurrence of wanted in s
>> *
>> * based on code by Henry Spencer
>> * modified for ANSI by D'Arcy J.M. Cain
>> */
>>
>>/* The following define required for full checking.  The problem is that */
>>/* the function has to ultimately assign a const char * to the return */
>>/* value which has to be char *.  The answer is to drop the use of */
>>/* const in this module and trust the code to do the right thing */
>>#define		const
>
>Yuck!
>Do *not* #define keywords unless you have absolutely no alternative.
>
>>#include	<string.h>
>
>Now what happens if string.h happens to contain
>	const CHAR_BIT = 8;
>or some such?

Include files are very unlikely to contain external definitions like this.
Remeber in C there is world of difference between "#define CHAR_BIT 8"
and "/*static*/ const /*int*/ CHAR_BIT = 8;".  But who knows what's 
in <string.h> so it would be better if the "#define const" was placed
after the "#include <string.h>". 

>>char	*strstr(const char *s, const char *wanted)
>
>This is a *different* prototype to the externally visible one, since
>this one doesn't include "const".

What externally visable one? 

>>	return(s);
>
>The solution to the const problem is just to put a cast in the final return
>statement:
>	return (const char *) s;

You mean "return (char *) s;".  This ia probably the better over all
solution, but simply not using const will work to.  

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: About the 'F' in RTFM
Organization: Texas Instruments, Inc
Date: Mon, 20 Jul 1992 21:41:13 GMT

In article <1992Jul17.202448.19848@wyvern.twuug.com> alpha@wyvern.twuug.com (Joe Wright) writes:
>Proposed change to 'standard' practice.  'RTFM' is now 'RTM'.
>The 'F' does not relate to any known adjective for Manual.
>'Read The Manual' should suffice.

Yeah, it should, but if it did they wouldn't have asked the question
in the first place.  Hence the 'F'.

-- 
"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: pat@cs.uow.edu.au (Pattarasinee Bhattarakosol)
Newsgroups: comp.lang.c
Subject: update.time
Summary: How to get the update time of file?
Keywords: fstat
Date: 30 Jul 92 01:33:30 GMT
Organization: Dept of Computer Science, Wollongong University, Australia

Hello,

I would like to ask a simple question. 
I want to know how to get the date & time of the updated file, which does
not belong to the user.   In my program, I have an assumption that the file
which will be retrieved  belongs to someone else.
I plan to use fstat in the c program (my server program), but one point 
that I cannot find is what is time_t type in struct of stat.

Anybody out there please answer my question, by mailing the answer to me
at pat@cs.uow.edu.au, because I don't come to read the network news often.


Thank  you

pat
From: ross@zooid.guild.org
Newsgroups: comp.lang.c
Date: 18 Jul 92 03:11 MDT
Subject: Re: Hungarian notation
Nf-ID: #R:mechp05.uucp:35240001:1992Jul17.231117.15302@zooid.gui:-1809532524:001:1166
Nf-From: zooid.guild.org!ross    Jul 18 03:11:00 1992


ross@zooid.guild.org (Ross Ridge) writes:
>I rarely spend much time scratching my head wondering what the type of
>variable is, and the odd time that I do, I'm wondering if it's a "struct foo"
>or a "struct bar" something that Hungarian won't tell me.

stephen@eggneb.astro.ucla.edu (Stephen Schimpf) writes:
>Why not? It is perfectly acceptable for you to come up with your own
>prefixes. You are not limited to ones like "sz" and "b" or ones like
>"hinst" or "hwnd" that Microsoft invented for Windows. If you make it
>clear to other programmers reading your code (this includes you a few
>months (weeks?) after you have written it) it will work.

How am I going to make an arbitrary, and probably ambigous list of hundred
or so prefixes clear to anyone?  

>typedef struct tagFOO			// foo  <-- mention prefix here

If that comment is sufficient enough docomentation on the meaning of
the new prefix then:

	struct tagFOO left;

is sufficient enough documention of the type of the variable defined.

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: compiler broken?
Date: 27 Jul 92 18:37:58 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Jul25.054848.11223@wyvern.twuug.com>, alpha@wyvern (Joe Wright) writes:
>rdlin() {
>	int i;
>	for (i = 0; i < length && ((record[i] = getc(infile)) != EOF); ++i)
>		;
>	return i;
>}
>
>It worked fine on my C/80 system but failed on another i486 Unix
>system.  It turned out that if the character read was 0xff it was
>promoted to -1 (EOF) and caused an 'early' exit.

You left out the declaration of record[], but from your problem, I
bet you have it declared as "char record[N]", or something similar.
Moreover, I'll bet chars are unsigned on your C/80, and signed on
the Unix box.

Your problem (assuming my guesses are correct) is in the expression

  (record[i] = getc(infile)) != EOF

If record[i] is of type char, then the value of the assignment statement
will be of type char, too.  That means if you have signed chars, 0xFF gets
promoted to (int) -1, and matches EOF.  If you have unsigned chars, this
promotion does not happen.

However, if you have unsigned chars, when EOF is encountered, the value
is first truncated to 0xff by the assignment statement, so it never
matches the EOF statement.  That means all remaining records are filled
with (char)EOF, which may or may not matter to the rest of your program.

>I fixed it:
>
>rdlin() {
>	int c, i;
>	for (i = 0; i < length; ++i) {
>		if ((c = getc(infile)) == EOF)
>			break;
>		record[i] = c;
>	}
>	return i;
>}

Notice how here, the assignment statement results in an int, so no
information is lost when EOF is encountered, and 0xff is not erroneously
promoted when it is encountered.

Also, you probably want to put a '\0' after the end of the data in your
array, since many of C's string-handling functions depend on it being there.
You should probably also re-think the wisdom of making "record", "length",
and "infile" global to a routine of such general utility as reading in a
string.  In fact, you may wish to investigate fgets(), which is a library
routine that performs virtually the same task as the code presented above.

>Question:  Is the Unix compiler broken?  

No, I don't think so.

-- 
You're traveling through another dimension -- a dimension not only of sight and
sound but of mind. A journey into a wonderous land whose boundaries are that of
imagination.  That's a signpost up ahead: your next stop: the Twilight Zone!
Xref: sparky comp.lang.c:11431 comp.lang.c++:11322 comp.lang.objective-c:452
From: R.S.Jones@qmw.ac.uk (Robert S. Jones)
Newsgroups: comp.lang.c
Subject: Re: Summary: Why use "extern" on function prototypes.
Date: 21 Jul 92 07:06:41 GMT
Organization: Queen Mary & Westfield College (London)
X-Useragent: Nuntius v1.1

In article <12271@anderson> David Anderson, anderson@Software.Mitel.COM writes:
> From Mike: ARIEL.LERC.NASA.GOV!SMNEYLN@uunet.ca Tue Jul  7 13:06:09 1992
>
> I checked in 'C the Complete Reference' by the C god himself, H.Schildt.
> He says that extern variables (and functions) are not allocated in that
> section of the program.  Thus, I think extern, although not necessary in
> headers, is used to reduce memory considerations.  Take a look at a 
> Windows program on DOS machines.  The program must obviously be written
> in several parts, using the same header files (ie stdio.h).  If the
> header file did not have extern for each proto, memory would be allocated
> for the functions several times.  So if i use stdio.h in a hundred part
> program, I might just zap a good 100k of memory just to the extra allocation
> However, if I extern the header, I would only allocate the memory once (in
> the actual library), and save that precious 100k.

Disclaimer. I am NO expert, nor probably even a minor deity.

But, surely the point is being missed here. Headers are (mostly) not magic,
just bits of text idempotently [:-)] dragged in to your C masterpiece
at the point you #include them. What on earth do you expect <stdio.h> to
allocate 100k for? There is no code in it - only definitions. If your C 
libraries and linker are any good you should only get ONE copy of each
routine you ACTUALLY call in your "chef d'oeuvre" in the linked module.
>
--
Robert S. Jones -- Computer Systems Manager | The opinions stated above are
Queen Mary & Westfield College, London U.K. | not necessarily .. no, dammit
X-Voice: +44 71 975 5326                    | ... these are the facts!! :-)
Newsgroups: comp.lang.c
From: hurst@hyper.hyper.com (Graham Hurst)
Subject: Re: good memory allocation strategies?
Summary: Dynamic memory allocation is unsafe with default SGI kernel
Keywords: SGI kernel
Reply-To: hurst@hyper.com (Graham Hurst)
Organization: HyperCube Inc.
Date: Wed, 22 Jul 1992 17:21:11 GMT

In article <1992Jul21.214115.28569@tamsun.tamu.edu> tsmith@cs.tamu.edu writes:
...
>I am working on a moderate size (~10000 lines so far) system on an SGI
>workstation running UNIX system V.3, and I am wondering about some
>memory allocation issues. [Rest deleted]

Beware of using memory allocation on SGI computers!

We recently discovered a "feature" of the default SGI kernel that makes
dynamic memory allocation unreliable - it never turns down a request for
memory!

Since IRIX 3.3.2, the default SGI kernel will cause malloc/realloc
(via sbrk) to return a non-zero pointer even if the requested memory size is
greater than the sum of physical memory and swap space! If your app tries
to use enough of this memory, the kernel sends a SIGKILL to kill your app
and puts a message on the console about running out of swap space.

I know (but don't agree with) SGI's reasons for making the change in their
kernel, and I know non-portable workarounds that help (including reconfiguring
the kernel). Even if you roll-your-own memory management, many GL calls use
malloc.

SGI told me that Mach and OSF/1 act the same way (i.e. allow fork/exec/sbrk
requests greater than swap+physical). Can anyone confirm?

This behaviour precludes portable and otherwise robust software (employing
the good coding practice of checking the return value of malloc) from
executing reliably on SGIs. I believe it is also at odds with the ANSI C
standard (can't quote it directly, but K&R II suggests if one gets a non-zero
pointer one can use the memory).

Graham Hurst
Hypercube Inc, 7-419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040
internet: hurst@hyper.com
From: dave@cs.arizona.edu
Newsgroups: comp.lang.c
Date: 18 Jul 92 02:12 MDT
Subject: Re: About the 'F' in RTFM
Nf-ID: #R:1992Jul17.202448.19848@wyvern.tw:-789306601:1992Jul17.221259.24938@organpipe:-2128540280:001:660
Nf-From: cs.arizona.edu!dave    Jul 18 02:12:00 1992


In article <1992Jul17.202448.19848@wyvern.twuug.com>, alpha@wyvern (Joe Wright) writes:
>The 'F' does not relate to any known adjective for Manual.

That's a rather bold statement.  Don't you think it should be "The `F'
[in RTFM] does not relate to any adjective /that I know of/ for Manual.

`egrep "^f" /usr/dict/words' yields several possibilities that might
be appropriate.

-- 
You unlock this door with the key of imagination.  Beyond it is another
dimension: a dimension if sound, a dimension of sight, a dimension of mind.
You're moving into a land of both shadow and substance, of things and ideas.
You've just crossed over into... the Twilight Zone.

Newsgroups: comp.lang.c
From: woodman@bnr.ca (Dave Woodman)
Subject: Re: About the 'F' in RTFM
Organization: BNR Europe Ltd, Maidenhead, UK
Date: Wed, 22 Jul 1992 10:04:28 GMT

In article <1992Jul17.202448.19848@wyvern.twuug.com> alpha@wyvern.twuug.com (Joe Wright) writes:
>Proposed change to 'standard' practice.  'RTFM' is now 'RTM'.
>The 'F' does not relate to any known adjective for Manual.
>'Read The Manual' should suffice.
>

Given the state of many manuals today, perhaps the change should be to 
RTFUM... 

I rather like the 'F', and if it were dropped from here, too many other 
hackish phrases and acronyms would have to be changed. In any case, since
it "ain't broke, don't fix it!"

		Dave.


-- 
==============================================================================
=  My e-mail address might be woodman@bnr.ca, but Maidenhead is definitely   =
=  in Britain... My employer is entitled to disagree with anything but this! =
==============================================================================
Newsgroups: comp.lang.c
From: root@alex.rinaco.msk.su (alex kotov)
Subject: Re: Turbo C++ installation problem
Reply-To: root@alex.rinaco.msk.su
Organization: Alex Home
Date: Wed, 22 Jul 92 17:13:10 +0300

Greetings!

>   I am having trouble installing Turbo C++ 3.0 on my machine. When I try to run
>   it I get "DPMI server initialization error-> machine not in database. So then
>   I run DPMIINST.EXE to correct this as per instructions, receiving "A20 was
>   already enabled, so test is meaningless." The machine is a 286 with Phoenix
>   bios. Thanks much to anyone who can help.
>

I had the same problem with different Borland products and I have found
only one way to overcome it.
First, modify your CONFIG.SYS file to remove all memory commanders
such as HIMEM, MC, QEMM, QRAM etc.
Second, run DPMIINST.EXE. A20 will have been disabled at that time and
DPMIINST will make some test and put your machine into its database.
Last, you can restore your CONFIG.SYS and get to work.

BTW, what is Turbo C++ 3.0? Does it have Windows support?
Is it identical to Borland C++ 3.0?

Hope this helps,
-- 
+--------------------------------------------------------+
| Alex Kotov | root@alex.rinaco.msk.su     Moscow Russia |
|------------+     FIDO 2:5020/48.7 AKA 2:5020/75.7      |
+--------------------------------------------------------+


Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: unsigned long to long without lossage (Help)
Organization: SoftQuad Inc., Toronto, Canada
Date: Sun, 26 Jul 92 06:56:23 GMT

> There is NO WAY to portably convert unsigned long to long
> without lossage, because unsigned long can have 64 bits, but long -
> 53 bits (as in one xSoviet mainframe "Elbrus") :-)

Is the ":-)" intended to imply that the whole statement was a joke and
there is no machine with such a property, or is it something else?
If it is not a joke, then more information about data types on the
machine would be of interest.

The ANSI/ISO C standard requires long and unsigned long to be the same
size, and I never before heard of a C implementation where they are not.
-- 
Mark Brader, Toronto		"Mark is probably right about something,
utzoo!sq!msb, msb@sq.com	 but I forget what"	-- Rayan Zachariassen

This article is in the public domain.
Newsgroups: comp.lang.c
From: bcschu@skws02.monsanto.com (Brett Schultz)
Subject: reading in a matrix from a file
Organization: Monsanto Company
Date: Wed, 22 Jul 1992 21:36:17 GMT

What is the fastest way to allocate space for and read in a matrix from a file?

e.g.

For a 2X3 matrix the file looks like:
1
2
3 - end of first row
4
5
6 - end of second row

The way i was doing it was to first allocate space for the int ** (in this case
2 of them)

then allocate space for the 3 int * as I read through the file.
I'm sure there is a faster way to do this.

Note: I have total control of how the file is set up.


I was wondering if anyone has any ideas on how to allocate space for the matrix
using the least possible number of malloc calls (normally the matrix I am 
reading in is a 20,000X30 matrix so I want to save the number of malloc calls)
and could you use fread or something like that to read in the matrix at one
time and store it in memory.  Remember I can make the file look anyway I want
to make the storage of the matrix the fastest as possible.

Thanks,

Brett Schultz
email: bcschu@tin.monsanto.com
From: heinz@edohwg.UUCP (Heinz Wrobel)
Newsgroups: comp.lang.c
Subject: Re:  HIgher problems at hand. HELP!
Date: 27 Jul 92 20:35:45 GMT
Organization: Edotronik GmbH

In article <robertk.02v9@taoami.lerctr.org> robertk@taoami.lerctr.org (Robert Kesterson) writes:
>> Are you sure that the Amiga doesn't have this routine built in or something?
>> If you are expecting an int index into the string and actually get back a
>> pointer you may see results such as these.
>[ more stuff deleted ]
>
>I don't know what compiler is in question here, but so far as I know there
>should be a strstr() on the Amiga.  I just tried it in SAS/C 5.10, and it
>is in there, and works as expected.

Any reasonable ANSI compiler has strstr(). Talking about Amiga compilers, I
don't know of any current commercial or PD ANSI compiler that doesn't have
it.

> Robert Kesterson	    robertk@taoami.lerctr.org

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
"It's good to have a mouse, it's faster if you can do without one..."
"He who doesn't develop with an A2024 doesn't know about font independent
 user interfaces..."
Newsgroups: comp.lang.c