goer@sophist.uucp (Richard Goerwitz) (01/11/89)
Just recently, I decided that I needed a C compiler for my
PC. My wife frequently uses it, and I'd like to write games
for my son. I'd also like to do some stuff here before run-
ning it on the Sun I typically use on campus here at the
University of Chicago.
QUESTION: What compiler for use under MS-DOS is the most
portable? In other words, which will probably allow me to
do the most things with the biggest libraries, and yet still
offer me some degree of machine independence (i.e. let me
run things I write on my PC on the Sun at school with a
minimum of fuss).
Any ideas?
Replies can be posted or sent to me directly. If anyone
expresses interest, I will gladly post any information that
I receive.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
rutgers!oddjob!gide!sophist!goer
Richard Goerwitz
goer@sophist.uchicago.edu
...!rutgers!oddjob!gargoyle!sophist!goerevil@arcturus.UUCP (Wade Guthrie) (01/13/89)
In article <1354@tank.uchicago.edu>, goer@sophist.uucp (Richard Goerwitz) writes: > QUESTION: What compiler for use under MS-DOS is the most > portable? . . . I have had a lot of luck with Microsoft C (not Quick-C, for which I can say nothing as I have not tried it). It seems to be one of the richest versions of the language I have seen and it makes small, fast code. You can certainly utilize its capabilities to write (expansive) code that is portable. Wade Guthrie evil@arcturus.UUCP Rockwell International Anaheim, CA (Rockwell doesn't necessarily believe / stand by what I'm saying; how could they when *I* don't even know what I'm talking about???)
bader+@andrew.cmu.edu (Miles Bader) (01/14/89)
evil@arcturus.UUCP (Wade Guthrie) writes: > In article <1354@tank.uchicago.edu>, goer@sophist.uucp (Richard Goerwitz) writes: > > QUESTION: What compiler for use under MS-DOS is the most portable? > I have had a lot of luck with Microsoft C (not Quick-C, for which I can > say nothing as I have not tried it). It seems to be one of the richest > versions of the language I have seen and it makes small, fast code. You > can certainly utilize its capabilities to write (expansive) code that > is portable. Assuming, of course, that you don't use one of the 437,889 microsoft extensions to the language... -Miles
bagpiper@oxy.edu (Michael Paul Hunter) (01/16/89)
In article <1354@tank.uchicago.edu> goer@sophist.uucp (Richard Goerwitz) writes: >Just recently, I decided that I needed a C compiler for my >PC. My wife frequently uses it, and I'd like to write games >for my son. I'd also like to do some stuff here before run- >ning it on the Sun I typically use on campus here at the >University of Chicago. > >QUESTION: What compiler for use under MS-DOS is the most >portable? In other words, which will probably allow me to >do the most things with the biggest libraries, and yet still >offer me some degree of machine independence (i.e. let me >run things I write on my PC on the Sun at school with a >minimum of fuss). > Turbo C 2.0 by Borland is a very good development environment. The manual lists which functions are ms-dos specific. Borland seems intent on tracking ANSI C so that makes it highly portable. The compiler has a switch to force ANSI C. In my eyes it is the best ms-dos C compiler. Mike
rogerson@PEDEV.Columbia.NCR.COM (rogerson) (01/17/89)
In article <YXnd7fy00UkaI3Om9C@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >Assuming, of course, that you don't use one of the 437,889 microsoft >extensions to the language... >-Miles All of which can be turned off.
geoff@warwick.UUCP (Geoff Rimmer) (01/17/89)
In article <YXnd7fy00UkaI3Om9C@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >evil@arcturus.UUCP (Wade Guthrie) writes: >> In article <1354@tank.uchicago.edu>, goer@sophist.uucp (Richard Goerwitz) writes: >> > QUESTION: What compiler for use under MS-DOS is the most portable? >> I have had a lot of luck with Microsoft C (not Quick-C, for which I can >> say nothing as I have not tried it). It seems to be one of the richest >> versions of the language I have seen and it makes small, fast code. You >> can certainly utilize its capabilities to write (expansive) code that >> is portable. > >Assuming, of course, that you don't use one of the 437,889 microsoft >extensions to the language... > Awww come on! The main extensions they have provided are not essential to programming in C - a lot of the extensions are things like new keywords like pascal, fortran, cdecl, far, near, huge. The first 3 are only useful if you're linking your C object files with Pascal (hmph), BASIC (uggh!), or FORTRAN (agghh); and I have never used the last 3 - I can easily get by without them - I just compile using a different memory model. Other extensions to the language are concerned with things like allowing ',' instead of ',...' for variable argument functions, and so on. On the question of Quick C as mentioned by Richard Goerwitz above, I've found it a VERY useful piece of software. It's not just a compiler, but a good editor as well - in fact you now get Quick C free with Microsoft C 5.1 BTW, can anyone tell me if the keyword 'volatile' is part of the ANSI standard? (I mean is it true to say that all ANSI C compilers must have the keyword volatile WORKING (i.e. semantically as well as syntactically)?) ------------------------------------------------------------ Geoff Rimmer, Computer Science, Warwick University, England. geoff@uk.ac.warwick.emerald "If there's one thing I hate in British showbusiness MORE than you, it's that bunch of people who made one half-funny gag at Live at the Palladium and have made a fortune doing game shows ever since. 'Oh and your name is Cynthia and you'd like me to patronise and humiliate you on the offchance of winning a teasmade.' Cheeky chappies? More like complete and utter bastards if you ask me!" - Filthy Rich and Catflap, 1986. ------------------------------------------------------------
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/18/89)
In article <908@ubu.warwick.UUCP> geoff@emerald.UUCP (Geoff Rimmer) writes: >Awww come on! The main extensions they have provided are not >essential to programming in C - a lot of the extensions are things >like new keywords like > pascal, fortran, cdecl, far, near, huge. Some of us would argue that the ABSENCE of these extensions is more useful to the portable-C programmer than their presence! I have had code in the past that used several of these as variable names, etc. Unless the compiler manages to allow them as user identifiers outside the context of type declarations, they are bound to get in the way. (I don't know whether or not MicroSoft's compiler is that clever.) >BTW, can anyone tell me if the keyword 'volatile' is part of the ANSI >standard? (I mean is it true to say that all ANSI C compilers must >have the keyword volatile WORKING (i.e. semantically as well as >syntactically)?) Certainly. What would be the point if it didn't have to work?
bobmon@iuvax.cs.indiana.edu (RAMontante) (01/18/89)
gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: -geoff@emerald.UUCP (Geoff Rimmer) writes: ->Awww come on! The main extensions they have provided are not ->essential to programming in C - a lot of the extensions are things ->like new keywords like -> pascal, fortran, cdecl, far, near, huge. - -Some of us would argue that the ABSENCE of these extensions is more -useful to the portable-C programmer than their presence! I have had -code in the past that used several of these as variable names, etc. -Unless the compiler manages to allow them as user identifiers outside -the context of type declarations, they are bound to get in the way. -(I don't know whether or not MicroSoft's compiler is that clever.) I don't know about MSC, but Turbo C has a switch to turn these off and only accept strictly dpANS keywords (is "strictly dpANS" an oxymoron?) if desired. Note that 'pascal' 'fortran', and 'cdecl' exist to allow linking with modules written in these languages and compiled by Microsoft compilers for these languages under MSDOS. 'far', 'near', and 'huge' all exist to allow optimizing for the segmented structure of the 8086 (and can be obviated at some cost in size and execution speed by compiling in HUGE memory model). This linking and memory-model-monkeying is inherently non-portable anyway; the operations just don't make any sense on most systems. Hey! What'd you do with the 'entry' keyword?!?!? A 'goto' is only half a 'goto' if I can't have multiple entries to a procedure! Cheee....
chasm@killer.DALLAS.TX.US (Charles Marslett) (01/18/89)
In article <9414@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > Some of us would argue that the ABSENCE of these extensions is more > useful to the portable-C programmer than their presence! I have had > code in the past that used several of these as variable names, etc. > Unless the compiler manages to allow them as user identifiers outside > the context of type declarations, they are bound to get in the way. > (I don't know whether or not MicroSoft's compiler is that clever.) It is. They have more that a reasonable number of command line switches to disable/enable every detail conceivable (and a few I cannot conceive of uses for, except in a Windows environment ;^). Microsoft C is rather stringently ANSI-ish if you disable the extensions -- the only thing they seem to leave on when you turn it off (sometimes) is function prototypes -- they fix up calling sequences after telling you they won't. If only they got all the optimizations as perfect . . . =========================================================================== Charles Marslett STB Systems, Inc. <== Apply all standard disclaimers Wordmark Systems <== No disclaimers required -- that's just me chasm@killer.dallas.tx.us
mcdonald@uxe.cso.uiuc.edu (01/18/89)
>In article <908@ubu.warwick.UUCP> geoff@emerald.UUCP (Geoff Rimmer) writes: >>Awww come on! The main extensions they have provided are not >>essential to programming in C - a lot of the extensions are things >>like new keywords like >> pascal, fortran, cdecl, far, near, huge. >Some of us would argue that the ABSENCE of these extensions is more >useful to the portable-C programmer than their presence! I have had >code in the past that used several of these as variable names, etc. >Unless the compiler manages to allow them as user identifiers outside >the context of type declarations, they are bound to get in the way. >(I don't know whether or not MicroSoft's compiler is that clever.) It is not that clever. BUT THEY CAN TRIVIALLY BE TURNED OFF!!! Actually, "pascal", "fortran", and "cdecl" are quite useful, and not only for cros-language purposes. The "pascal" and "fortran" declarations used on a function make its calling sequence more efficient. There is a command line switch which makes this the default "pascal", and then cdecl overrides that for library functions. The only one that can cause real problems is cdecl, which is in all the header files. But you can, if you wish to be REALLY standard, edit it out, and use the command line switch for pure (except they haven't quite finished the ANSIfication process) ANSI.
turner@sdti.SDTI.COM (Prescott K. Turner) (01/19/89)
In article <9414@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <908@ubu.warwick.UUCP> geoff@emerald.UUCP (Geoff Rimmer) writes: >>BTW, can anyone tell me if the keyword 'volatile' is part of the ANSI >>standard? (I mean is it true to say that all ANSI C compilers must >>have the keyword volatile WORKING (i.e. semantically as well as >>syntactically)?) > >Certainly. What would be the point if it didn't have to work? X3J3 did the best they could. However, the ANSI definition of WORKING will certainly differ on occasion from what users expect. In particular, the standard does not require that when an object is declared volatile, every access to it will be an atomic operation uninterrupted by other processes. For example, a compiler is permitted to handle the function int foo (volatile int * x) { return * x; } by copying from the object pointed to by "x" one byte at a time. If the object is really volatile, the value returned may differ from any value ever stored in it. A good C compiler will make such operations atomic when the hardware has efficient support for it. And the standard requires implementations to document how they handle volatile objects. -- Prescott K. Turner, Jr. Software Development Technologies, Inc. 375 Dutton Rd., Sudbury, MA 01776 USA (508) 443-5779 UUCP: ...{harvard,mit-eddie}!sdti!turner Internet: turner@sdti.sdti.com
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/19/89)
In article <16573@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >-> pascal, fortran, cdecl, far, near, huge. >This linking and memory-model-monkeying is inherently non-portable >anyway; the operations just don't make any sense on most systems. Obviously if a program USES these in the MicroSoft sense, it is non-portable. However, if it uses them for its own purposes, then it may very well break when ported to a MicroSoft implementation. One hopes that MicroSoft will provide alternative names within the name space reserved for implementations (e.g. "__pascal") for these extensions, in which case those names would not need to be disabled for standard conformance. But the non-underscore names DO need to be disabled to conform to the standard (unless, as I mentioned before, the compiler is smart enough to allow all strictly conforming programs to use the names for their own purposes, with MicroSoft's special meaning active only in cases that could not occur in a strictly conforming program). >Hey! What'd you do with the 'entry' keyword?!?!? A 'goto' is only half >a 'goto' if I can't have multiple entries to a procedure! Cheee.... "entry" never was supported by the AT&T UNIX C compilers. I guess by the time Dennis and Steve got around to worrying about it, they had realized that it was not an idea that should be encouraged. X3J11 quit reserving it as a keyword because there was no point in doing so.
blarson@skat.usc.edu (Bob Larson) (01/19/89)
In article <16573@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >Note that 'pascal' 'fortran', and 'cdecl' exist to allow linking with >modules written in these languages and compiled by Microsoft compilers >for these languages under MSDOS. This is true only of fortran and pascal. cdecl is a keyword only because microsoft was to lazy to add a few #defines to their programs. It does nothing that could not be accomplished better in the preprocessing phase. -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/19/89)
In article <349@sdti.SDTI.COM> turner@sdti.UUCP (0006-Prescott K. Turner, Jr.) writes: >X3J3 did the best they could. I hope you meant X3J11. X3J3 is Fortran, I think. >However, the ANSI definition of WORKING will certainly differ on >occasion from what users expect. That depends on whether users get their ideas from bogus sources or not. >In particular, the standard does not require that when an object is >declared volatile, every access to it will be an atomic operation >uninterrupted by other processes. Of course not. Only sig_atomic_t has any requirement of atomicity. Most implementations would have to haul in a large amount of semaphore baggage in order to guarantee atomicity for general types. That wasn't the purpose of the "volatile" type qualifier; avoiding excessive optimization was its purpose. The proposed C Standard deliberately avoids attempting to deal with concurrent process issues. There might be some point in a future Standard dealing with this, but it was felt to be premature to settle how it should be done at this time. >A good C compiler will make such operations atomic when the hardware >has efficient support for it. No argument there. If a program DEPENDS on the volatility of an object for its correct operation, it is inherently non-portable and consequently needs to be tweaked for the specific behavior of its compilation and run-time environment. The "volatile" type qualifier merely makes it feasible for such environments to employ a higher degree of optimization in non-volatile cases than would otherwise be possible, because there is an escape available when it's necessary.
swilson%thetone@Sun.COM (Scott Wilson) (01/20/89)
In article <9419@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >One hopes that MicroSoft will provide alternative names within the >name space reserved for implementations (e.g. "__pascal") for these >extensions, in which case those names would not need to be disabled Excuse my ignorance but the radio's turned up too loud. What happens to the names of routines used to implement standard library functions? Don't these pollute the name space? Are implementations required to work around this? For example can a pANS program with a routine called write() reliably be compiled and run on a UNIX system without causing printf (really _flsbuf) to call the user's routine and botching everything? Does _flsbuf need to be rewritten to call __write() or something similar where __write is implemented as: __write(d, buf, nbytes) int d; char *buf; int nbytes; { syscall(SYS_write, d, buf, nbytes); } to avoid getting the symbol "write". Of course, we're left with syscall polluting the name space. -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA
bobmon@iuvax.cs.indiana.edu (RAMontante) (01/20/89)
I write: >Note that 'pascal' 'fortran', and 'cdecl' exist to allow linking with >modules written in these languages and compiled by Microsoft compilers >for these languages under MSDOS. I was wrong. Turbo C doesn't recognize any fortran keyword. Not to mention 'entry'. Oops. <14767@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: > >This is true only of fortran and pascal. cdecl is a keyword only because >microsoft was to lazy to add a few #defines to their programs. It does >nothing that could not be accomplished better in the preprocessing phase. Well, I'm talking specifically about TurboC's use of the keywords; in TC the 'cdecl' keyword means that a function follows the 'C' linking and arg-passing conventions, and identifiers are case-sensitive and get leading underbars, even though the overall default may be 'pascal'-like. For example, main() must always be 'cdecl' to match the standard startup code. Maybe this could be done in the preprocessor. I'd be interested to know how, I don't know what's involved.
mdfreed@ziebmef.uucp (Mark Freedman) (01/20/89)
In article <9414@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <908@ubu.warwick.UUCP> geoff@emerald.UUCP (Geoff Rimmer) writes: >>Awww come on! The main extensions they have provided are not >>essential to programming in C - a lot of the extensions are things >>like new keywords like >> pascal, fortran, cdecl, far, near, huge. > >Some of us would argue that the ABSENCE of these extensions is more >useful to the portable-C programmer than their presence! I have had >code in the past that used several of these as variable names, etc. >Unless the compiler manages to allow them as user identifiers outside >the context of type declarations, they are bound to get in the way. >(I don't know whether or not MicroSoft's compiler is that clever.) > >>BTW, can anyone tell me if the keyword 'volatile' is part of the ANSI >>standard? (I mean is it true to say that all ANSI C compilers must >>have the keyword volatile WORKING (i.e. semantically as well as >>syntactically)?) > >Certainly. What would be the point if it didn't have to work? The Turbo C 2.0 reference manual alleges that the -A option causes the compiler to ignore non-ANSI extensions, and that Turbo C keywords such as far, near, pascal, etc. may then be used as identifiers. It's possible that Microsoft C has a similar option. btw I see that fstat() is not part of the ANSI stdio lib (unless I've missed something). How does one determine the length of a file in a portable fashion ? bbtw As I recall, Microsoft implements the volatile keyword syntactically but not semantically. Perhaps their motto could be "we're BIG, so we don't HAVE to be good" :-)
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/20/89)
In article <86097@sun.uucp> swilson@sun.UUCP (Scott Wilson) writes: >Excuse my ignorance but the radio's turned up too loud. What happens >to the names of routines used to implement standard library functions? Functions specified in the Standard may safely be used in implementing other functions in the Standard library. Other external identifiers must be taken entirely from the name space reserved for implementations. >For example can a pANS program with a routine called write() reliably >be compiled and run on a UNIX system without causing printf (really >_flsbuf) to call the user's routine and botching everything? Yes; that is exactly the point of the prohibition against conforming implementations infringing on the name space reserved for applications. >Does _flsbuf need to be rewritten to call __write() ... Yes, but your example wasn't the right way to do that. "__write" is best made an assembly-coded system-call hook just like the current "write". The current "write" function can remain in the UNIX C library, but it must not be used in implementing the C language run-time support (don't laugh! We have a compiler that generates calls to "bcopy"), nor within the implementation of library functions specified in the Standard. I think UNIX/POSIX C implementors have been aware of this for quite some time. It has no adverse impact on existing applications, and is a necessary constraint to achieve maximal program portability.
henry@utzoo.uucp (Henry Spencer) (01/21/89)
In article <86097@sun.uucp> swilson@sun.UUCP (Scott Wilson) writes: >... What happens >to the names of routines used to implement standard library functions? >Don't these pollute the name space? Are implementations required to >work around this? For example can a pANS program with a routine >called write() reliably be compiled and run on a UNIX system without >causing printf (really _flsbuf) to call the user's routine and botching >everything? Does _flsbuf need to be rewritten to call __write() or >something similar... In a word, yes. The name-space pollution situation was a major disaster in the making, and X3J11 decided to call a halt to it. A conforming implementation can reserve those names specified in the standard, and only those names specified in the standard (including those specified as "reserved for future use"). All, repeat *all*, other names are open for use by the user, and the user must be able to use any, repeat *any*, other name without causing trouble. Which means that any extra functions needed by C-standard library functions must have names which are in the "reserved for the implementation" space. -- Allegedly heard aboard Mir: "A | Henry Spencer at U of Toronto Zoology toast to comrade Van Allen!!" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
guy@auspex.UUCP (Guy Harris) (01/21/89)
> Does _flsbuf need to be rewritten to call __write() or >something similar Yes. >where __write is implemented as: No. What I think AT&T plans to do for S5R4, for example, is to *rename* the "write" routine "_write", and have a mechanism by which the linker will let "_write" satisfy unresolved references for "write" (or something like that); this means programs that call "write" and expect it to be the "write" in the system library will not have to be changed - but neither will programs that have their own private "write". (Since "write" is usually implemented as a small assembly-language stub, "syscall" doesn't enter into it.)
blarson@skat.usc.edu (Bob Larson) (01/21/89)
In article <16653@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: ><14767@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >>cdecl is a keyword only because >>microsoft was to lazy to add a few #defines to their programs. It does >>nothing that could not be accomplished better in the preprocessing phase. >Well, I'm talking specifically about TurboC's use of the keywords; in >TC the 'cdecl' keyword means that a function follows the 'C' linking >and arg-passing conventions, and identifiers are case-sensitive and get >leading underbars, Simplified, cdecl means do things as they are done in C. > even though the overall default may be 'pascal'-like. The compiler option to change these overall defaults is the problem, eliminating it the proper solution, not cdecl. To change the calling convention from the norm, add a keyword to each fuction declaration that may change rather than adding the compiler flag. If there is a need to change the calling convention at compile time, just add a preprocesser token to all non-standard routines (such as CALLING_CONVENTION_OF_THIS_COMPILATION) and use the compiler switch to #define it to pascal or null or fortran. Prime C has the fortran keyword, and never found a need for the cdecl one. It also runs on a segmented processor (128k bytes each), and has no near, far, or huge keywords. (It does have the equivelent of large and huge model, which only affect how address computations are done on arrays whose size cannot be deduced at compile time.) -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/21/89)
In article <877@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >What I think AT&T plans to do for S5R4, for example, is to *rename* >the "write" routine "_write", and have a mechanism by which the linker >will let "_write" satisfy unresolved references for "write"... I believe they plan something along those lines, but it's important to note that it isn't really necessary to augment the linker in order to meet the ANSI C constraints; the C library can contain entries for both _write and write, with the standard C functions using only the former. The most significant drawback to the scheme is that both the C library and traditional programs that use write() and standard I/O will increase in size if there is actually redundant code with two names. If it weren't for the recent use of "random archive" tables of contents, but instead libraries were sequentially searched as in good old original UNIX, then the additional size could also be avoided using existing linkers by arranging for a 0-length module containing the "write" entry point occur immediately before the one with the code labeled "_write".
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/22/89)
In article <9008@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >> > What happens to the names of routines used to implement standard library >> > functions? Don't these pollute the name space? Are implementations >> > required to work around this? >> In a word, yes. >In a word, no--or at least not unless the standard has changed since the >version that prompted these words to X3J11: In a word, yes. Your letter was acted on during the third public review. I summarized your issue as: "Prohibit reservation of names other than what is specified." The Committee response was: "This was accepted as an editorial change to the Standard. Wording has been added to clarify this issue." I gather from recent postings that the authors of unregistered letters were not sent the official Committee responses to their issues. We were not really obligated to do so, but it would have been nice. I guess the expense was too much; I know *I* couldn't really afford to mail them. Anybody who wants to know a specific response send me e-mail and I'll try to look it up for you. (I took the files off-line a while back.)
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/23/89)
In article <1989Jan20.055826.26116@ziebmef.uucp> mdfreed@ziebmef.UUCP (Mark Freedman) writes: >btw I see that fstat() is not part of the ANSI stdio lib (unless I've missed >something). How does one determine the length of a file in a portable fashion ? No, fstat() was considered too much tailored to the UNIX environment for inclusion in a system-independent language specification. IEEE Std 1003.1 does specify it for POSIX environments. The "length" of a file is a tricky notion in many implementations, because it depends on how you count record structure overhead, padding, etc. The proposed ANSI C standard does specify that for a BINARY stream (one fopened with the "b" mode modifier), ftell() returns the number of bytes from the beginning of the file; therefore, you can use fopen(,"rb"), fseek(,0L,SEEK_END), ftell(), and fclose() to implement a function that returns the file's "length". Just how useful that information will be depends on what you plan to do with it; it may not be what you really need to know. >bbtw As I recall, Microsoft implements the volatile keyword syntactically >but not semantically. Unless they perform hyper-optimization, they may not NEED to do anything special in the case of "volatile". All that "volatile" does is warn the compiler that every access at that level of the type that is specified by the source code for the "C virtual machine" must in fact occur in the actual machine. Unoptimized generated machine code would naturally do that, and non-aggressive optimizations (such as Dennis originally put into his PDP-11 compiler) would preserve this property. It's when registers start getting used intelligently to "cache" values that optimizers tend to lose the natural volatile property of data objects. Any essential USE of volatility is necessarily implementation-dependent, so failure to implement it "right" cannot affect strictly-conforming programs. One presumes that if there is a reasonable use for volatility then MicroSoft would provide some way to obtain the desired effect, even if it requires use of "asm" (or better, _asm) or something else strange.
henry@utzoo.uucp (Henry Spencer) (01/24/89)
In article <9479@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >[volatile] Unoptimized generated machine code would naturally do >that, and non-aggressive optimizations (such as Dennis originally put >into his PDP-11 compiler) would preserve this property... Actually, some of the things that ended up in his peephole optimizer at some point broke said property, although not severely and not often. -- Allegedly heard aboard Mir: "A | Henry Spencer at U of Toronto Zoology toast to comrade Van Allen!!" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu