Regarding calculation of free memory

In article <79fyrfbwzw.fsf@barnowl.research.intel-research.net>,
 <dgay@barnowl.research.intel-research.net> wrote:
>
>However, gcc was essentially always available for Solaris (their may have
>been a short delay after the first Solaris release, but I didn't notice
>it at least).

The problem was in the libraries.  Solaris didn't sort out even the
basics until 1995/6, didn't enable ISO C + POSIX codes until 1998
(Solaris 7) and didn't sort out all of the chaos until Solaris 9.

Still, it did better than a certain big blue company :-(

>I don't think X11 is typical of "most codes", though. Isn't it the one
>which gives different signatures to the same function when viewed from
>different modules?

Probably.  It has included every other sin, crime and idiocy, so
why not complete the set?


Regards,
Nick Maclaren.

Paul Keinanen <keinanen@sci.fi> writes:

> On 05 Oct 2005 08:42:46 -0700,
> dgay@barnowl.research.intel-research.net wrote:
> 
> >"FredK" <fred.nospam@nospam.dec.com> writes:
> 
> >> I've yet to find UNIX code that sticks to a convention, and that is
> >> remotely safe from boneheaded mistakes.  Probably 80% or more
> >> of the code I've seen doesn't use C prototypes, which would
> >> have at least pointed out they wanted Delete() instead of delete() -
> >> each of which had different parameters (for an example).
> >
> >I'm curious where such code comes from - can you say? Most (nearly all?) of
> >the code I see, i.e., mostly open source code, has prototypes.
> 
> Are you talking about Linux or Unix in general ?

I'm talking about the open source available in the late 80s onwards time
frame, so mostly Unix in general rather than Linux in particular. And some
amount was more cross-platform than that (e.g., emacs).

-- 
David Gay
dgay@acm.org

In article <dhp6mi$7u3$1@gemini.csx.cam.ac.uk>,
Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>In article <5pCdnWbp1rsoKaLeRVnyuw@pipex.net>,
>Steve at fivetrees <steve@NOSPAMTAfivetrees.com> wrote:
>>"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message 
>>news:dhobjl$e2v$1@gemini.csx.cam.ac.uk...
>>> < extreme_pedant_mode=ON >
>>>
>>> Not so.  In Fortran 77, it was possible to allocate all memory statically,
>>> but it isn't generally possible.  It can't be done in Fortran 90 or C.
>>
>><even_more_extreme_pedant_mode=ON>
>>
>>It *can* be done in C - by avoiding malloc ;).
>>
>><even_more_extreme_pedant_mode=OFF>
>
>I will skip the mode nesting, as things are getting ridiculous :-)
>
>Problem one:  in C, there is no memory management beyond stack scoped
>except by using malloc.  Any algorithm that requires more than that
>can't be done if you don't use malloc.

That is why so many serious real time application do their own
heap management. If the heap usage is simple, programming it yourself
may be not even be hard. 

>Problem two:  there are many library facilities that use malloc either
>explicitly or implicitly - including almost all I/O - you would have
>to avoid them, too.

Yeah, you have to avoid printf c.s. They are mostly in the user interface
though. Most real time applications are split in a real real time part
and the user interface that is not. If you adapt this, you can use
printf freely in the user interface and the problem all but disappears.


>
>
>Regards,
>Nick Maclaren.



-- 
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst