HDTenEightyP/NetNews huggingface dataset:
From: simon@giaec.cc.monash.edu.au (simon shields)
Subject: dynamic multidimensions qtn ?
Keywords: pointers 2 dimensions
Organization: Monash University, Melb., Australia.
Date: Fri, 11 Sep 1992 04:19:28 GMT


Hi

My system is HP-UX giaec A.08.07 A 9000/720 
Is it possible to have dynamic multidimensions in c.
Heres a test program that causes a core dump


#include <stdio.h>
#include <stdlib.h>
#define error(a) fprintf(stderr,a)

main()
{
	int **f;

	if ((f=(int**) malloc(100*sizeof(int)))==NULL) {
		error("Not enough memory for f\n");
		exit(0);
	}
	f[0][0]=24;    /* <- core dump occurs here ? */
	f[0][1]=34;
	printf("%d %d\n",f[0][0],f[0][1]);
	exit (0);
}

___
Thanks for any help
by from Simon

Newsgroups: comp.lang.c
From: faivre@cst02.segin.com (Denis Faivre)
Subject: Re: EASY C
Reply-To: faivre%cst02.segin.com@relay.prime.com (Denis Faivre)
Organization: Segin, Groupe Axime
Date: 13 Sep 92 20:57:11 GMT

mjn@pseudo.uucp (Murray Nesbitt) writes:

>If you want Pascal, you know where to find it.

The goal isn't to change to another language, but to make C easier to learn,
easier to read and easier to debug for programmers used to deal with COBOL.
-- 
Denis FAIVRE - AXIME                   When anything can go wrong, it w$*& !
Phone : +33 20.60.79.79
E-Mail : faivre@cst02.segin.com
Newsgroups: comp.lang.c
From: hollasch@kpc.com (Steve Hollasch)
Subject: Re: SEX SEX SEX
Summary: Damn newbies...
Organization: Kubota Pacific Computer, Inc.
Distribution: usa
Date: Sat, 5 Sep 1992 01:26:30 GMT

vinod@dolomite.WPI.EDU (Vinod K Nair) writes:
    [drivel that DESERVED to be deleted.  =^]

    Ok, hands up everybody who DIDN'T immediately know that this had to be
a posting from a .edu site.

______________________________________________________________________________
Steve Hollasch                                   Kubota Pacific Computer, Inc.
hollasch@kpc.com                                 Santa Clara, California
Newsgroups: comp.lang.c
From: alan@sal.wisc.edu (Alan Watson)
Subject: Re: Initializing Random Seeds 
Organization: Space Astronomy Lab, Madison WI
Date: Mon, 7 Sep 1992 05:11:54 GMT

Save the state of the generator in a file at the end of the run; read
the state back in at the beginning of the next run.
From: edb1@cbnewsf.cb.att.com (edward.benyukhis)
Newsgroups: comp.lang.c
Subject: Re: Help to solve problem with "gets()"
Date: 11 Sep 92 15:10:13 GMT
Organization: AT&T

In article <1429@yetti.UUCP> g-yao@cs.yorku.ca (Ling Yao) writes:
>Hi, Dear friends:
>
>   As a "C" novice, I would like to ask some advice about how to use
>   gets().
>
>The following is my programm:
>
>*************************************************************************
>#include <stdio.h>
>
>static char *message[]={"Translation:",
>			    "0. X      1. Y    2. Z",
>                        "Exit:",
>			    "x or X",
>			 NULL
>                        };
>main()
>{
>    float tmp;
>    int i=0;
>    char *a;
>
>/* print input message */
>    while(*message[i]!=NULL)
>    {
>	printf("%s\n",message[i]);
>	i++;
>    }
>
>   L1: gets(a);
>    printf("gets=%s\n",a);
>
>    switch(*a) {
>    case '0': printf("translate in x ");
>            return(1); 
>
>    case '1': printf("translate in y ");
>            return(1);
>
>    case '2': printf("translate in z");
>            return(1);
>
>    case 'x':
>    case 'X':
>	return(0);
>
>
>    default:
>	 goto L1;
>    }
>}
>**************************************************************************
>
>When I run it , I get following result:
>
>----------------------------------
>Translation:
>0. X      1. Y    2. Z
>Exit:
>x or X
>Segmentation fault (core dumped) 
>_________________________________
>
>When I use lint, it showed:
>
>____________________________________
>gets() returns value always ignore.
>------------------------------------
>
>Some friends who can kindly give me some help ,
>I would it appreciate very much.
>
>Please answer this by email , if it is convience to you.
>
>Thanks in advance.
>
>
>+-------------------------------------------------------------+
>| Ling YAO                        "I die when it's time for   |
>| Department of Computer Science   me to die. So let me live  |
>| York University                  my life the way I want to."|
>| North York, Ont. Canada M3J 1P3         -----Jimi Hendrix   | 
>| e-mail: g-yao@cs.yorku.ca                                   |
>| Office phone:(416)736-2100       home phone:(416)650-1480   |
>|        Ext.20242 or 20275        Fax:       (416)650-1480   |
>+-------------------------------------------------------------+
>-- 
>
>+-------------------------------------------------------------+
>| Ling YAO                        "I die when it's time for   |
>| Department of Computer Science   me to die. So let me live  |




