HDTenEightyP/NetNews huggingface dataset:
From: jwfourie@rkw-risc.cs.up.ac.za ()
Subject: Borland C++ 3.0 strncpy - Is there something wrong?
Summary: Is there something wrong with strncpy (Borland C++ 3.0)
Date: 29 Sep 92 20:05:37 GMT
Organization: University of Pretoria, South Africa
Keywords: strncpy

I used strncpy in a program to copy a substring of a string into another one.
The strings was declared like this:
unsigned char buf[2000];
unsigned char src_ad[4];
After reading some values into buf I wanted to copy the 4 values from
index 12 i.e. buf[12] to buf[15] into src_ad.
I used:  strncpy(src_ad,(unsigned char *)(buf+12),4)
this worked well until a value of 0x03 occurred in buf[15]
then the value of 0x00 where copied in src_ad[4] instead of 0x03
the same happened with a vaule of 0x01 in buf[15]

I have no explanation other than strncpy has to have a bug. I did not yet
looked at the assembler code.

I used memmove(src_ad,buf+12),4) and this worked correctly.

I had the same problem with strncmp.

Is there anybody out there which can share a little bit of light on this
matter.

I would greatly appreceate it if anybody who does reply to this article forward
the reply to me by eMail 'cause or news is whiped every 24 hours and I'm not in a possition to read the news every day.

Thanx
------------------------------------------------------------------------------
Johann W. Fourie    eMail: jwfourie@rkw-lan.cs.up.ac.za|  I'd rather be C-ing
                                                       |  than Wirth
-----------------------------------------------------------------------------
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: 'make' woes (won't catch secondary dependancy)
Date: 2 Oct 92 15:32:15 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <774@rc1.vub.ac.be>, apardon@rc1 (Antoon Pardon) writes:
>make that
>
>h1.h: h2.h
>	touch h1.h
>
>That ought to work

It'll work, but IMHO, it can be a pain in the @$$ for those of use who
use emacs.  You run M-x compile, h1.h gets `touch'ed.  Then, a little
later, you decide you want to change something in h1.h, and all of a
sudden you're hit with

  File changed on disk; really want to edit the buffer? (y, n, or C-h)

Obviously, this is not a message you want to get into the habit of
ignoring, so punching `y' every time it comes up is NOT a good idea.

IMHO, this is a bug in the specification of "make" that you need to
update the target file in order to propigate changes down the dependency
list.  There should really be a way to propigate changes based soley on
the files the target is dependant on.

Disclaimer: I am not a "make" guru; there might be some way to do this
with current "make"s; if there is, I'd be more than happy to here about it.

-- 
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!
From: Aurelius@cup.portal.com (Mark Christian Barnes)
Newsgroups: comp.lang.c
Subject: Re: Differences between ANSI C and VAX C
Date: Sun, 27 Sep 92 22:23:23 PDT
Organization: The Portal System (TM)
Distribution: na
  <1992Sep24.103945.131031@mswe.dnet.ms.philips.nl>

| Don't try something like
|     typedef void (*FP)( short, float);
|     FP fp3 = appropriate_function;
|     (*fp3)( 10, 2.7); 
| because 'appropriate_function', if defined in ANSI-style, will not expect
| promoted arguments, but the call to (*fp3) will apply K&R-type promotion.
| Kind regards,  
|     Vic Hartog

 I beg to differ here Vic. I have been writing such code with VAX C v3
for a couple of years now. The parameter types are consistant between
the function pointer invocation and the actual function.

 It is true however, that a function pointer type, without parameter
prototypes, will widen its parameters. I believe this is ANSI behaviour.

typedef void (*FP)(); /* parameters, if any, treated in the K&R style */
                      /* this is generally *bad*, always declare a    */
                      /* function pointer with prototyping info.      */

FP pFunc = prototyped_func; /* say void func( short, float ); */

(*pFunc)( 10, 2.7 ); /* 10 is a long, 2.7 is a double, regardless of  */
                     /* any prototype information for prototyped_func */
                     /* of course this *may* produce errors, BEWARE   */

			Regards, Aurelius@cup.portal.com
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: ++i = i++ ?
Date: 28 Sep 92 22:56:53 GMT
Article-I.D.: ima.1992Sep28.225653.395
Organization: Formerly of Interactive Systems, Cambridge, MA

In article <zxmgn01.717703161@mailserv> zxmgn01@mailserv.zdv.uni-tuebingen.de (Philipp Knirsch) writes:
>++i = i++;
>
>Hehehe.. Which value has i when it is first 0 after this line of correct 
>C-Code??

I was hoping that my own article would preempt nonsense of this sort, but
apparently I wasn't quick enough.

>Perhaps i am wrong, but something nice to think about and to test and look
>what the compiler is doing :)

