edb_tom@tor.nhh.no (Tom Ivar Helbekkmo) (08/23/89)
A couple of observations regarding non-standard details in Minix: - The FILE struct used in our stdio uses different levels of indirection from the normal "standard". Also, the members of the struct have wrong names. Shouldn't this be fixed, to ease portability for programs that use these elements? I've taken the liberty of doing so in my library, and haven't experienced any problems. - Then there's the old problem with not having ".o" files. I've changed my cc and related programs to use ".s" for unpacked assembly sources, and ".o" for packed assembly. This also works very well, and (at least in my opinion) makes program development easier. How about it? Should we go for something like this in future? -tih -- Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205 edb_tom@tor.nhh.no, thelbekk@norunit.bitnet, helbekkmo@nhh.uninett
ast@cs.vu.nl (Andy Tanenbaum) (08/23/89)
In article <67@tor.nhh.no> edb_tom@tor.nhh.no (Tom Ivar Helbekkmo) writes: >A couple of observations regarding non-standard details in Minix: > >- The FILE struct used in our stdio uses different levels of > indirection from the normal "standard". Also, the members > of the struct have wrong names. Shouldn't this be fixed, Things that are visible to programmers, like names of members that are defined in official header files should move toward the standard. Internal details should not, lest AT&T get unhappy that MINIX is becoming UNIX. >- Then there's the old problem with not having ".o" files. I will try to see if I can arrange for a separate assembler and linker next time (2.0). This will produce .o files. This is an intention, not a promise. Andy Tanenbaum (ast@cs.vu.nl)
Leisner.Henr@xerox.com (marty) (08/23/89)
In article <67@tor.nhh.no> edb_tom@tor.nhh.no (Tom Ivar Helbekkmo) writes: >A couple of observations regarding non-standard details in Minix: > >- The FILE struct used in our stdio uses different levels of > indirection from the normal "standard". Also, the members > of the struct have wrong names. Shouldn't this be fixed, The ANSI Dpans (May 88) doesn't say much about what FILE really is -- it's all defined by the implementation. If ANSI defined functions/macros are used, and the programs include <stdio.h>, there should be no portability problems. Pretty much every implementation I've seen differs somewhat in how stdio.h is implemented, the Minix implementation strays a little further from the norm. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
henry@utzoo.uucp (Henry Spencer) (08/24/89)
In article <67@tor.nhh.no> edb_tom@tor.nhh.no (Tom Ivar Helbekkmo) writes: >- The FILE struct used in our stdio uses different levels of > indirection from the normal "standard". Also, the members > of the struct have wrong names. Shouldn't this be fixed, > to ease portability for programs that use these elements? No. Such programs are inherently unportable. The only applicable standards specify that portable programs should not rely on such information. Better to find out quickly -- just because the names match doesn't mean that the behavior matches. (We've run into this quite seriously in C News -- SunOS 4.0 has some of the members behaving quite oddly in some hard-to-pin-down circumstances, and this fouls up our [optional] stdio-speedup package.) -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu