From:	"John M. Aldrich" <fighteer AT cs DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Simple beginner questions
Date:	Sat, 06 Dec 1997 08:24:57 +0000
Organization:	Two pounds of chaos and a pinch of salt
Lines:	80
Message-ID:	<34890BD9.5CA5@cs.com>
References:	<664c3s$2rq$1 AT fsuj19 DOT rz DOT uni-jena DOT de>
Reply-To:	fighteer AT cs DOT com
NNTP-Posting-Host:	ppp218.cs.com
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

E. Schmidt wrote:
> 
> 1. How to define user function with variable
>    number of arguments? I simply want(ed) to
>    define my error handler printing some formatted message
>    and making some other things like closing files...

This is a somewhat advanced topic, but the solution to it is standard
(and thus not specifically related to DJGPP).  You declare a function
that is something like this:

int varsum( int howmany, ... )
{
    int i, sum;
    va_list v;

    va_start( v, howmany );
    for ( sum = 0, i = 0; i < howmany; i++ )
        sum += va_arg( v, int );
    va_end( v );

    return sum;
}

The va_* types are used to access the variable arguments list.  You can
call this function with any number of integer arguments, as long as you
tell it the correct number of them in the first argument.  If you don't,
it will probably crash badly.  :)

Unfortunately, the va_* functions were omitted from the DJGPP libc
documentation, but a good explanation of them can be found in chapter 15
of the comp.lang.c Frequently Asked Questions
(http://www.eskimo.com/~scs/C-faq/top.html).

> 2. How to close the file, if I don't know if it is opened or closed?
>    Only file variable FILE * fp; is achivable.

You should remember if it's opened or closed and handle it
appropriately.  This is simply good programming practice; it's not
anything you should have to depend on the compiler for.  For what it's
worth, calling fclose() on an already-closed file pointer is undefined
behavior.

> 3. Is it important in C to free the memory in the inverse
>    allocation order ?

It does not matter.  How memory fragmentation is handled by your
compiler's local implementation of malloc() is transparent to the user
and should not be of concern to you unless you are working with a
program that uses lots of memory.  In this case, it's often best to
write your own custom allocation routines instead of depending on any
particular implementation of malloc() and company.

>      p1=malloc(100);
>      p2=malloc(200);
>      ...
>      free(p2);
>      free(p1);
>    What happens with pieces of memory which are set free in "wrong" order?
>    For above example
>      free(p1);
>      p1=malloc(50);
>    Would these 50 bytes be allocated in the memory of previous malloc(100) ?

They might be.  Or malloc() might use a 2^n hash table to track free
blocks, and allocate an additional 64-byte block for the third request
(it used 128-byte blocks for the first two).  You can't depend on any
particular behavior here.

hth

-- 
John M. Aldrich, aka Fighteer I <fighteer AT cs DOT com>

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s+:- a-->? C++>$ U@>++$ p>+ L>++ E>++ W++ N++ o+>++ K? w(---)
O- M-- V? PS+ PE Y+ PGP- t+(-) 5- X- R+(++) tv+() b+++ DI++ D++ G>++
e(*)>++++ h!() !r !y+()
------END GEEK CODE BLOCK------

- Raw text -