I think you should spend less time looking at what your compiler is doing, and
spend more time studying the C language.  (Try the FAQ list for a good start.)

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.lang.c
From: Nico Tranquilli
Subject: Re: Memory Allocation Question
X-Xxmessage-Id: <A6F0B3A4CC020B1A@mac1.di.unipi.it>
X-Xxdate: Thu, 1 Oct 92 12: 54:44 GMT
Organization: Computer Science Dept. , University of Pisa
X-Useragent: Nuntius v1.1.1d9
Date: Thu, 1 Oct 1992 13:07:30 GMT

In article <1992Oct1.061758.23927@cs.rose-hulman.edu> , Elvis
P.@graceland.rock.and.roll writes:
>I have a thing that I want to allocate memory for as follows:
>
>	int *thing[2];
>
>First of all, I think this means an array of how ever much space I  
>allocate, with 2 fields.
>ie.  thing[100][0] and thing[100][1]
>
>Well, how do I allocate memory for it?

int *thing[2] stands for a vector of 2 pointers to int. When you need
dynamic allocation, invoke calloc function. As calloc returns a pointer
to void (or somewhere to char), make a cast.
i.e.:
	   thing[0]=(int*)calloc(100,sizeof(int));
     thing[1]=(int*)calloc(100,sizeof(int));
When you no longer need that space:
	   free(thing[0]);
     free(thing[1]);

Nico.
From: mikey@ontek.com (euphausia superba)
Newsgroups: comp.lang.c
Subject: Re: ++i = i++ ?
Date: 29 Sep 92 17:33:39 GMT
Organization: Ontek Corporation -- Laguna Hills, California

WARNING: Nitpick alert!  Nitpick alert!

In comp.lang.c, hollasch@kpc.com (Steve Hollasch) writes:
| 
| ...For example, the statement
| 
|         frotz;        // Let's say frotz is an integer.
| 
| is a valid statement in C.  'frotz' is implicitely compared with 0, and then
| the result (true or false) is discarded.  The net effect of this statement is
| nil, and you could delete this statement or add 50 more like it without
| any difference in execution (a smart compiler would delete these statements
| anyway).  Note that the above statement has no side effects.

I don't recall ever seeing any mention of expression statements being 
compared with zero before being thrown away.  K&R2 Section A9, pg 222:

    "Statements are executed for their effect, and do not have values."

The more specific definition of expression statements (A9.2) does not
alter this wording.

Perhaps you are thinking of the controlling expressions in while, for, 
or if statements, in which the expression definitely is compared with 
zero, although it is not thrown away in those cases.

      the krill, "volatile int frotz;"
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: NO NUMBERS! (or even SHORT INTS!)
Date: 5 Oct 92 23:51:57 GMT
Organization: negligable

I would have to agree.  Instead of getting more complex w/ all these
planetary calculations, where symbolic constants definately make more
sense, let's get simpler:

	for (i=1; i<MAX_STUDENTS; i++)
		{
		}

I do use the symbolic constant (if not a variable) for the END condition of
the loop, but I see no reason for any symbolic definition of the START
of this loop.  As someone pointed out, it is bad form to do:
	#define ONE		1

And I don't see anything more fitting.  And if the argument goes
"you should use a '#define FIRST_STUDENT	1'"  I pre-reply "but
what about all those other "firsts?"  (SITES, EXAMS, QUESTIONS, etc.)
do I have a dozen lines looking like:
	#define FIRST_SITE	1
	#define FIRST_STUDENT	1
	#define FIRST_QUESTION	1
	#define FIRST_QUIZ	1
	.....

IMHO that is both overkill and ridiculous.


I'll give you that constants of any significance should be symbolic,
but in this case there is no special significance to "1".  (of course
this does go along w/ the earlier post stating that you should not have
any numbers other than "0" "1" and "MANY" ... if you can say that "MANY"
means "any symbolic constant"...)




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Work away today, think about tomorrow.		|
Never comes the day, for my love and me.	|	-Richard Hartman	
I feel her gently sighing			|	hartman@uLogic.COM
as the evening slips away....			|

Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Probably a simple realloc() question
Organization: TauMetric Corporation
Date: Fri, 2 Oct 1992 16:04:20 GMT

ark@alice.att.com (Andrew Koenig) writes:

>Suppose further that your system provides no way to shrink the size
>of an allocated block.  If your user requests such shrinkage, you
>really have only two choices:

>	1. Don't return any memory to the system, but lie and tell
>	   the user you did, or

>	2. Allocate new memory, copy the stuff, then free the old.

But there is no promise that realloc() will return unused memory to
the system.  It is not required by the C standard, for example.  If
realloc() just returns the original pointer when asked to shrink the
allocation, it is not lying to the user, since there was no promise
about returning memory in the first place.

By way of analogy, the C standard does not require free() to return
memory either.  Furthermore, free() does not return a value, so
there is not even a way for it to indicate that it did not return
memory (short of setting errno, which is allowed but not required).
If free() does not indicate a failure to return memory, why should
one expect realloc() to do so?

If a given implementation of realloc() promises to return memory,
that is a different matter.  Users should not depend on this behavior
in the absence of explicit documentation, however.

We must bear in mind that malloc/calloc/realloc/free are intended
as general-pupose memory management routines.  The implementor of
the C library must evaluate many conflicting requirements and try
to find a balance between fast operation and efficient use of memory.

Some applications require speed and have no concern about running out
of memory.  Others require extreme memory conservation measures and
don't care how long memory allocation takes.  No one strategy can
satisfy both kinds of programs.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Organization: University of Illinois at Chicago
Date: Sunday, 4 Oct 1992 16:49:51 CDT
From: <U37956@uicvm.uic.edu>
Newsgroups: comp.lang.c
Subject: Freeing dynamic allocated memory

Suppose I dynamically allocated a chunk of memory using malloc() in a function,
but I do not free it when exiting the function. Will the system automatically
do the garbage collection for me? If not , can I use the original data in the
memory if the function is re-entered ?

This is a question I have been wondering for a long time. Maybe some of you
think it is a very easy problem.
From: hjv@phil.ruu.nl (Hendrik Jan Veenstra)
Newsgroups: comp.lang.c
Subject: Re: Memory Allocation Question
Date: 1 Oct 92 12:58:57 GMT
Organization: Department of Philosophy, University of Utrecht, The Netherlands

Elvis P.@graceland.rock.and.roll writes:


>I have a thing that I want to allocate memory for as follows:

>	int *thing[2];

>First of all, I think this means an array of how ever much space I  
>allocate, with 2 fields.
>ie.  thing[100][0] and thing[100][1]

>Well, how do I allocate memory for it?

It looks like you mean you want toi malloc room for two int-pointers, but
I suppose that's not really what you mean :) If you want two arrays of ints,
pointed to by thing[0] and thing[1], you could do:

    #define WANTED_SIZE 100

    thing[0] = (int *) malloc(WANTED_SIZE*sizeof(int));
    thing[1] = (int *) malloc(WANTED_SIZE*sizeof(int));

