Xref: utzoo comp.sys.amiga:75551 comp.sys.amiga.tech:17342
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!ira.uka.de!rusux1!phobix.caed.IAO.FhG.de!wschmidt
From: wschmidt@phobix.uucp
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Bugs ???  ls 4.0k    Manx c#?.lib
Keywords: mungwall lvodos.o ls 4.0k
Message-ID: <391@rusux1.rus.uni-stuttgart.de>
Date: 2 Jan 91 18:37:04 GMT
Sender: zrf80385@rusux1.rus.uni-stuttgart.de
Reply-To: wschmidt@IAO.FhG.de
Followup-To: /dev/null
Organization: Fraunhofer Institute for Industrial Engineering
Lines: 25


Sorry, if this has been mentioned here before. Expiration time is rater short
here, so I 've probably missed it.

Yesterday I played with mungwall. In 9 out of 10 case it reported that
ls (Version 4.0k [i haven't seen a newer one] ) munges memory it doesn't own.
It uses one byte more than it has allocated (writes to it). The sizes of
these memory chunks are between 17 and ~25 bytes (always odd length).


Recently I discovered that in c.lib, cl.lib, c16.lib and cl16.lib delivered
with Aztec C 5.0d the offsets in the lvodos modules are positive instead of
negative!

This only affects assembly programs and C programs that refer to
'LVO<DosFunction>'. The #pragmas and the glue routines seem to be correct.

I will report this to MANX, but it may take some weeks until i get around to
do so. It would probably be better if someone from the other side of the
big pond told them about.

Wolfram Schmidt
-- 
ONLY valid email address: wschmidt@IAO.FhG.de (regardless of the Reply-To: line)
Wolfram Schmidt   Teckstr. 11   W-7056 Weinstadt   Germany   +49-7151/62408  MET