The reason the program core dumps is in the statement:

	while ( *message[i] != NULL ) {
		...
		...
	}
	
You do not want to dereference message[i] with *.  What you want to
do is 

	while ( message[i] != NULL ) {
		....
		...
	}
	
	
There are other obviously wrong statements in you program. 
char *a, for example, is not initialized and memory is not allocated
to hold a string before you perform a gets(a);



Best regards,


Ed Benyukhis
From: wangyu@ccwf.cc.utexas.edu (Yu Wang)
Newsgroups: comp.lang.c
Subject: free() problem ...
Date: 9 Sep 92 04:20:40 GMT
Reply-To: wangyu@ccwf.cc.utexas.edu (Yu Wang)
Organization: The University of Texas at Austin, Austin TX
Originator: wangyu@grumpy.cc.utexas.edu

Hello guys,

I got a question on free().  It looks to me that free() doesn't
actually make freed memory spaces available to other programs.

I wrote 2 simple programs: the first one was to allocate, say, a 10MB
size array, then, free it (using free()), and put in an infinite
loop.  After running the first program in background, I ran the
second program which used malloc() to grab as much memory as possible
and report the memory size that had been seized.

I ran the second program many times during a long period of time, but
the available memory size I got from it was always 10MB less than the
number I got from running the second program prior to the first
program, i.e. 10 MB memory was never made available to other programs!

Any help is greatly appreciated.

Lena
Newsgroups: comp.lang.c
From: adam@microware.com (Adam Goldberg)
Subject: Re: main()
Organization: Microware Systems Corp., Des Moines, Iowa
Date: Tue, 8 Sep 1992 12:56:11 GMT

doug@tisdec.tis.tandy.com writes:

>Actually main() is defined as

>  int main(int argc, char **argv, char *envp);

Actually, main() is defined as
   int main(int argc, char **argv, char **envp);

although it probably should be unsigned int main(...) since what
does a negative return code return to the OS?

-- 
Adam G.
adamg@microware.com, or ...!uunet!mcrware!adamg
The above is not to be construed in any way as the official or unofficial
statements of Microware, or any Microware employees.
From: wade@nb.rockwell.com (Wade Guthrie)
Newsgroups: comp.lang.c
Subject: Re: Only C gurus allowed?!?!
Date: 10 Sep 1992 01:10:58 GMT
Organization: Rockwell International


Several people have said something to the effect of "If you don't REALLY know,
don't answer".  Well, if one thinks he knows, then he really should reply --
that's what the net community is all about.  Besides, how does anyone know
if they have a unique solution to a problem that even the GURUs haven't
considered.  Lastly, lets give Chris, Doug, Henry, Karl, and Andrew a break --
they can't be asked to solve ALL of our problems; we may just have to rely
on one another to do that.

Come out of the tower and chill a bit.

Wade
wade@nb.rockwell.com
Rockwell doesn't care about all of this -- these are my thoughts.
From: ae684@cleveland.Freenet.Edu (Jeffrey Schmidt)
Newsgroups: comp.lang.c
Subject: Begining in C
Date: 12 Sep 1992 17:42:47 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


I'm a high school student and have mastered Basic and Pascal.
I've started to teach myself C - since there are no courses
available as of yet.  Any suggestions of good books or anything
for that matter would be greatly appreciated.  Thanx.

Please respond by email.
-- 
The preceding was yet another useless 
thing I typed with many typoos!
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: Only C gurus allowed?!?!
Date: 9 Sep 92 16:29:21 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Sep9.051107.22938@nuscc.nus.sg>, eletanjm@nuscc (TAN JIN MENG) writes:
>I posted something in this group to try to help someone out. 
>
>I got flaming mail to the effect that I was wrong, that my explanation
>was garbage etc etc and that I shouldn't post in this group (to help
>others) unless I'm very sure of the facts.
>
>Is there some kind of implicit censorship here? To the effect that only
>C gurus are allowed to help others here?

Well, any post to the net is an implicit invitation to flames, particularly
if it is in error.  My experience has been fairly good; I've posted my share
of erroneous information, but the vast majority of the replies I've gotten
I would not consider `flames'.  Your milage may vary, especially if you
consider any message contradicting what you've said a flame.

>Does it matter whether I was right or wrong?

Well... yes.  As the program says, when you post an article, you post to
machines all over the state/province/country/continent/world.  If you're not
99 3/4 % sure you're right, it's probably best to sit on your hands, and let
someone else reply.  There's lots of people who read this group that are
/very/ knowledgable about C, and it's rare that a post gets completely ignored.

>I remember the last controversey I stirred up in this group when I titled a 
>thread "ANSI C and threads". It was an article about testing a possible
>way to write portable threads using C (I did mistitle somewhat) - I got
>as many flames (and outright insults) regarding my "misuse of ANSI" as I
>did discussing the contents of the article.

Well, if you were truely writing non-portable code which is very easy to do),
it probably deserved comment and correction.

>I'm fairly pissed.

-- 
Dave Schaumann			dave@cs.arizona.edu
From: berman@nlm.nih.gov (Lew Berman)
Newsgroups: comp.lang.c
Subject: structures
Date: 15 Sep 92 19:45:02 GMT
Reply-To: berman@nlm.nih.gov
Organization: National Library of Medicine

Are items in a structure gauranteed to be contiguous in memory?
The following is the structure I will be working with:


#define	IMAGE_TYPE_CERVICAL		0x0001
#define IMAGE_TYPE_LUMBAR		0x0002
#define IMAGE_TYPE_OTHER		0xffff

typedef struct image_stat {
  short int min;			/* image min */
  short int max;			/* image max */
  short int mean;		        /* image mean */
  float     variance;                   /* image variance */
} IMSTAT;

struct lheader {
  short int id;                         /* image id number */
  short int itype;			/* type of image */
  short int rows;			/* number of rows */
  short int cols;			/* number of cols */
  short int dyn_range;   		/* dynamic range */
  short int dpi;			/* dpi of image */
  
  IMSTAT    istat;			/* ptr to stats on file */
};

union image_header {
  struct lheader header;
  char cHeader[sizeof(struct lheader)];
};
		
typedef union image_header IMHEADER;

struct image {
  IMHEADER  header;			/* image header */
  char	  *data;			/* image data */
};

typedef struct image IMAGE;


The reason I ask this question is that I would like to be able to transmit 
the data in this structure using sockets.  If I can use the pointer to cHeader,
as defined in the union, than all I need to do is send the header first
rather than sending each component of the header separately.  But this is dependent
on whether or not the items in the structure are guaranteed to be in their 
correct order since on the receiving end the software will expect them
in this order.

Please respond by e-mail directly to me.

Thanks,

Lew Berman
National Libr. of Medicine
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: I disagree with lint(1)
Keywords: lint, classic C
Date: 7 Sep 92 10:05:33 GMT
Organization: AND Software BV Rotterdam

In article <1992Sep7.083401.2587@sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes:
|typedef struct foo *bar;
|
|fun(b)
|bar b;
|{
|    b=b;
|}
|
|struct foo
|{
|    int i;
|}   the_struct;
|
|main()
|{
|    fun(&the_struct);
|    return 0;
|}
|
>Lint(1) says:
|
|fun, arg. 1 used inconsistently	foo.c(5)  ::  foo.c(16)
|I disagree.  The first argument to fun is a pointer to struct foo on both
|lines.  In my book, that's the same.
|What do you all think?

I think lint is right. The C compiler only does a `shallow type comparison',
i.e. 

struct foo {
	int i;
};

struct bar {
	int i;
};

are two completely different structure types even though their contents
are identical (to us.) The compiler stores the names of the identifiers
in a couple of name spaces:

- label names
- structure tag names
- for every structure, a separate structure member name space
- all other identifiers (inlcuding typedef'd names)

Very, very, very old C compilers didn't have a separate name space for
the structure members, but I'm talking about the Pleistocene here ...

Because the C compiler (and lint) just doesn't check the _contents_
(or description) of the types (it just finds the name `bar' in the 
last name space and the name `foo' in the structure tag name space,) 
it comes to the conclusion that you're using inconsistent pointer types.

Does this clarify things a bit?

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c
From: behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens)
Subject: Re: problem with "external pointer"
Organization: Technische Universitaet Muenchen, Germany
Date: Mon, 7 Sep 1992 21:49:37 GMT

dave@cs.arizona.edu (Dave Schaumann) writes:

>What you have to understand is that "extern int *ps;" is a /definition/ of
>"ps".  You still need to have a declaration of "ps" somewhere in your source
>code.  If you don't, the linker will complain (and rightly so).

Wasn't that the other way round? It's a declaration and you still need the
definition? Oh well, I tend to confuse the two too ;-)