Now you can address thing[0][0]-thing[0][99] and thing[1][0]-thing[1][99].

If you want to have a 'one block' of memory, you could do:

   thing[0] = (int *) malloc(2*WANTED_SIZE*sizeof(int));
   thing[1] = &thing[0][WANTED_SIZE];

I don't say this is 'beautiful' coding... :)
Don't forget to free the allocated memory once you're done with it (e.g. upon
exiting the program). In the first case this would require
   free(thing[0]);
   free(thing[1]);
In the second case, you'd only have to free(thing[0]);
Hope this helps.


--
Hendrik Jan Veenstra  |   hjv@phil.ruu.nl   |   You look for your dreams in
Dept. of Philosophy   |                     |   heaven, but what the hell are
University of Utrecht |                     |   you supposed to do when they
The Netherlands       |                     |   come true...?
Newsgroups: comp.lang.c
From: adam@microware.com (Adam Goldberg)
Subject: Re: ++i = i++ ?
Organization: Microware Systems Corp., Des Moines, Iowa
Date: Thu, 1 Oct 1992 13:13:27 GMT

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

>The expression results you keep referring to as boolean (true or false) and
>discarded are actually int and discarded.  e.g. for the statment:
>	i;

>where i has the value of 5, the statement value is 5, not "true".

>not that this affects the original question any....

Not exactly.  According to my K&R (2nd ed), Section A9.4:

     In both forms of the if statement, the expression, which must have
     arithmatic or pointer type, is evaluated, including all side-effects,
     and if it compares UNEQUAL TO 0, the first substatment is executed
     [the if clause].  In the second form [if..then..else], the second
     substatement is executed if the expression IS 0 [the else clause].
     [emphasis added].

To my reading, 0 is defined as false, and != 0 is defined as true.


-- 
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.
Newsgroups: comp.lang.c
From: amorgan@Xenon.Stanford.EDU (Crunchy Frog)
Subject: Re: Freeing dynamic allocated memory
Organization: Computer Science Department, Stanford University.
Date: Mon, 5 Oct 1992 03:06:07 GMT

In article <92278.164951U37956@uicvm.uic.edu> <U37956@uicvm.uic.edu> writes:
>Suppose I dynamically allocated a chunk of memory using malloc() in a function,
>but I do not free it when exiting the function. Will the system automatically
>do the garbage collection for me? 

Christ, I hope not.  I think every C program would stop working if it did.  
It isn't even required to release it when the program is done (although 
UN*X does this for you).  If you really want something that does this check 
out GNU's alloca() (although it is pretty flakey I understand). 

>If not , can I use the original data in the
>memory if the function is re-entered ?

Yep.  You don't even need to wait until the function is re-entered.  You
can pass a pointer to the block back to the calling function and use it
anywhere.

C Frog
From: phd85@seq1.keele.ac.uk (D.H. Holden)
Newsgroups: comp.lang.c
Subject: Linking maths library -lm
Date: 29 Sep 92 17:03:24 GMT
Organization: Keele University, England

From article <pal.717774974@regent.e-technik.tu-muenchen.de>, by pal@regent.e-technik.tu-muenchen.dbp.de (Peter Loibl):
> dalessan@clam.rutgers.edu (Gene Dalessan) writes:
> 
> 
>>#include <math.h>
>>#include <stdio.h>
>>main()
>>{
>>double val=-1.0;
> 
>>do {
>> printf("hyperbolic cos %f is %f\n",val,cosh(val));
>> val +=0.1;
>> } while (val<=1.0);
>>}
> 
> 
>>PLEASE help...Why do I get undefined _cosh?
> 
>>I'm learning C know and this example is out of the book.
>>I need the cosh for a numerical meth problem.
> 
>>Gene
> 
> Well, you probably forgot to link the math library. If you are
> working on a UNIX machine it looks like this:
> 
> cc myprog.c -lm -o myprog
> 
> -lm will link the math-lib and -o will name the binary file as myprog.
> 
> If you work on another machine, then you will have to look up how 
> to set the compiler options.
> 
> Peter
> pal@regent.e-technik.tu-muenchen.de

    I dont seem to be the only one with this problem
    surely this should be a FAQ.


	   Dave.

--
Dave.
phd85@uk.ac.keele.seq1
Newsgroups: comp.lang.c
From: kferg@vpnet.chi.il.us (Kevin Ferguson)
Subject: Re: Memory leak detectors: references?
Keywords: References to publications on memory leak detectors
Organization: Vpnet Public Access
Date: Thu, 01 Oct 1992 18:59:54 GMT

In article <333@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>
>I believe a couple of macro sets have been published in the
>computer magazines -- Dr. Dobbs Journal comes to mind.
>
>I think they are available in the DDJ forum on CompuServ,
>but I couldn't tell you the issue date....
>

Try  Aug, Sep, or Oct of '90.  I have files dated Nov 90 named
MSHELL, MEMTRACK, and XMEM.  Obviously, my file dates are when I
downloaded them, not the issue date.

luck,
kevin


Newsgroups: comp.lang.c
From: ibe1109@draper.com (Ira Ekhaus)
Subject: numerical extensions to  ANSI C , status?
Organization: Draper Laboratory, Inc., Cambridge, MA
Date: Mon, 28 Sep 1992 18:55:00 GMT

HI,

I've  heard rumours of this  beast.
It would allow Matlab or APL style vector calls
within a C routine.

For example with  matrices a,b,c already defined:
c(3,:) = a(:,1)*b(:,2);
The third row of  c is the product of the 1st column of 
a with the second column of b.


Is there a mailing list for the status of this standard, and
where can I get additional information.

thanks,

Ira
ekhaus@draper.com
Phone: 617 258 1109
Draper Laboratories m.s. 7c
555 Technology Square
Cambridge , MA 
02139
From: mcs@goblin.caltech.edu (Martin Shepherd)
Newsgroups: comp.lang.c
Subject: Untyped pointer arithmetic
Date: 30 Sep 1992 20:55:11 GMT
Organization: California Institute of Technology
Distribution: world
NNTP-Posting-Host: goblin.caltech.edu

Is there any way to do anonymous pointer arithmetic portably?

What I need to be able to do is best explained with the following bit
of illegal code.

void *ptr_array[NUM_PTRS];
int ptr_increments[NUM_PTRS];
/*
 * Copy (cast) typed pointers into the void *ptr_array[] array.
 */
.
.
/*
 * Calculate "byte" increments required to increment each
 * pointer by a multiple of the size of the original typed pointer.
 */
.
.
/*
 * Increment each typed pointer via an anonymous array.
 */
for(i=0; i<NUM_PTRS; i++)
  ptr_array[i] += ptr_increment[i];

I realize that the above code would not even compile, given that
address arithmetic is illegal on 'void *' pointers, but could somebody
suggest an alternative portable way to do this.

At the moment I do it by using a 'char *' in place of the 'void *' but
I am concerned that this will fail on machines where 'char *' and
the pointers of other types have different sizes or alignment
constraints.

For those who want to know why one would want to do this, I have an
interactive language that optimizes multi-dimensional array arithmetic.
In elemental array expressions, pointers into any arrays in the
expression all have to be incremented at the end of each element for
each dimension. The speed with which this is effected is critical to
the speed of expression evaluation so I would like to avoid switch
statements and type fields at this point. (Of course type fields have
to be used when the expression is compiled in order to work out the
increments in bytes, but speed is not critical at that point).

Any suggestions?

