Path: utzoo!attcan!uunet!mcsun!hp4nl!ruuinf!praxis!bartm
From: bartm@praxis.cs.ruu.nl (Bart Muyzer)
Newsgroups: comp.os.minix
Subject: ST 1.5.0 problems, please help
Keywords: posix source, ptr references
Message-ID: <2571@ruuinf.cs.ruu.nl>
Date: 5 Mar 90 21:16:57 GMT
Sender: news@ruuinf.cs.ruu.nl
Organization: Utrecht University, Department of Computer Science.
Lines: 84


  To all MINIX users:

  While doing the upgrade from ST 1.1 to ST 1.5.0, I came across the following
  problems. Could anyone please help me with them or send her/his own
  experiences?

  1.	I checked all crc's; they seem to match (except for some files that
	I modified myself according to postings in comp.os.minix) exCept for
	the lib/posix directory. The crc's for the following files match with
	the PC-version, NOT the ST-version:

	chmod.c	creat.c	exec.c fdopen.c getgrent.c getpwent.c link.c
	mkfifo.c open.c read.c stat.c unlink.c utime.c write.c

	To all these files, I applied cdifs from posix.cdif, and I had no
	problems. Is this a mistake from Frans?
	I compiled the (generated) ST sources for these commands, had no
	problems, and all commands seem to work...

  2.	cv.c includes the files <out.h> and <a.out.h>. Both define S_ABS:
	  <out.h>   #define S_ABS 0x0001	/* absolute section type */
	  <a.out.h> #define S_ABS ((unsigned short)-1) /* internal segnum
							  or extern symbol
							  num */

	cv.c used the latter, which gave a warning. Is this ok? The meanings
	of S_ABS seem to differ...

  3.	During compilation of the new sh, I got a warning: "Incompatible
  	pointers in =". The following fragment shows what happens:
		
		typedef	long jmp_buf[13];

		jmp_buf	m1;		/* Make m1 an array of 13 longs */
		int	*failpt;

		setjmp(failpt = m1);

	Setjmp() expects its argument to be of type 'jmp_buf'; here it gets an
	int * instead. First, m1 (a long *) is forced to an int * (scary...,
	and this produces the warning), the result is assigned to failpt and
	passed to setjmp.
	This is a typical example of assuming that sizeof(long) == sizeof(int),
	which may be true on a PC, but certainly isn't on an ST...
	Is it save to ignore this? If no, what should I do about it?

  4.	The compilation of de (disk editor) broke on this fragment from
  	<type.h>:

		#if (CHIP == M68000)
	 	typedef	long vir_bytes;   <-- "long with illegal type"
		#endif

	(CHIP is defined as M68000). vir_bytes isn't defined elsewhere, not in
	any system header files, not in de's own header files. I don't know
	what is wrong... The size and crc of <type.h> match with the ones
	Frans posted.
  5.	There has been a posting about a missing 'mknod' for /dev/tty1 in the
  	makedev script. What was it again?
  6.	Some commands produce warnings about "conversion of pointer to int
	loses accuracy" (and int -> ptr, which is worse). Should I ignore
	these?

  REMARK:
    I had to chmem +25000 /usr/lib/opt in order to compile ic, and to
    chmem +25000 /usr/lib/cv in order to compile kermit.

  
  You can either answer in comp.os.minix or by email (bartm@cs.ruu.nl).
  Thanx in advance,

						>] Bart [<
-- 
Bart Muijzer, Department of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80089, 3508 TB Utrecht, The Netherlands______________
Email: bartm@cs.ruu.nl, UUCP: ...!mcsun!hp4nl!ruuinf!bartm   |Hardware likes
Phone: +31-3404-19844 ext. 390 (work), +31-5443-71082 (home) |soft treatment

--
Bart Muijzer, Department of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80089, 3508 TB Utrecht, The Netherlands______________
Email: bartm@cs.ruu.nl, UUCP: ...!mcsun!hp4nl!ruuinf!bartm   |Hardware likes
Phone: +31-3404-19844 ext. 390 (work), +31-5443-71082 (home) |soft treatment