Soenke
-- 
===========================================================================
More than silver, more than gold, I need   !    behrenss@informatik.
electricity. I need it for my dreams.      !    tu-muenchen.de
(RACTER)                                   !  FIDO: 2:246/13 Soenke Behrens
Xref: sparky comp.lang.c:13428 comp.lang.pascal:5282 comp.lang.misc:2990
From: tswingle@oucsace.cs.ohiou.edu (Tom Swingle)
Newsgroups: comp.lang.c,comp.lang.pascal,comp.lang.misc
Subject: Opinions on case sensitivity in programming languages?
Date: 10 Sep 92 03:42:46 GMT
Followup-To: poster
Organization: Ohio University CS Dept,. Athens

This is a subject I have been curious about for a long time:  the merits of
case-sensitive vs. case-insensitive languages.  I have not been able to figure
out any major benefits one way or another.  So this is where all of you come
in; you get to point out things that I might be missing.  More specifically, I
am looking for reasons one might choose one over another when designing a
programming language.  Plus, I would like to find out which one is preferred by
more people and why.  Here are a few questions to incite discussion, although
you need not feel obligated to answer all of them, and please feel free to 
comment on anything else regarding this issue that you want:

1.  Do you prefer programming in a language which is case-sensitive or case-
insensitive (or does it even make a difference to you), and why?

2.  How significant an issue is case-sensitivity in your preference toward one
language over another?

3.  Since this article is posted to the C and Pascal newsgroups, here is a
question for the respective users of each language:  To the C programmers, do
you feel that you would like C better if it were case-insensitive; and to the
Pascal programmers, do you feel that you would like it better with case
sensitivity?  (I suppose the Pascal users could always go over to Modula-2,
but there's more to Modula-2 than just that.  Just forget that Modula-2 exists
for now, Pascalites :-). )

4.  If you were designing a language, would you make it case-sensitive, case-
insensitive, or maybe even allow for an option to go either way.  (The last
choice might be rather awkward, and the answer to this question is not
necessarily the same as the answer to #1; you might have a preference, but
realize that the majority feels the other way--or maybe you don't care what
they think :-). )

Again, this is not intended to be an exhaustive list of questions; if you have
anything else to say about it, feel free to do so.  Preferably, I would like
to do this in e-mail and summarize to the net (followups are directed to
poster).  I will give the final count of votes among those with a preference,
as well as any other useful information that I get.  And yes, I do have an 
opinion, but I will not state it yet so as to avoid tainting the results :-).
Cast your vote today!!
-- 
"The problem you are experiencing is  |  "To be sure of hitting the target, 
not with the network nor with the     |  shoot first and, whatever you hit, 
station.  Please adjust your set."    |  call it the target." 
More ramblings from: tswingle@oucsace.cs.ohiou.edu/tswingle@bigbird.cs.ohiou.edu
Newsgroups: comp.lang.c
From: ara@zurich.ai.mit.edu (Allan Adler)
Subject: mp.h
Organization: M.I.T. Artificial Intelligence Lab.
Distribution: comp
Date: Thu, 10 Sep 1992 06:20:13 GMT


I'm trying to compile some code that #include's the file <mp.h>, which
I and my C compiler (GCC) have never heard of. I think it might be something
that lives on a sun4, but I don't konow.

Anyway, even if someone sent me mp.h from their system, it probably wouldn't
work on another system. So I am wondering what one does on another system
to replace this mp.h by something more portable, e.g. something mentioned
in Harbison and Steele or something that comes with GCC.

Allan Adler
ara@altdorf.ai.mit.edu
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Why should POINTERS be so damn hard to understand ?
Date: 7 Sep 92 06:05:31 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1992Aug28.012406.3698@ttinews.tti.com>, reid@metis.tti.com
(Reid Kneeland) repeated a popular myth (=falsehood):
' If you think of C as a preprocessor for the PDP-11 assembler, it
' makes a lot more sense.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) replied:
" Of course, if you _do_ think of C that way, you will be committing the
" sin of anachronism. ...  The PDP-11 was _not_ the first
" machine C ran on, nor the machine C was designed for.

In article <1992Sep03.154038.27377@syscon.rn.com>, carl@syscon.rn.com (Carl Kreider) writes:
> Certainly true, but I thought that "*p++ = *s++" derives directly from
> "mov (r0)+,(r1)+" for example.  In that sense C is high level assembler.