Martin Shepherd   (mcs@phobos.caltech.edu)
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: ANSI behaviour for casting double to long
Keywords: ANSI double long cast
Organization: TauMetric Corporation
Date: Tue, 6 Oct 1992 15:21:51 GMT

baillie@munta.cs.mu.OZ.AU (Stephen Baillie) writes:

>K&R states that casting a float to an int will cause truncation
>of any fractional part of the float, but fails to mention what
>happens to overly large floating point numbers when they are
>cast to integral types. ...
>Obviously I have now put in a check for this overflow condition,
>but I was wondering if anyone had any ideas as to what is
>supposed to happen?

The results are undefined if the floating value is too large to fit
in the integral type.  This means that the C implementor is under no
constraints whatever in this regard.  So, yes, you must check for
overflow if you care what happens.  For example:

	if( fabs(f) < MAX_INT )
	    i = f;
	else
	    ... overflow


>"If we shadows have offended, Think but this and all is mended:
> That you have but slumbered here, While these visions did appear.
> And this weak and idle theme, no more yielding but a dream."

This is certainly a classier .sig than the usual quotes from
spoiled teen-agers in a haze of drugs masquerading as musicians.
Thanks for raising the tone of this news group!
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: mcs@goblin.caltech.edu (Martin Shepherd)
Newsgroups: comp.lang.c
Subject: Union-initialization portability
Date: 1 Oct 1992 08:45:48 GMT
Organization: California Institute of Technology
Distribution: world
NNTP-Posting-Host: goblin.caltech.edu

First, thanks to dkeisen@leland.stanford.edu,msb@sq.com and
ok@goanna.cs.rmit.oz.au who replied to me regarding untyped pointer
arithmetic. (char* pointers can be portably used for byte pointer
arithmetic on anonymous pointers).

I now have another portability question concerning union initialization.

The ANSI-C spec describes union initialization, saying (actually from
K&R2) "The initializer for a union is either a single expression of the
same type, or a brace enclosed initializer for the first member of the
union".

In the following example I make the first member of the union a void *
pointer so that any pointer can be used to initialize the union.

typedef enum {FLOAT_PTR, INT_PTR, CHAR_PTR} VarType;

struct Descriptor {
  char *name;
  VarType type;
  union {
    void *init;  /* The initialization field of the union */
    int *iptr;
    float *fptr;
    char *cptr;
  } valof;
};

As an example of its use one might have the following initialization:

float float_array[20];
char char_array[9];
float fvar;

#define NUM_VAR 3
struct Descriptor test[NUM_VAR] = {
 {"farray", FLOAT_PTR, {&float_array[0]} },
 {"cvar",   CHAR_PTR,  {&char_array[0]}  },
 {"fvar",   FLOAT_PTR, {&fvar}           }
};

Then later access the first element of the actual variables as:

  for(i=0; i<NUM_VAR; i++) {
    switch (test[i].type) {
    case FLOAT_PTR:
      printf("Variable %s=%f\n", *test[i].valof.fptr);
      break;
    case CHAR_PTR:
      printf("Variable %s=%c\n", *test[i].valof.cptr);
      break;
    case INT_PTR:
      printf("Variable %s=%d\n", *test[i].valof.iptr);
      break;
    default:
      fprintf(stderr, "Unrecognised variable type\n");
      break;
    };
  };

My question: Should this work, given that one is not actually casting
the void * pointer back to the required type, but simply accessing
it through union'd members? (It does work on a sparc). If not, is
there another way to achieve this, or should I use a function call
such as:

  init_variable(&test[2], "fvar", FLOAT_PTR, &fvar);

prototyped as:
init_variable(Descriptor *dsc, const char *name, VarType type, void *valof);

to cast the 'void *valof' pointer in its argument list to the correct type?

(The above examples have not be tested - the real code from which this
was derived is somewhat more complex and not suitable for posting).

Any help would be appreciated.

Martin Shepherd  (mcs@phobos.caltech.edu)
Newsgroups: comp.lang.c