HDTenEightyP/NetNews huggingface dataset:
From: steve@taumet.com (Steve Clamage)
Subject: Re: Strings and integer sizes
Organization: TauMetric Corporation
Date: Tue, 13 Oct 1992 15:44:48 GMT

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

>:I agree when you say that zoe[3]= "abc"; is an erroneous initializer
>:when you want to store a _string_ in the array, but otherwise this
>:is all perfectly legal. The ANSI-C standard even states this explicitely
>:in paragraph 3.5.7 Initialization.

>Unfortunately this is correct.  Stupid and misleading, but correct.

>Another thing we can thank the standards committee for....

According the Rationale in the ANSI C Standard, this was existing
practice in some widely-used compilers.

If X3J11 had made |zoe[3]="abc";| illegal, someone else would be saying,
"Stupid and misleading, another thing we can thank the standards
committee for ..."

Two things I have learned in doing standards work:

1.  Some people like to complain about a standard without reading it
    to find out what it actually says.

2.  No matter what you decide, some people will complain loudly about
    how you have ruined the language.

The particular problem faced by X3J11 (the ANSI C Committee) was trying
to reconcile mutually incompatible implementations of C, none of which
violated K&R1.  No one decision could satisfy everyone.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c
From: fnorero@lascar.puc.cl (Fernando Norero (Ayudante dcc))
Subject: Help: Free() in Borland C++2.0
Organization: Pontificia Universidad Catolica de Chile
Date: Tue, 6 Oct 1992 21:21:56 GMT


	Dear Hackers:

	I'm working with Borland C++ 2.0 and I'm working in a program that
uses a lot of heap space, I have many problems with malloc() and free()
functions. I knew free() function sometime doesn't work. .

My question is:
	Has anybody developed a memory management routine, or something like
a heap garbage colector? Could you please help me?

	Thank you very much for your help.

	fnorero@lascar.puc.cl
	greetings from Chile.








Newsgroups: comp.lang.c
From: runeh@dhhalden.no (RUNE HALFDAN HOLST HUSEBY)
Subject: Re: Returning an array from a function -> How to?
Organization: Ostfold College
Date: Sat, 10 Oct 1992 23:43:24 GMT

In article <BvxErG.MCA@news.cso.uiuc.edu> msr52148@uxa.cso.uiuc.edu (Shepard) writes:
>From: msr52148@uxa.cso.uiuc.edu (Shepard)
>Subject: Returning an array from a function -> How to?
>Date: Sat, 10 Oct 1992 22:06:50 GMT
>I am fairly new to C, and I want to write a function that returns an array. 
>I would like to avoid passing in pointer to an empty array and modifying it
>that way.  I need one function that generates a table of integers dependent
>on an string/array of characters which is passed in as an argument.  I've 
>tried every arrangement of pointers and definitions I can think of, but nothing
>seems to work.  What I'm aiming for is something like this:
>
>int maketable(char *string)
>{
>   int table[xxx];
>   .
>   .
>   .
>   return (table);
>}
>
>main()
>{
>  int maintable[xxx];
>
>  maintable=maketable("TestString");
>}
>
>I'm sure this must be possible somehow, but I've spent the past two days 
>messing with pointers to this and that and nothing seems to work.  Any
>suggestions?  Thanks in advance!
>
>			Mike Root
>			msr52148@uxa.cso.uiuc.edu

Try this:

int maketable(char *string)
{
  int *table;
  
  /* you need the create space on the global heap */
  table = (int *) malloc(size_of_array * sizeof(int));
  if(table == NULL)
  {
  /* an error has occured */
    return ERROR
  }
  .
  .
  .
  return table;
}

main()
{
  int *maintable;
  
  maintable = maketable("Teststring");
  .
  .
  .
  .
  /* remember to free what's malloc'ed */
  free(maintable);
}


