HDTenEightyP/NetNews huggingface dataset:
From: bernard@cpio1.UUCP (Bernard Fouche)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: malloc/new memory allocatio overhead?
Date: 23 Jul 92 10:36:18 GMT
Organization: CPIO S.A.


In article <1992Jul14.132746.23256@ncsu.edu>, odkahn@eos.ncsu.edu (Opher D. Kahn) writes:
> 
> 
> Does anybody know exactly what memory allocation overhead results
> from a new or malloc?  I am allocating the following structure/class
> that has a sizeof == 80.  How much memory is taken up by the other
> info fields that malloc/new creates, such as the size field, pointer
> to next malloc block, etc.?  From some other indications it seems
> that it takes ~127 bytes, but that seems like too much.

Usually, on unix and using malloc(3C), the overhead is (sizeof(void
*)) bytes per malloc.  With malloc(3X) it's difficult to say because
the routines manage pools of buffers of different size. So if you
malloc a lot of chuncks of a particular size, some buffers inside
malloc(3X) will have to grow and make the calculation difficult.

If you want a powerfull malloc that you can hack, get gmalloc (GNU
malloc). It's rather fast, it can give back memory to the system and
you can see exactly what's going on because it's provided as source
code.
-- 
-----------------------------------------------------------------------------
Bernard Fouche  VOX   : +(33) (1) 48.04.56.30  FAX :  (33) (1) 48.04.98.95|
Email : bernard@cpio1.UUCP or cpio1!bernard@gna.org (try both!)
Postal Mail : CPIO S.A., 13-15 Rue de la Verrerie, 75004 Paris, France
From: nto0302@dsacg3.dsac.dla.mil (Bob Fisher)
Newsgroups: comp.lang.c
Subject: Re: initiaklizing union members
Date: 23 Jul 92 11:33:57 GMT
Distribution: usa
Organization: Defense Logistics Agency Systems Automation Center, Columbus

From article <1708@toro.MTS.ML.COM>, by scott@toro.MTS.ML.COM (Scott Strool):
| How can I initialize a struct that contains a union member.
| If I have a struct as defined:
| 
| struct Row {
| 	int Type;
| 	union {
| 		int ival;
| 		char* sval;
| 		} value;
| 	};
| 
| how would i set value with a static declaration:
| 
| static Row r0 = { 0, 1234 };
| static Row r1 = { 1, "string" };
| 
| This does not work!

I don't know if this is a compiler problem or a syntax problem.  I
suggest that you try initializing Row r1 with a pointer, not a string.
If that doesn't help, try placing int Type after the union.  The union
may or may not be aligning on a word boundary.
-- 
Bob Fisher
EMAIL:    bfisher@dsac.dla.mil          osu-cis!dsacg1!bfisher
VOICE:    Commercial 1-614-692-9071	Autovon 850-9071
USPS:     Defense Logistics Agency, DSAC-TOL, Box 1605, Columbus OH 43216-5002
Newsgroups: comp.lang.c
From: rhurwitz@hfglobe.intel.com (Roger Hurwitz)
Subject: Murphy's Law : Variable Argument Macros
Followup-To: rhurwitz@mstuux.intel.com
Keywords: variable arguments, macros
Organization: Development Tools Operation, Intel Corp., Hillsboro, OR
Date: Fri, 24 Jul 92 17:50:06 GMT


Murphy's Law #563:

	"The day after you ignore a seemingly irrelevant thread
	on comp.lang.c you will be presented with a problem
	requiring a thorough understanding of that thread."

	Can someone please send me the solution summary for
	passing a variable number of arguments through a
	macro "function".  I need to write an error message
	macro that combines __FILE__ and __LINE__ information
	as well as a variable number of user arguments to
	put together using vsprintf.

Thanks,
	Roger Hurwitz
From: folsom@bigmax.UUCP (Al Folsom)
Newsgroups: comp.lang.c
Subject: Elementary C Texts
Keywords: Books
Date: 29 Jul 92 13:00:36 GMT
Organization: Fischer & Porter Co., Warminster, PA.


I thought I posted this note a couple of days ago, but suspect that 
through an error here it never left the local system.  

 I am looking for recommendations for textbooks for an introductory
 C course, taught at a local community college. K&R II and Harbison
 & Steele are too dense for this course.  I have been using "C A 
 Software Engineering Approach" by Darnell & Margolis, but have been 
 getting some complaints that this, too, doesn't have enough examples, 
 and doesn't explain material explicitly enough.  Does anyone have 
 suggestions for a truly elementary C text which I can use in good
 conscience, either as a primary text or a supplement for more
 examples?  

 I know the topic of C books has been discussed before.  If you would
 prefer to E-mail and let me summarize, we can save bandwidth.  On the
 otherhand, if you'd rather post, that's OK too.  I'm easy.

 Thanks.


+-------------------------------------------------------------------+
| Al Folsom                 | We've done object oriented programming|
| Fischer & Porter Co.      | for years ...                         |
| ...uunet!bigmax!folsom    |                                       |
| also folsom@decus.org     | When our customers object to the way  |
| KY3T@WA3TSW (Ham)         | it works, we go program some more...  |
+-------------------------------------------------------------------+
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Header files
Date: 23 Jul 92 17:38:54 GMT
Organization: negligable


Just add ".;" at the head of the list of include directories, then
it will look for any include files in the current directory before
it looks in the other directories.
From: heinz@edohwg.UUCP (Heinz Wrobel)
Newsgroups: comp.lang.c
Subject: Re:  Bugs with sscanf()?
Date: 21 Jul 92 20:38:33 GMT
Organization: Edotronik GmbH

In article <6JUL199210231568@ariel.lerc.nasa.gov> smneyln@ariel.lerc.nasa.gov (Michael Neylon) writes:

[code deleted]

>Someone mentioned that the buffer may be erased or partial deleted after
>returning from the field.  However, using a debugging tool, I saw that the
>field is still perfectly intact just before execution of the scanning.

You _almost_ got the solution to your problem yourself.
The buffer "a[]" is an auto buffer. auto stuff is allocated on the current
functions stack. What the "return a" does is to pass a stack address to
main that is no longer valid! It is invalid because you left the
function string() which makes its stack frame invalid. The _invalid_ stack
contents still look good before you do the scanning but the very call to
the scan function destroys the stack you _had_ been using as buffer in
string().

You can either declare a[] as static (IMHO Argghhh! for some reasons) or
put a[] into main and pass a pointer to it to string() (IMHO better). That
way you call string with a _valid_ buffer pointer and get valid buffer
contents back as they "belong" to the main() stack frame.

Check out the FAQ on pointers and auto stuff.

Hope this helps. :-)


>Mike Neylon	 aka Masem the Great and Almighty Thermo GOD!

PS: How about ANSI or C++ ;-) :-)


--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
From: oklein@smallo.bo.open.de (Olaf Klein)
Newsgroups: comp.lang.c
Subject: Re: Curious bug...
Date: 24 Jul 92 21:11:27 GMT
Organization: smallo.bo.open.de Fido-SubNet-Gate : 2:245/5800.12

pegasus@csd4.csd.uwm.edu (David R Hucke) writes:

1)
>What happens is this:  When I run the program in the QC Environment it
>works fine.  The characters are correct, and the colors are not correct.
2)
>When I run the program from DOS (outside of the QC Environment) the characters
>are correct but the colors are not correct.

Wheres the difference between 1) and 2)  ???

