HDTenEightyP/NetNews huggingface dataset:
From: almeida@ame.gsfc.nasa.gov (aswin m. almeida)
Subject:  The 2-Dee Array Deelemna
Organization: NASA Goddard
Date: Wed, 6 Jan 1993 19:03:55 GMT

I would like to thank those of you who helped me earlier
with my buggy malloctest program that was an attempt at
declaring a two dimensional array on the fly.  Using
your suggestions and corrections, I came up with the
following fragment of code, which runs, and then gets
a bus error (I am curious as to what is causing this
bus error).


PROGRAM: (Corrected as by your mail to me)


In addition, I would greatly appreciate it if someone
could explain (with crude ASCII drawings) *, **, and &.
I find it easiest to learn with drawings when it comes
to pointers (its how I learned PASCAL), but C is a 
new cup of tea, and a picture is worth a thousand words <: 


more malloctest.c
#include <stdio.h>

main ()
{

int i,j;

int nrows, ncolumns;
int **array;               /* 1) corrected, moved from 2) below */

ncolumns = 10;

printf ("Enter array index: \n");
scanf ("%d", &nrows);


array = (int **) malloc (nrows * sizeof(int *)); /* 2) int declaration moved to 1) */
for (i=0; i < nrows; i++)
  array[i] = (int *) malloc (ncolumns * sizeof(int));  /* removed * before last int */

printf ("Reading array values, and printing\n");
for (i=0; i<10; i++)
  for (j=0; j<nrows; j++)
  {
    printf("%d x %d = %d\n",i,j,i*j);
    array[i][j] = i*j;   /* dbx reports this as the location of the bus error */
    printf("%d,%d = %d\n",i,j,array[i][j]);

  }

}

Ok, basically, this is the program.  I moved int **array up with the other declarations,
as you all told me to do, and removed a * before the last int (I would greatly
appreciate a good explanation of why this is so).

Here is the input/output:

a.out
Enter array index: 
3
Reading array values, and printing
0 x 0 = 0
0,0 = 0
0 x 1 = 0
0,1 = 0
0 x 2 = 0
0,2 = 0
1 x 0 = 0
1,0 = 0
1 x 1 = 1
1,1 = 1
1 x 2 = 2
1,2 = 2
2 x 0 = 0
2,0 = 0
2 x 1 = 2
2,1 = 2
2 x 2 = 4
2,2 = 4
3 x 0 = 0
Bus error (core dumped)

What gives here?

Again, I would like to thank those of you who responded and helped with 
debugging this small fragment of code.  Now I am looking for

1) The reason I am getting this annoying bus error.
2) An explanation, with crude ASCII pictures, of *, **, and & in C.
3) An explanation of why | array[i] = (int *) malloc (ncolumns * sizeof(int));
   I was told to remove the star here ----------------------------------^ before int.

I have a few better C books now (went to Crown and picked Crash Course in C
and a Microsoft C book by McGrawHill), and I also have the C bible, though
I am not a computer jock (yet <: ) and its not really for me.  I'd
appreciate any comments or suggestions directly to 

almeida@ame.gsfc.nasa.gov

Thanks!
A. Almeida
Newsgroups: comp.lang.c
From: bandy@netnews.jhuapl.edu (Mike Bandy)
Subject: Re: Any hope for me..? 
Organization: JHU/Applied Physics Laboratory
Date: Thu, 7 Jan 1993 17:01:13 GMT

raph@panache.demon.co.uk (Raphael mankin) writes:

>When I employ programmers I prefer those with a degree in English or History
>or Physics, or anything except CS. They tend to have more rounded knowledge
>and don't think that they know it all.

>My experience of CS graduates is that, by and large, they have read nothing
>and know nothing that was not in their degree course.

I've had the (mis)fortune to work with a lot of EEs who were thrown
into programming without any college computer coursework.  Their attitudes 
are often that they, because they have 'engineering' in their degree, are
better than the computer science types at their tasks.  In reality, they
know little of the basics (data structures, networking, optimization
issues, etc).  Whereas I'm sure that the history major has a more well read
background, he does not have the basic requirements for the job.

Why is it that they'll let anyone program, but let a non-EE major (for 
example) apply for an EE job, and he's eliminated from consideration 
immediately?

-- 

	Mike Bandy
	bandy@aplcomm.jhuapl.edu
	Johns Hopkins University / Applied Physics Lab
Newsgroups: comp.lang.c
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: Debugging with 2 terminals.  HELP!!!!!
Date: Sat, 9 Jan 1993 16:28:52 GMT
Distribution: usa
Organization: TH-Darmstadt

In article <1993Jan8.213710.4079@netcom.com> herring@netcom.com (John Herring) writes:


>   Does anyone know of a debugger that will allow me to run the program on
>   one terminal and debug using the debugger in another terminal?

GDB provides this feature and is available for most ***IX systems.

I debugged a port of GNU-Emacs-18.54 to sysV68 using GDB-3.5.

>   john

best adams
Newsgroups: comp.lang.c
From: hari@blackmail.eng.uiowa.edu (Hari Vattikota)
Subject: Question on malloc
Date: Fri, 8 Jan 1993 01:02:31 GMT
Organization: Department of Elect. and Comp. Engr., University of Iowa, USA.

Hi,

	I have a problem with malloc in my program.
	I have my program split in two files.The first file has the "main"
	routine and several subroutines.One of the subroutines in "main" is
	present in the second file.And when it calls this subroutine from
	the second file it always gives a segmentation fault at the first
	malloc as the malloc returns NULL pointer.Also I do quite some
	memory allocation using malloc in "main" before calling the
	subroutine.Irrespective of the amount of malloc I do before calling
	this subroutine it always crashes at the first malloc in the
	subroutine.I am executing the program on an HP Apollo series 400
	machine and the error message is "Conflicting versions of malloc
	libraries in use" and malloc returns NULL pointer.I've checked the
	pointers.I don't find any type mismatches.
	What might be the cause of the error.Is it malloc or is it something
	else?

	If you have any idea please let me know.
	Thanks.

	Hari.



Newsgroups: comp.lang.c
From: fred@genesis.demon.co.uk (Lawrence Kirby)
Subject: Re: applying or 
Distribution: world
Organization: BT
X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19)
Date: Tue, 5 Jan 1993 10:58:28 +0000

In article <726190196snz@panache.demon.co.uk> raph@panache.demon.co.uk writes:

<stuff deleted>
>The language semantics are defined such that the OR and AND oeprators are 
>sequential. Therefore, if you can *detect* that the order has been changed, the
>compiler may not change the order. If there is no way that you can detect the
>order of evaluation, then what the hell...

I can detect it because it runs faster! :-)

-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------
Newsgroups: comp.lang.c
From: rene@hamel.uucp (Rene Mueller)
Subject: Re: Interesting bug
Organization: Free University of Berlin, Germany
Date: Thu, 7 Jan 1993 00:05:53 GMT

In article <92353.203941SML108@psuvm.psu.edu>, <SML108@psuvm.psu.edu> writes:
|> I had a program with code like
|> 
|> void routine (x)
|> int *x;
|> {
|>   int x;
|> 
|> 
|> }
|> 
|> My compiler did not trap this as an error...  Shouldn't it?  Or at least
|> give a warning?
No, it should'nt give even a warning...
Cause you open a new block with '{', and inside a new block you can define a NEW variable with an 'old' name...
That mean that you will see the functionparameter right after the closing bracket '}', but that's too late....

	rene@math.fu-berlin.de
Newsgroups: comp.lang.c
From: kimball@stsci.edu (Timothy Kimball)
Subject: Re: String function names
Organization: Space Telescope Science Institute
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 4 Jan 1993 14:43:17 GMT

Jerome M Learman (learman@cps.msu.edu) wrote:
: Does anyone know of a string function that converts all letter in the string to
: lower case letter or all capital letter. I could parse the string char by char
: and use a case statment but I really don't want to do this
: 
: ---

Go ahead and parse char by char, but instead of a case statement,
use the standard library functions tolower() and toupper().
They return the lower (or upper) case version of their argument,
and their names are obvious. :^)

tdk
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: NH-- > NH
Date: 9 Jan 1993 04:06:41 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.15

In article <1993Jan9.010946.3172@draco.macsch.com>
dnl@convex.is.macsch.com (David Lombard) writes:
>Never confuse "Gee it works" with "that's the result you should expect."

Indeed.  `Gee, using this nitroglycerin to start the barbecue works
really well!'  Maybe so, but it is *not* recommended.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: rmah@panix.com (Robert Mah)
Newsgroups: comp.lang.c
Subject: Recurring date/times?
Date: 5 Jan 93 03:33:43 GMT
Organization: PANIX Public Access Unix, NYC

Anyone have any suggestions on good data structures for representing 
recurring dates and times.  That is, things like "the first teusday
of every month" or "three days before the end of every month", etc.

I'm looking for something flexible and compact that I can easily check
to see if a given date/time falls on the recurring date/time.

Thanks,
Rob

-- 
[--------------------------------------------------]
[  Robert S. Mah   |  "Every day an adventure,     ]
[  rmah@panix.com  |   every moment a challenge."  ]
[--------------------------------------------------]
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Moving from Pascal to C, Help please!!!!!!
Date: 6 Jan 93 16:56:14 GMT
Organization: AND Software BV Rotterdam

In article <1993Jan6.151028.2055@leland.Stanford.EDU> dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
|In article <4293@dozo.and.nl> jos@and.nl (Jos Horsmeier) writes:

|>Then you've just been plain lucky and so were the authors of NRC.

|My understanding was that Numerical recipes in C used the trick:
|
|#define   Array      (array - 1)
|
|and then indexed the array as Array[1] to Array[n-1].
|
|Yes, array - 1 is illegal. Even when used as Array[1] which
|is the same as *(array - 1 + 1). But even if a system uses
|segments in such a way that array - 1 is not a valid address,
|it is very likely that array - 1 + 1 gives a pointer that
|is represented exactly the same way as array is. Even if pointer
|arithmetic is done using only the offset.

That's what I thought so too, 'till someone pointed out to me that
the pointer (array-1) points _outside_ the object itself (and it
doesn't point one byte beyond the object, which is an exception
to the rule.) All pointer arithmetic, using pointers _not_ pointing
to a valid object cause undefined behavior. Maybe my example where
segmented memory was used wasn't a good example. But consider an
architecture where special pointer registers are used and whenever
such a register is loaded with a new value, a validity check is
done. Loading a register with a value (array-1) can cause a core
dump or whatever ...

|Don't take any of this as an endorsement of this "technique". It
|isn't. I just said that it was not enough to keep me from buying
|the book. It is not something I would ever do in my own code; I
|try to stay out of the areas of undefined behavior.

A very sensible strive! ;-)

kind regards,

Jos aka jos@and.nl
Organization: Penn State University
Date: Mon, 4 Jan 1993 05:13:58 EST
From: <RVK@psuvm.psu.edu>
Newsgroups: comp.lang.c
Subject: Followup on size of executables.

Thanks to everyone who replied to my earlier posting. I
feel, however, that I still need some more clarification.
I was asked what do I mean by a "huge" executable. The
phrase is perhaps inaccurate. I used it only in relative
terms, as illustrated by the example below.

Consider the Hello, World example in assembly (for intel 486):

.MODEL small
.STACK 100h
.DATA
CR EQU 13
LF EQU 10
EOS EQU '$'
HelloMessage DB 'Hello, World',CR,LF,EOS
ExitCode DB 0
.CODE
start:
mov ax,@data
mov ds,ax       ;set DS to point to the data segment
mov ah,9        ;DOS print string function
mov dx,OFFSET HelloMessage ;point to 'Hello World'
int 21h         ;display 'Hello, World'
mov ah,4ch      ;DOS terminate program function
mov al,[ExitCode] ; Exit Code
int 21h         ;terminate the program
END start


and consider the corresponding C fragment:

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

When compiled with MASM 6.0 the hello.asm generated an
executable of size 548 bytes, whereas when compiled with
Microsoft C 7.0 the hello.c generated an executable of
size 6762 bytes.  I agree that the executable generated
by the C fragment is not large, yet when compared to that
generated by the assembly code, it is more than 10 times
larger. It is to this difference that I was refering to.

This brings us to another question: Who cares for a few K's
more or less?

Well, one answer is that suppose I am writing a TSR for a DOS
machine ( I haven't written one yet !) , or for that matter
any low level utility for DOS. There size of executable is of
concern. Another answer is that theoretically the concern is
still valid : why do I have to link with everything that's there
in stdio.h to produce an executable? Note that to write any
reasonably complex program in C one would need to include a
whole lot of other header files too  e.g. stdlib.h, string.h ....
each of which will add to the overhead.

This brings me to my final question: Is there no way other than
programming in assembly, to produce a really small executable?
I would like to use C, but I don't know how (if at all possible)
to do that.


Xref: sparky comp.lang.c:19588 comp.lang.c++:19024
From: cshaver@informix.com (Craig Shaver)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: C/C++ Correctness (was: Re: C/C++ Speed)
Date: 12 Jan 93 17:16:49 GMT
Organization: Informix Software, Inc.

In article <1993Jan11.224238.22152@csservices.Princeton.EDU> blume@kastle.Princeton.EDU (Matthias Blume) writes:
>The question should be: are programs written in C++ more reliable than those
>written in C.  I serioulsy doubt that!
... deleted ...

>The sad truth is, however, that almost everybody seems to believe in C++
>nowadays... :(  C++ will not be the solution to the current software crisis --
>it will be the cause of the next one.

You hit the nail on the head!  C++ is really a niche language that is gaining
momentum on the back of C as an improved C.  The tech #$%@!'s are pushing it 
into low level projects where it does not belong (safety and speed problems), 
and into high level applications where there are not enough bodies that
understand it and can maintain it.  C++ could be used to build tools for 
application programmers, but even that use is dubious IMHO :*].


>
>-Matthias


-- 
Craig Shaver  (cshaver@informix.com for now) (415)390-0654 (415)926-6407
Productivity Group POB 60458 Sunnyvale, CA  94088
Newsgroups: comp.lang.c
From: martink@NeoSoft.com (Martin Koistinen)
Subject: ** in C
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Tue, 5 Jan 1993 03:49:03 GMT

I have a function that needs a 2D array. So I declared it as follows:
 
double *My_Function(double A[3][3])
{
	static double R[3];
      .
      .
      .
   return((double *)&R);
}
 
I have a header file that declares it as:
 
double *My_Function(double **)
 
My code refers to it as:
 
double M[3][3];
double *p;
 
p = My_Function(M);
 
I have two questions:
 
1) Is there any reason why I shouldn't return a pointer to a static from a
function? I realize that I may get bad results if I try to reference the
pointeaafter I do another call to the function or try to use it twice in
the same statement but is there anything else?
 
2) My compiler gives me a warning that I am passing the function something
other then what it wants. Why?
 
My code seems to work great but I feel better when my compiler doesn't
give me warnings. It was my understanding that n Dimensional arrays break
down into pointers (n references).
 
I am curious about the static stuff because I have never seen this done by
others.
 
Please respond via email - Thanks
Martink@neosoft.com
-- 
______
\    / 95 percent of the symbols used in this | Martin J. Koistinen
 \  /  post were made of recycled  characters | martink@neosoft.com
  \/   ----------- Recycle today for tomorrows future -------------
From: shindle@ocf.berkeley.edu (Richard Michael Shindle)
Newsgroups: comp.lang.c
Subject: Help - Linking
Date: 11 Jan 1993 00:48:31 GMT
Organization: U.C. Berkeley Open Computing Facility
Distribution: na
NNTP-Posting-Host: planecrash.berkeley.edu

I work as a part-time programmer at UC Berkeley while I get my degree. I
mainly write subroutines for other people's programs and have little
experience using the C compilers. (I know enough to test my subroutines.)
AT any rate, I was given the job of adding code to an already existing
program that works. They wanted to add a few options. So I added a couple
of lines of code that don't call any functions - they just preform a few
calculations and print it out. However, when I compile this program using
the old Make file I get an error when it tries to link the OBJ and LIB
files. The line that causes the error is 
 link /NOD axes parser wfits werror wexten,,, libw mlibcew, axes.def

The error is that it I have unresolved externals (53 of them). I have no
idea what the error is but I do realize that the unresolved externals are
supposed built-in functions of Microsoft C (5.1) compiler and the
Microsoft SDK. 

I know this may not be enough information for anyone to offer help, but I
do have a file with the error messages given and a copy of the make file
where the error occurs. If you would like to help or know what the problem
is, please email me at 

shindle@planecrash.Berkeley.EDU

If needed I can send the outout with the error messages along with the
make file. Thanks for your cooperation and help.


Mike
shindle@planecrash.berkeley.edu

	x
	x
	axes.def
-- 
Sittin' on the dock of the bay...
Newsgroups: comp.lang.c
From: adam@microware.com (Adam Goldberg)
Subject: Re: Problem with Turbo-C: calculating with pointers
Organization: Microware Systems Corp., Des Moines, Iowa
Date: Fri, 8 Jan 1993 16:17:09 GMT

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:

>#include <alloc.h>

>main()
>{
>char *pointer,*begin,*end;
>long size;

>size=71800;
>pointer=(char *)farmalloc(size*sizeof(char));
>begin=pointer;
>end=pointer+size;
>printf("%p %p %ld",begin, end, end - begin);
>}

>I would expect end - begin to return 71800. However it seems to return 6264.
>This is exactly 64K less.
>If this happens for all pointer calculations, I'm in big trouble.
>Any ideas to solve this.

Huge model normalizes all pointers, which allows you to access a whole
64k area with one pointer (ie, huge_char_ptr[64000]).

Here's what is happening:

pointer=(char *)farmalloc(71800); /* Pointer gets assigned the value 
                                     'seg:0' (where seg is arbitrary).*/
begin = pointer;  /* Ok, no problem so far */
end = pointer+size;  /* Ok, sega:0 + 0:0x11878  BUT WAIT, 0x11878 is
                        > 0xffff, therefore the actual calculation
                        is 'sega:0 + 0x1878', so end is actually pointing
                        to sega:1878 */

printf();  /* Yup, you get 6264 which is 0x1878 */


So, the root cause of this is the bane of all MS-DOS programmers:
  Commandment 1:  You must treat as a special case any accesses to
                  data of length >64k.

No, this does not happen with all pointer calculations--only those
which wrap-around 64k.

(PS: I believe the other responses were in error)

Adam

-- 
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.
Xref: sparky comp.lang.c:19566 comp.lang.c++:18984
From: jeff@emily10.Berkeley.EDU (Jeffrey C. Ely)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Borland example code reusable?
Date: 12 Jan 93 04:13:14 GMT
Distribution: usa
Organization: Dept. of Statistics, U. C. Berkeley
NNTP-Posting-Host: emily10.berkeley.edu

This question could lead to a labyrinth of further questions for which I 
am certain there is no one reasonable answer, but maybe some of you have
some information on the matter:  is the purchaser of Borland C++ implicitly
authorized to reuse the sample code supplied in the examples directories?
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: **BOOKS TO LEARN C: SUGGESTIONS NEEDED**
Date: 10 Jan 93 21:26:25 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Distribution: usa
Organization: University of Arizona

In article <eaeu209-090193013620@714-725-3177.nts.uci.edu>, eaeu209@orion (Rodney G. Ramos) writes:
>I've recently been interested in learning C. Can anyone suggest a good book
>to get me started?

Isn't this in the FAQ?  If it isn't, it should be.

>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.

The canonical text is _The C Programming Lanugage_ (2nd ed) by Kernighan
and Ritchie (ISBN 0-13-110362-8).  This is pretty much a dive-right-in
book which is probably best for those already familiar with similar
langauges like Pascal.

_A Book on C_ by Kelley & Pohl (now in the 2nd edition, I think) has been
often recommended as a text better for "beginner" programmers.

_C: A Reference Manual_ by Harbison and Steel (ISBN 0-13-110933-2) is
an excellent reference, and worth buying for any serious C programmer.

-- 
Yeah, right.
Newsgroups: comp.lang.c
From: rjf@lincroftnj.ncr.com (51351[efw]-Robert Feddeler(MT4799)T343)
Subject: Re: Problem with string processing.
Organization: AT&T/NCR, Lincroft, NJ, USA
Distribution: usa
Date: Thu, 7 Jan 1993 18:45:18 GMT

In article <Ts3TwB1w165w@wozzle.linet.org> alane@wozzle.linet.org (J. Alan Eldridge) writes:
>oleary@staff.tc.umn.edu writes:
>
>> A much better version is:
>>  
>> void add_char_to_str(char ch, char *str)
>> {
>>         char tmp[2] = {0};
>>  
>>         *tmp = ch;
>>         strcat(str, tmp);
>> }
>>  
>
>Oh, dear.
>
>tmp[0] has a 0 in it but tmp[1] is undefined. You are not creating
>a nul-terminated string here.
>
>If you'd said tmp[2]={0,0}; then all would be well on that front.


And if you wanted to write it so that the implementation
"looks just like the problem", you would write:

void add_char_to_str(char ch, char *str)
{
	int	l;

	l = strlen(str);
	str[l++] = ch;
	str[l] = 0;
}

Highly readable, ultimately efficient (strcat() has to do a strlen()
internally), and you don't have to worry about what the compiler is
going to do with the initializer on the automatic.


bob.			| Heap big trouble in the land of plenty.
Were these more than just my opinions, they would have cost a bit more.
Newsgroups: comp.lang.c
Subject: Re:  String function names
From: alien@acheron.amigans.gen.nz (Ross Smith)
Date: 3 Jan 93 13:19:20 GMT+12
 <1993Jan1.032304.14636@organpipe.uug.arizona.edu> <1i0fcaINNgqd@msuinfo.cl.msu.edu>
Distribution: world
Organization: Muppet Labs

In article <1i0fcaINNgqd@msuinfo.cl.msu.edu> learman@cps.msu.edu (Jerome M Learman) writes:
>Does anyone know of a string function that converts all letter in the string to
>lower case letter or all capital letter. I could parse the string char by char
>and use a case statment but I really don't want to do this

There isn't a standard function for this. The simplest solution is
something like this :

void upstring(char *str)
  {
  char *cptr;
  for (cptr = str; *cptr; cptr++)
    *cptr = toupper(*cptr);
  }

... and similar for lower.


--
...... Ross Smith (Wanganui, NZ) ...... alien@acheron.amigans.gen.nz ......

"I blame you for the moonlit sky and the dream that died with the Eagle's flight
I blame you for the moonlit nights when I wonder why are the seas still dry
Don't blame me, sleeping satellite"                              (Tasmin Archer)

--

Newsgroups: comp.lang.c