How often do I have to say it?  "move (r0)+,(r1)+" is a PDP-11 instruction.
The PDP-11 was _NOT_ the first machine C ran on, nor the machine C was
designed for.  _That_ machine DID NOT HAVE SUCH INSTRUCTIONS.  C happened
to contain a sub-language which is close to PDP-11 machine language, but
that was to _some_ extent a lucky coincidence.  C was _not_ a high-level
assembler for the machine it was designed for.

The true history of C has been told so many times that there is no need
to make up stories about it.
-- 
You can lie with statistics ... but not to a statistician.
Newsgroups: comp.lang.c
From: rowe@netcom.com (Rick Rowe)
Subject: C Newsletter
Date: Mon, 07 Sep 92 03:03:34 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

It seems that FALL is in the air and there are plenty of new C
students. I have noticed quite a few questions regarding issues
that are answered in Steve Summit's C FAQ. Grab a copy and check
it out - it will really help ya. 

I also wanted to let those new C programmers know about a newsletter which 
is oriented towards C education. It is sent out each quarter and
covers various C programming topics.  It does have a small
subscription fee now, but you will find it insignificant. (Please
hold back the flames, it was free until my wife realized what
it was costing us. :-( So, the costs cover expenses only...) 

[I told her, but I love C - she asked, "C what?".] 

In any case, if you are new to the C language obtaining interesting
resources and taking the time to experiment will make your efforts
pay off. There are other C newsletters out there too ... and even
mags on the subject. The bottom line is to take the time and read, 
experiment, ask questions, and continue;

My students are also excited. Which kind of energizes me. I just
love it when a student realizes that a pointer implies a type of
variable and not something I use to help my lectures. :-)

Sorry for the use of bandwidth here...but remember, keeping the
excitement going and _encouraging_ those new C want-a-be's is
also worthy of bandwidth from time to time.

The newsletter is sent via snail mail (hardcopy only)
and all example programs are sent via E-mail or on disk. 

For info on the newsletter, please send questions to:

	rowe@netcom.com

C YA! Rick Rowe

ps. please be kind, flame somebody being hard on a beginner - I'm
just trying to keep them excited. Ya'll know they'll need it!

-- 
===========================================================================  
Rick Rowe - The C Programmers Network Newsletter+_   int x=10,y=20;       |
Editor      Internet: rowe@netcom.com           +_   x=x^y; y=y^x; x=x^y; | 
On a clear day you can C forever!               +_   /* getting dizzy? */ |
From: rescorla@rtnmr.chem.yale.edu (Eric Rescorla)
Newsgroups: comp.lang.c,alt.folklore.computers
Subject: Re: What is Duff's Device?
Date: 12 Sep 92 15:32:35 GMT
Distribution: na
Organization: Rescorla for himself.

In article <1992Sep12.091733.522@cs.umb.edu> mzraly@ra.cs.umb.edu (Michael S. Zraly) writes:
>I understand that Duff's Device is a technique used to unroll a
>critical loop, along the lines of what one might find in a routine like
>memcpy().  Can someone please post or email an example of code using
>Duff's Device?
>
>Finally, is Duff's Device named after Bell's Tom Duff?
From the Jargon File.
:Duff's device: n. The most dramatic use yet seen of {fall
through} in C, invented by Tom Duff when he was at Lucasfilm.
Trying to {bum} all the instructions he could out of an inner
loop that copied data serially onto an output port, he decided to
{unroll} it.  He then realized that the unrolled version could
be implemented by *interlacing* the structures of a switch and
a loop:

       register n = (count + 7) / 8;       /* count > 0 assumed */
       switch (count % 8)
        {
        case 0: do {    *to = *from++;
        case 7:         *to = *from++;
        case 6:         *to = *from++;
        case 5:         *to = *from++;
        case 4:         *to = *from++;
        case 3:         *to = *from++;
        case 2:         *to = *from++;
        case 1:         *to = *from++;
        } while (--n > 0);
        }

   Having verified that the device is valid portable C, Duff announced
   it.  C's default {fall through} in case statements has long been
   its most controversial single feature; Duff observed that "This
   code forms some sort of argument in that debate, but I'm not sure
   whether it's for or against."

                                  
-Ekr

-- 
-------------------------------------------------------------------------------
Eric Rescorla, DoD#431 (Nighthawk S)              rescorla@rtnmr.chem.yale.edu
Former chemist now CM400 mechanic                 ekr@eitech.com(preferred)
                       I will hack Unix for food.
Newsgroups: comp.lang.c