>#include <stdio.h>
>main()
>{
>   short far *SCREEN = (short far *) 0xB8000000;
>   short menu[8][20];
>   short x,y;
>   FILE *file;
>   int i,j,z;

>   if(!(file = fopen("c:\\test.scn","r"))){
>	printf("Unable to open file!\n");
>	exit(99);
>    }
>    for(j=0;j<8;j++)
>	for(i=0;i<20;i++){
>   	    fscanf(file,"%c%c",&x,&y);    /* reading in attribute and
>					     character bytes */
>	    menu[j][i] = (short)((y<<8)+x);  /* putting together screen
>						character ---> attribute
>						and character.  Shifting
>						one of the bytes. */
>	}
>    fclose(file);
>	for(j=0;j<8;j++)
>	    for(i=0;i<20;i++)
>		*(SCREEN+((j+5)*80)+(30+i)) = (int)menu[j][i];
>}

I don't know the scope of a short in Quick-C, but if it's really
8-bits, which I could believe under DOS, then you loose the high
(attribute) byte of menu[][], but get the char after the actual as the
attribute char.

Bye, Olaf

PS. I don't think, that this program style is very portable, and the
exit code doesn't match the errno-code, 2 (ENOENT) should be appropriate...

-- 
Olaf Klein	smallo.bo.open.de	2:245/5800.12
From: gegu@zurich.spectrospin.ch (Gerry Gucher)
Newsgroups: comp.lang.c
Subject: Re: Functions Within Functions
Summary: declare functions inside functions ? better not
Date: 30 Jul 92 08:57:02 GMT
Organization: Spectrospin AG, Fallanden Switzerland

In article <rfries.81@fries_Robert@ub.ub.com>, rfries@fries_Robert@ub.ub.com (Robert Fries) writes:
>
> No, you cannot 'define' a function within the body of another function.
> Yes, you can 'declare' a function within the body of another function.
> 
> Robert

Once upon a time it was common to declare functions in a "local context"
such as inside a function. With the coming up of ANSI C prototypes I
strongly discourage this practice.

In my opinion any data or code object should be declared only once.
For global functions (not static) this is in a header file, for static
functions this is at the top of the source file with the other
declarations.

Declaring extern functions at various places buys you nothing in
terms of compiler type checking. If the type of one of your functions
changes, there is no guarantee that all declarations have been 
updated.  

Declaring something like

   extern strcpy();  

will bite you when you port the code to an IBM system running AIX.
There strcpy() is a macro and your extern declaration will produce
a syntax error.

Gerry 

+------------------------------------------------------------------+
| Gerry Gucher                             gegu@spectrospin.ch	   |
| Spectrospin AG,  Industriestr 26,  8117  Faellanden Switzerland  | 
+------------------------------------------------------------------+
| A program that  returns the  wrong | There is nothing wrong with |
| result twice as fast is infinitely | making  mistakes,  but make |
| slower.               - H. Spencer | new ones.           - D.Sim |	
+------------------------------------------------------------------+
From: tsmith@cs.tamu.edu (Todd M Smith)
Newsgroups: comp.lang.c
Subject: good memory allocation strategies?
Date: 21 Jul 92 21:41:15 GMT
Reply-To: tsmith@cs.tamu.edu
Organization: Computer Science Department, Texas A&M University


I thought that perhaps this would be a FAQ, but I couldn't find it in
the FAQ.

I am working on a moderate size (~10000 lines so far) system on an SGI
workstation running UNIX system V.3, and I am wondering about some
memory allocation issues.  Here are the two situations I am dealing
with.

1)  I have need for a lot of variable-size data structures (lists of
items), so I currently have linked lists running all over the place.
2)  Soon, I might also need to use large contiguous blocks of space,
but the size of these can change also.

I guess this is a common trade-off.  I don't really want to limit the
user by using arrays that I "think" are bigger than they will need.
But dynamic stuff can be a pain sometimes, and I don't want to slash
up the memory.

So I need some information on the following questions:

1) Is it reasonable (in general) to ask the user to live with a big
limit?
2) How much of a speed penalty does dynamic allocation really impose?
3) How serious of a problem can memory fragmentation be on a modern
workstation?
4) If dynamic allocation is used, what is the best strategy for
handling blocks of memory whose sizes change, i.e., initially
overallocating, constantly realloc()ing, keeping track of unused
space, writing your own complete memory management system :-),
etc.?

If there are other pertinent issues that I have left out, please
include them too.  Thanks in advance.


Todd Smith
--
Todd Smith                                      tsmith@cs.tamu.edu
                    Life is a word problem.
From: rdw@vax5.cit.cornell.edu
Newsgroups: comp.lang.c
Subject: Error in MS C 6.0 ?
Date: 21 Jul 92 17:52:15 EDT
Distribution: comp
Organization: Cornell University

Dear Microsoft 6.0 C programmers:

     Has anybody noticed a possible error in the Microsoft C 6.0 compiler in
the way it handles function prototyping?  When passing single-precision float
arguments to a function, I get compilation errors when I try to use the
following together:   
prototyping in the function allusion but 'old-style' argument declarations when
defining the function.

For example:

extern int func( int a, float x, int b);

with
The prototyping works fine when I declare the arguments with the new method:
int func( a, x, b )
     int a, b;
     float x;
{



int func( int a, float x, int b )
{

If I use the old method, the compiler gives me a Parameter 2 mismatch error.
Does anybody know what's going on?

		Baffled,

		Aaron S. Chou
		Cornell University




Xref: sparky comp.lang.c:11605 comp.unix.programmer:3916
From: KOSU_MATSB@ROUTH.KOSUFY.LU.SE
Newsgroups: comp.lang.c
Subject: Answer: Concatenation of macto values
Date: 24 Jul 92 15:04:19 GMT
X-Unparsable-Date: Fri, 24 Jul 92 17:11 GMT+02

Hello!
	Thanks for the answers!

To concatenate the VALUES of two macros the following works on
GNU GCC 2.2.2:
	#define Concat0(_x_,_y_) _x_ ## _y_
	#define Concat(_p_,_q_) Concat0(_p_,_q_)

	#define A foo
	#define B xyzzy
	#define C Concat(A,B)
The little cludge of Concat0 is needed to make the preprocessor 
expand the macros BEFORE the ## operator is applied, ie
	#define C Concat0(A,B)
gives AB the value AB NOT fooxyzzy.

Thanks to:
: f88ho@efd.lth.se (Hans Olsson)	(Who gave the exact solution).

and the following people giving hints:
: briggs@progress.COM (Scott Briggs)
: jos@and.nl (Jos Horsmeier)
: tlg@uknet.ac.uk (Tim.Goodwin)
: Mark Brader
 -----------------------------------  -----------------------------------
 Mats Bergstrvm                       mats.bergstrom@kosufy.lu.se
 Div of Cosmic and Subatomic Physics  kosu_matsb@130.235.92.17
 Department of Physics                ROUTH::KOSU_MATSB (ROUTH::=57412::)
 University of Lund                   Phone: (+46)104767
 SWEDEN.                              Fax:   (+46)104709
 -----------------------------------  -----------------------------------
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: My view of variable naming conventions (was: Hungarian...)
Date: 27 Jul 92 05:59:03 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Jul27.013310.24591@uwm.edu>, markh@csd4 (Mark William Hopkins) writes:
>(0) Declare as close to 0 variables and parameters at any scoping level as
>    possible.
>(1) Declare all objects as local as possible, even within a statement block.

Absolutely.  There's even a name for this: "encapsulation".  To get more
practical: use structs to group related variables, even if makes the actual
code a bit longer.  Ultimately, you'll find it makes maintenence easier when
related variables are related by a physical structure in the code (as opposed
to use and unreliable or nonexistant documentation).

>(2) Use generic names for generic objects, and short, common (and appropriate)
>    natural language words for objects with semantic content.

Yes.  The length of a variable name should be proportional to the acreage
of code its scope occupies.  1 letter for a 3-line index counter, and something
rather longer for something global to the whole program.

>(3) If you have to comment on a variable's use, then you've named it wrong.
>    Rename it.

Yah.  A bit of care in naming global identifiers and functions goes a long way.

>Experience with my own code and other people's code have borne out this
>assessment time and time again:
>
>    If you find yourself reverting to Hungarian Notation,
>    then you've violated all the above, (0) through (5).

Programming in the large is as much about managing complexity as it is about
solving the problem at hand.  Any competant programmer can solve all the 
problems that comprise a large program *in isolation*.  And the key to
managing complexity lies in careful use of encapsulation and abstraction.

If you're having problems remembering the type of a variable, you're
probably better off rethinking you're program's abstractions, rather
than adopting some bizarre naming convention that's harder to remember
how to use than it is to remember the types of your variables

-- 
You unlock this door with the key of imagination.  Beyond it is another
dimension: a dimension if sound, a dimension of sight, a dimension of mind.
You're moving into a land of both shadow and substance, of things and ideas.
You've just crossed over into... the Twilight Zone.
Newsgroups: comp.lang.c
From: shulick@navajo.ucs.indiana.edu (Sam Hulick)
Subject: Writing an auto-wrap routine
Originator: shulick@navajo
Reply-To: shulick@navajo.ucs.indiana.edu
Organization: Vallen Software
Date: Thu, 23 Jul 1992 21:18:05 GMT


I want to have a function that would work like this:

  void wprintf(char *string, int cols)

Which would print 'string' using word-wrap, at 'cols' columns.  What's the best
way to go about this?

REPLY VIA E-MAIL (shulick@indiana.edu).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
Sam Hulick  ///  E-mail: shulick@indiana.edu (including NeXT mail)
------------------------------------------------------------------------
  "The pen is the mouth and the paper is the soon-to-be-wise one."
Newsgroups: comp.lang.c
From: lermer@theory.chem.ubc.ca (Noah Lermer)
Subject: Loop structures
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Fri, 24 Jul 1992 00:34:02 GMT

Hello everyone,

I've got a loop flow problem.

 I read a value from the user
 Check that the value is valid,
   if it is then I just want to continue,
   if it is not, then I display an error and reprompt for the value.

in pseudocode:

 :loop
    get input <---------
    if (!valid)         |
      complain to user  |
      then loop: -------

The problem comes when I want to code this in C
I've found a couple ways of doing this, none of which I like completely.

Solution i)

do {
    ... get input ...
} while ( !valid ? showerror(),1 : 0 );

The obvious problem with this is that it is ugly and hard to read,
let alone maintain, but could be ok if you macro-ised it.

Solution ii)

