hall@nosc.NOSC.MIL (Robert R. Hall) (06/21/88)
All of Minix v1.3 library functions compiled without error messages except for malloc.c which gave me the three warning messages: "malloc.c", line 49: (warning) overflow in unsigned constant expression "malloc.c", line 68: (warning) overflow in unsigned constant expression "malloc.c", line 113: (warning) overflow in unsigned constant expression To eliminate these error message I patched it with the following diff: ----------------------------- malloc.dif ---------------------------- 14c14 < #define ptrint int --- > #define ptrint unsigned 22c22 < #define Align(x,a) (((x) + (a - 1)) & ~(a - 1)) --- > #define Align(x,a) (((x) + (a - 1)) & ~((ptrint)(a - 1))) _______________________________________________________________________ The question is: is this casting necessary or should I ignore the warning messages, in either case the object code produced by the version 1.1 cem compiler is different. (I have not seen version 1.2 distributed to the net). I tried putting this patch using the Mined editor version 1.3 and discovered that numeric + (search forward), numeric - (search bachward), numeric 5 (display file status), PgUp, PgDn commands did not function. So I went back to using the mined version 1.2 editor , where these particular functions work just fine. Next I tried to build a libc.a library archive file, following the example show in Provisional V1.3 doc/man-pages of AST readnews messag-ID <709@ast.cs.vu.nl> a READ_ME file for the tsort command which is shown as: ar cr libc.a `lorder *.s` | tsort and conclude that there is a typo here and the second backward quote mark belong after tsort and the command example should be: ar cr libc.a `lorder *.s | tsort` This modifed command does work on a small number of the elements but when applied to commplete library, I got the error message: lorder: argument list too long I find this version 1.3 shell message to be a more accurate discription of the trouble than version 1.2 message of: lorder: can't execute To build libc.a, I resorted to Glen Overby shell script in his message-ID <981@ndsuvax.UUCP> Next I tried to check for missing library element in the new file against what I had in the old file /usr/lib/libc.a by using the sort command as: ar t libc.a | sort -o new ar t /usr/lib/libc.a | sort -o org Version 1.2 of sort only pass on 1/4 of the element names whereas version 1.3 does the job correctly and is an improvement. Robert R. Hall hall@nosc.mil
Chuck_M_Grandgent@cup.portal.com (07/06/88)
Have successfully digested (so far) everything up to, and including
post19. Have run into a few difficulties, though don't suspect major.
Thought I'd reiterate some of them just for focus. Please excuse the
"miscellaneous" range of the message.
1) Latest posting of tty.c to Portal feed lost second part of the
posting (got 1 of 2 OK). Would be happy to wait for the re-post, or
would appreciate getting 2 of 2 in the mail.
2) I have weird problems (few) with the libc.a library I rebuilt.
Some programs can't find fdopen(), though I can ar xv libc.a fdopen.s.
Why ?? Also, have a program that keeps coming up with unresolved
reference to fgetc(), though there's NO calls to it in my program.
Nor, using grep, can I find any in any of the lib sources.
I've played with the def's in stdio.h to no avail.
3) I find the following VERY unnerving:
Things like: #include "abc.h"
#include <minix/abc.h>
In other words, multiple header files of the same name in different
places, with (apparently) different contents. Especially like in
/usr/src/fs, mm, etc. I know, I should go back to the original posting
of the 1.3 header files (Oh yeah - all the preceding is for upgrading
from 1.2 to 1.3) and make sure I got everything right - but I thought
I did.
4) It hasn't been clear on occasion which component pieces need to
be applied TOGETHER. For example, I got (thank you Andy) the tty.c
which supports the ANSI sequences, but when I rebuilt my kernel with
it, ED wouldn't work, so I thought there was something wrong with
it (of course there was - I needed the 1.3 ED). etc.
Actually, the order Andy has been posting the 1.3 pieces is admirable,
headers, then library source, then commands, then kernel stuff, etc. -
that's the right order.
Don't get me wrong - I'm thrilled with how well its gone. Just thought
I'd pass on some of the pitfalls I've run into.
-- sun!portal!cup.portal.com!chuck_m_grandgent
-- AEG Modicon, Industrial Automation Systems Group
--//-----------------------------------------------//--