Hope this helps.

                               }  } {  {
/-------------------------------}  }  { /----------------------------------\
| Rune Halfdan Holst Huseby      }  {  |  S-Mail: Atomveien 18             |
|  ____________________________   }{   |          1777 HALDEN              |
| (_____(_runeh@dhhalden.no____###)    |          NORWAY                   |
|-------------------------------------/ \----------------------------------|
| Real programmers never work 9 to 5. If any real programmers are around   |
| at 9 am, it's because they were up all night.                            |
\--------------------------------------------------------------------------/

Newsgroups: comp.lang.c
From: bill@chaos.phys.ualberta.ca (Bill Burris)
Subject: multidimensional arrays as parameters
Reply-To: bill@chaos.phys.ualberta.ca (Bill Burris)
Organization: University Of Alberta, Edmonton Canada
Date: Tue, 13 Oct 1992 22:49:18 GMT

I was wondering how to pass a multidimensional array as a parameter.

For a 1D array I do the following:

void function( int * );

int array[10];

main()
{
    function( array );
}

void function( int *data )
{
    ...
}


Now for a 2D array if I do the following:

void fun2d( int * );

int array2d[10][20];

main()
{
    fun2d( array2d );
}

void fun2d( int *data2d )
{
    ...
}

I get a warring from the compiler for the parameter in the call
fun2d( array2d );

Bill
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Strings and integer sizes
Date: 9 Oct 92 07:44:49 GMT
Organization: University of Helsinki

hartman@ulogic.UUCP (Richard M. Hartman) writes:
>It is erroneous. "123" is a character array constant of four characters,
>'1', '2', '3', '\0'.  Attempting to inialize an array of [3] with this
>is erroneous.   "123" would be a proper initializer for an array of size
>[4] or above.

No.  Wrong.  Please read this part again (which you quoted):

>:Have a look at ANSI-C 3.5.7 Initialization:
>:
>:`An array of character type may be initialized by a character string
>:literal, optionally enclosed in braces. Successive characters of the
>:character string literal (including the terminating null character
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>:if there is room or if the array is of unknown size) initialize the
  ^^^^^^^^^^^^^^^^
>:elements of the array.'

The initialization

	char zoe[3] = "abc";

there is _not_ room for the terminating null character, so it is _not_
copied, but the initialization _is_ legal nevertheless.  Not necessarily
a good idea (the manually computed 3 may be a mistake and should often
be 4, or preferably the size should not be given at all), but definitely
legal.  The result is that zoe[0]='a', zoe[1]='b', and zoe[2]='c'.

Would it be a good idea to check the facts before posting?  Nah, then
one doesn't have time to post a followup to every new article. ;-)

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
Newsgroups: comp.lang.c
From: tsmith@csugrad.cs.vt.edu (Townsend Smith)
Newsgroups: comp.lang.c,comp.lang.misc,comp.programming
Subject: Random # Analysis algoright WANTED
Date: 12 Oct 92 16:27:46 GMT
Organization: Virginia Tech Computer Science Dept, Blacksburg, VA

I am looking for an algorithm / statistical calculation etc
that can be applied to a list of numbers to determine if they are
random, etc.  

Any references or comments would be appreciated,
Jack
tsmith@csugrad.cs.vt.edu  <-- internet mail

-- 
tsmith@csugrad.cs.vt.edu
Computer Engineering and Computer Science at Virginia Tech
Newsgroups: comp.lang.c
From: bubeck@peanuts.informatik.uni-tuebingen.de (Till Bubeck)
Subject: Re: Question about fread() and fwrite()!
Organization: "Lehrstuhl fuer Technische Informatik, Uni Tuebingen"
Date: Fri, 16 Oct 92 12:50:19 GMT

In article <1bl70vINN2o3@miles.mps.ohio-state.edu>, ren@miles.mps.ohio-state.edu (Liming Ren) writes:
|> I write a short program to test fread() and fwrite(), I don't get what I want and I can't figure out why. Please help.
|> 
|> I use fwrite to write a struct to a file, then fread it from the file. I don' get
|> the same object. Can somebody nice to explain the behavior of fread and fwrite?
|> For example, fwrite writes which member first and in which order.
|> 
|> Another question is: Is the size of a structure  the summation of all the size of its elements? If not, any formula for it beside using sizeof()?
|> 
|> The output from my program is:
|> 
|> 0  0  
|> 1  0  
|> 2  0  
|> 3  0  
|> 
|> 
|> #include<string.h>
|> #include<stdio.h>
|> 
|> typedef struct words_record{
|>   char rw[4][12];
|>   int tf[4]; 
|> } wr;
|> 
|>   
|> FILE *ptr;
|> 
|> main()
|> {
|>   int i;
|>   wr *p, temp, temp2;
|>   for(i=0; i<4; i++)
|>     {
|>       strcpy(temp.rw[i], "hhh");
|>       temp.tf[i]=i;
|>     }
|>   ptr=fopen("data2", "wr");
|>   fseek(ptr, 0L, 0);
|>   p=&temp;
|>   fwrite(p, sizeof(wr), 1, ptr);
|>   p=&temp2;
|>   fread(p, sizeof(wr), 1, ptr);
|>   fclose(ptr);
|>   for(i=0; i<4; i++)
|>     {
|>       printf("%d  %d  %s\n", i, temp2.tf[i], temp2.rw[i]);
|>     }
|> 
|> }

Hi, 

I hope I can help you a little bit...

First of all, you should open then file in binary mode, 'cause you're writing
binaries (not ascii). This makes no differences on Unix Systems, but maybe you
are using DOS or anything else (which uses CR/LF instead of only \n). This means:
ptr=fopen("data2","rwb"); 

Then you are reading after the end of file... First you are writing your
structure, then (without any fseek to the beginning of the file) you are reading
into temp2. This results in reading nothing into temp2 -> temp2 is zero at all.
Did you maybe send us the wrong code? You did the fseek after opening the file,
but the filepointer is already at the beginning of the file after opening....

Now your program should work(?)...

Your second question...The size of a structure is not necessary the sum of its
elements... Sometimes compilers are doing some alignment. The only way to get the
size of a struct is to use sizeof(). Why do you need another way?

Hope I helped you....

     Till Bubeck, University of Tuebingen, West-Germany
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Newsgroups: comp.lang.c
Subject: Re: "Illegal Pointer Arithmetic" error
Date: 11 Oct 92 16:01:17 GMT
Distribution: usa
Organization: Computer Science, University of Melbourne, Australia

byron@cc.gatech.edu (Byron A Jeff) writes:

>dmills@accvio.intel.com (Dave Mills) writes:
>>>------------->	     *buf++=NULL;
>>
>>There's a difference (noted in the FAQ, I presume) between NULL and NUL.  Your
>>"while(buf!=NULL)" refers correctly to a "NULL pointer".  "*buf++=NULL;",
>>though doesn't make sense.  The NUL character (ASCII 0) is defined as NUL with
>>one 'L', and that's what you want to stuff into buf. 
>
>Dave I don't think that's the problem.

Dave is in fact quite correct.

>The error is caused by a lack of
>spacing. What William wants the code to do is:
>
>   *buf++ = NULL;
>
>However because of the spacing there is an ambigous arithmetic construct here.
>The compiler is probably interpreting this as:
>
>   *buf+ += NULL;
>
>which is not only illegal arithmetic but also a syntax error. 

If that is the case, then your compiler is seriously broken.
The rule the compiler should follow is: when collecting tokens
(going from left to right), you should always form the longest
token possible. This means that
	*buf++=NULL
consists of the tokens
	* buf ++ = NULL
not
	* buf + += NULL
and also not the rather ridiculous extreme of your suggestion
	* b u f + + = N U L L

However, as you note, spacing can certainly enhance the readability
of your programs.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
From: Tachen Ni <tcnyyf@caen.engin.umich.edu>
Subject: Q: How to change the byte length of type "double" in g++?
Date: Thu, 08 Oct 92 13:55:43 EDT
Organization: Bioengineering, Univ. of Mich.
X-Useragent: Nuntius v1.1.1d9
X-Xxmessage-Id: <A6F9EEDC6901343C@no-name-medsci2.med.umich.edu>
X-Xxdate: Thu, 8 Oct 92 18:57:48 GMT



Recently I found that the default g++ (Version 1.37.1 on Unix
machine) byte length for data type "double" (8 bytes) is not 
enough for my project.  Is there any way that I can change it 
to 12 bytes?  

Reply by e-mail preferably.  Thanks for the help.  

Tachen Ni, Bioengineering Program, Univ. of Mich.
e-mail: tcnyyf@caen.engin.umich.edu
Newsgroups: comp.lang.c
From: hui@apaturia.trl.OZ.AU (Alvaro Hui)
Subject: (double)=(double)-(int)*(int) valid???
Organization: Telecom Research Labs, Melbourne, Australia
Date: Thu, 15 Oct 1992 06:21:45 GMT

Hi,

	I recently hit a problem in BC++3.1.
I have a statement doing "simple" subtraction as
follows.

	double a, b;
	int c, d;

	a=b-c*d;

	Now, if c*d > 2^(sizeof(int)), the compiler will
produce invalid result.

	Apparently, the compiler compute c*d in a temp variable
of size 'int' before doing a convertion to 'double'!!!!!! How
can the compiler assume multiplying two integer will always fit
into an int!!!!


Any comments? Now, be a good boy, I have to put in casting
everywhere in the program....Just a pain....

Alvaro,
a.hui@trl.oz.au

------------------------------------------------------------------
Alvaro HUI
a.hui@trl.oz.au
Synchronous Network Research
TeleCom Research Labortaries Australia.
==================================================================
2M->VC12->TU12->TUG2->TUG3->VC4->STM-1(AU-1);
140M->VC4->STM-1(AU-1)
==================================================================
Newsgroups: comp.lang.c
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: _underscores __before identifiers, etc
Date: Wed, 07 Oct 1992 22:49:40 GMT
Organization: Security APL, Inc.

In article <BusC26.8IB@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
>This is a plausible explanation.  It may have merit, but if you reflect on it,
>it is a little goofy.  Why should the compiler add something special to the
>*user's* identifiers (and in fact therefore to identifiers in library functions,
>etc.) leading to possible problems of conflict or requiring the user to restrict
>an otherwise sensible name space?  Why not generate its *own* labels with a
>distinctive format -- and one the user could not use (for example by including
>in them characters acceptable in assembly language identifiers but not in C
>identifiers -- this is often, if not usually, possible)?  This is precisely
>what I did the one time I wrote a code generator for a C front end and the
>customer insisted on assembly language output.

A more critical problem, if you actually going to assembly language, is that
on most machines, there are reserved keywords in the assembly language.  You
have to prevent generation of these, too.
From: ejohnfel@libws4.ic.sunysb.edu
Newsgroups: comp.lang.c
Subject: Linking Problems with Borland's Turbo C
Keywords: link
Date: 12 Oct 92 20:25:08 GMT
Organization: State University of New York at Stony Brook
Originator: ejohnfel@libws4.ic.sunysb.edu

Hiho all,

	I have this really annoying problem with Borlands Turbo C/C++ v1.0.
I have read in various places in the documentation that the IDE doesn't
allow certain assembly/C combos. I created a group of assembly based functions
for manipulating MS-Compat. mouse drivers (INT 0x33). All the functions
were assembled as FAR functions, none of them called any C functions, just
pure param passing, setting up for the INT call. My problem is, I created
a library from the object file (called MOUSE.LIB), when I (TRY to) link the
damn program, the IDE chokes on it.

	The linker keeps sending back "_main undefined symbol...".

	The compiler's memory model is small. The MOUSE.LIB was designed to
work with all memory models (like GRAPHICS.LIB), hence all the far function
declarations.

	Is this error an inherent flaw with the whole compiler/linker setup,
or am I missing something here?

	Also, while working on a sorting program, I tried to include a
header file (made by me) that contains textwindowing routines. After the IDE
finished compiling the header file it returned with an error (in a dialog
box no less) "Program is missing file ....d:\tc\bin\work\sortd.c" when 
"sortd.c"  was the source being compiled. Does anyone know what is happening
here? I've temporaily kludged the problem by not including the particular
header file. I haven't really looked the HF  over in any great detail yet,
I was just wondering if anyone else had this problem, or could clarify that
very wierd error message.
+------------------------------+---------------------------------------------+
| Name : Eric G. Johnfelt      | "It is amazing that the purest and greatest |
| Rank : Sophmore @ SUNY SB    |  of all human qualities, always seems to    |
| Ser.#: ejohnfel@ic.sunysb.edu|  escape us!"                 -Unknown       |
+--->> Disclaimer <<--*Read*---+---------------------------------------------+
| *The opinions expressed here |      errare humanum est : ne cede malis     |
|  come direct from Elvis & the| vea victis : ULTIMA RATIO REGUM : DEI GRATIA|
|  martians who kidnapped him! |            Homey don't play 'dat            |
+------------------------------+---------------------------------------------+
Xref: sparky comp.lang.c:14895 comp.software-eng:3741 comp.sys.mac.programmer:16868
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
Subject: Re: Productivity of a C programmer ?
Date: 13 Oct 92 14:05:10 GMT
	<BvvIK4.EuJ@news.cso.uiuc.edu> <mxmora-121092100513@css-mac1.sri.com>
	<23865@alice.att.com>
Followup-To: comp.lang.c
Organization: UNC Department of Computer Science
In-reply-to: ark@alice.att.com's message of 13 Oct 92 02:59:03 GMT

In article <23865@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

   I once saw a project that had a carefully mapped out schedule that
   included milestones for each phase: requirements, design, documentation,
   unit test, system test, and so on.

   The only catch was that they forgot to schedule any time for development.

That's nothing -- I'm working on a proect where they didn't leave any
time for design or test either.  (He grumbled.)
--
		Charles R. Martin/(Charlie)/martinc@cs.unc.edu
     Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
	    3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
		 Remember what the little cake said to Alice.
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Incomplete structure declarations: only within structs?
Date: 9 Oct 92 08:49:26 GMT
Organization: University of Helsinki

farrell@fjord.reo.dec.com (John M. Farrell) writes:
>Is there anything I can add to bar.h to ensure that the FOO in the prototype
>refers to the typedef defined later, in foo.h ?

The typedef has to come first.  In addition to the already suggested
nested includes, and the obvious solution of requiring the user to
include headers in a specific order, you could consider restructuring
the headers so that they are more self-contained and do not refer to
types (or #defines, enums, etc) in other headers.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
Newsgroups: comp.lang.c
From: greyham@research.canon.oz.au (Graham Stoney)
Subject: Re: Strings and integer sizes
Organization: Canon Information Systems Research Australia
Date: Tue, 13 Oct 1992 03:59:02 GMT

andreas@andreas.hact.de (Andreas Kesenheimer) writes:
>Never trust in C-Compilers! To make shure you get what you want, not just only
>with the Compiler you personally tested, you should initialise the array you
>want to store the string by memset. Otherways you can't be really shure your
>string is terminated (remember to allocate not only the stringlength but also
>the terminator and also remember that array-counting beginns with 0).

This is a joke, right?. I'm not sure if you were being serious or not; it
certainly isn't good advice if you were. strcpy always copies the terminating
'\0' so there is certainly no need to memset it first, unless you want to waste
CPU time, or your productivity is measured in source-lines-of-code.

Graham
Newsgroups: comp.lang.c
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: multidimensional arrays as parameters
Date: Wed, 14 Oct 1992 21:51:24 GMT
Organization: Security APL, Inc.

In article <1992Oct13.224918.21890@kakwa.ucs.ualberta.ca> bill@chaos.phys.ualberta.ca (Bill Burris) writes:
>I was wondering how to pass a multidimensional array as a parameter.
>
>For a 1D array I do the following:
>
>void function( int * );
>
>int array[10];
>
>void function( int *data )
>[...]
>
>Now for a 2D array if I do the following:
>
>int array2d[10][20];
>
>void fun2d( int * );

I've seen two responses to this, both claiming the correct declaration is:

void fun2d( int ** );

This is incorrect.  array2d is not an array of pointers to arrays, but an
array of arrays.  Thus, the automatic conversion yields a pointer to an
array.  Thus fun2d should be:

void fun2d( int * [20]);

Isn't this in the FAQ?
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Realloc failure when downsizing (was Re: Probably a simple realloc() question)
Date: 8 Oct 92 18:45:48 GMT
Article-I.D.: ulogic.398
Organization: negligable

In article <1992Oct3.072354.4718@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>If realloc fails, it leaves the originally allocated block intact so you
>loose no information.  There is also no loss of convenience, since you
>still have to check the return value.  
>
>	if ((temp = realloc(ptr, size)) != NULL)
>		ptr = temp;

If we are guaranteed that a realloc smaller will never fail, we
do not have to check (in those specific cases where we know
we are downsizing).

>The only difference, then, is that the NULL return conveys possibly
>useful information (getting short of usable memory) and the original
>pointer return does not.  Therefore, I see no reason not to return NULL. 

I do not see how this information is useful to me at that point.  When
I am trying to allocate new memory or upsize a memory block with
realloc(), then the information will be meaningful and I will have
checks for failure.

Explain again why realloc() should fail when there is enough memory
available for the size requested (even if it is the memory originally
intended to be released)?

At any call to malloc() or realloc() all I want is either a pointer
large enough to handle my request, or an indication of failure.  In
the specific case of downsizing, my original pointer is pointing to
memory obviously large enough to handle my request (although it will
have some to spare...)  What justification do you have for not granting
the request?

And no, I will not send you mail.  The discussion doesn't need to
be particularly heated and it seems to be of general interest to
judge by the size of the previous thread concerning this topic.

		-Richard Hartman
		hartman@uLogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Disco isn't dead...			...it's just in witness protection!
Newsgroups: comp.lang.c