:label
    .... get input ...
    if (!valid) 
    {
        showerror();
        goto label;
    }

Aside from the religious issues involved, using a goto in this situation
can also get hairy to look at since I need several inputs one after another
(all with their own set of labels etc...) separated by a fair bit of code
from the goto (the get input section can be fairly long). It gets easy to
loose track of which label goes with which code block, especially if they
are nested (ie, parts of one input are validated individually as well).
On the other hand, it is easily extensible to multiple error conditions.

Solution iii)

do {
    ... get input ...
    if (valid)
        break;
    showerror();
} while(1);

This is the solution I like the most, but has the disadvantage (like i) that
multiple error conditions are not handled easily. This should also be easy to
macro-ise.

Some more comments:
The (valid) or (!valid) condition is a rather complicated arithmetic expression
I would prefer to only have to calculate once. At the moment I have only one
error condition, but as a general algorithm, I would prefer to be able to
handle different types of errors. 

For what it's worth, the input routines are not from the standard library.
I'm doing direct screen i/o on a PC, so any technique you suggest should not
make any assumptions about <stdio.h>

I'd really appreciate any comments/suggestions (/flames :) you
care to send my way. E-mail (hollebon@cemaid.chem.ubc.ca or
lermer@theory.chem.ubc.ca) and I'll summarise for the 'net.

Thanks for your time,
Bruce Hollebone,
hollebon@cemaid.chem.ubc.ca
From: linsbin@cc.nctu.edu.tw (Lin shyh bin)
Newsgroups: comp.lang.c
Subject: Q : Using 128 bits on VAX C ?
Date: 30 Jul 92 02:11:34 GMT
Organization: National Chiao Tung University
X-Newsreader: Tin 1.1 PL4

Hi, netters :

    I only know it's available to use a 128 bits floating point number on VAX

FORTRAN (guad precision: REAL*16). And the VAX FORTRAN also support the math

library functions with a guad precision floating point number, just as

REAL*16 QSIN(REAL*16), REAL*16 QSIN(REAL*16), ...... etc. But I can't use the

128 bits floating point number on VAX C, it just allow to use the double 

precision type (64 bits). And it also only support the double precision type

of the math library functions.

   Could anyone tell me how to use guad precision type on VAX C ?  Or does it

have another solution method to get 128 bits precision on VAX C ?  By the way,

the "using /G_FLOAT on compiling" seems useful. How does it work ?

   Thanks in advance !!!

                                                   Sbin Lin
                                        Internet : u7822044@cc.nctu.edu.tw   
                                        Bitnet   : 7822044@TWNCTU02
From: ath@linkoping.trab.se (Anders Thulin)
Newsgroups: comp.lang.c
Subject: Re: About the 'F' in RTFM
Date: 23 Jul 92 06:44:57 GMT
Organization: Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden

In article <l6rbffINN8hu@appserv.Eng.Sun.COM> limes@ouroborous.Eng.Sun.COM (Greg Limes) writes:
>When some bonehead calls you up for the third time in an hour asking
>questions the he can find in Section I of the Unix Programming Manual
>or (worse) in the READ ME FIRST!!! document, telling him to RTM just
>does not have enough emotional impact.

If you emotional impact, spit in his face.

'RTFM' is the verbal equivalent of spitting someones face.  It
shouldn't be surprising that people objects to that kind of arrogance.

May I suggest that most of this discussion really belongs in
comp.society.folklore as it doesn't have much to do with C?
-- 
Anders Thulin       ath@linkoping.trab.se 
Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden
From: ajay@acpy01.att.com (Ajay Dhawan (CXNIXPT1))
Newsgroups: comp.lang.c
Subject: Telnet w/o login and password
Date: 28 Jul 92 20:49:26 GMT
Distribution: all
Organization: AT&T IMS - Piscataway, NJ (USA)


I'm working on writing a C program to telnet to a host machine
without interactively entering in a login or a password.  I've
managed to get past the login: prompt but I can't seem to get
past the Password: prompt.  I think my problem is that the 
password is read directely from the tty device rather than 
standard input, but I'm not too sure.

I managed to get past the login: prompt by doing the following:
I opened a pipe which returned two file descriptors, one for
reading and one for writing.  Then I used fork() to set up a
parent/child relationship.  The child process closes standard
input and then duplicates the pipe read descriptor using
dup(pd[0]) so that stdin is replaced by pipe read.  The child
process then uses execl to run telnet.   The parent process
uses the write() command to write to pd[1] which is the write
end of the pipe.  By doing this, the two processes are able
to communicate.

When I run my program, I get the login: prompt and the write
works giving me the Password: prompt.  But the write does
not work on the Password: prompt.  The program ends when 
the user gets timed out for input.

I understand that entering a password is a very interactive
process - I don't know if there is a way to do something 
like this non-interactively.  I have just recently started
working with such low level C programming.  Perhaps there
is a solution that I don't see.  If you have any ideas, I
would definitely be very interested.  If you'd like, I 
can send you the code I described above.

-Ajay Dhawan