From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f890526de6a8a218 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!newsfeed2.telusplanet.net!newsfeed.telus.net!edtnps84.POSTED!53ab2750!not-for-mail Sender: blaak@BLIGHT Newsgroups: comp.lang.ada Subject: Re: How to detect OS type and version? References: <20051013115001.60b6a695@pscube.informatik.uni-stuttgart.de> From: Ray Blaak Message-ID: Organization: The Transcend X-Newsreader: Gnus v5.7/Emacs 20.7 Date: Sun, 16 Oct 2005 04:48:41 GMT NNTP-Posting-Host: 66.183.127.198 X-Trace: edtnps84 1129438121 66.183.127.198 (Sat, 15 Oct 2005 22:48:41 MDT) NNTP-Posting-Date: Sat, 15 Oct 2005 22:48:41 MDT Xref: g2news1.google.com comp.lang.ada:5717 Date: 2005-10-16T04:48:41+00:00 List-Id: Robert A Duff writes: > Ray Blaak writes: > > Simply adding a new OS to some central definition should not impact all > > existing code. In practical terms people should have had an "unknown OS" > > handler anyway. > > What is the directory separator character on "unknown OS"? ;-) I don't know, of course. The point is to have a plan for it. In the worst case you exit with the appropriate error message "unknown OS!". In practice you assume "Unix". > The advantage of using an enumeration type, and _not_ having an > Unknown_OS value, is that the compiler will tell you about all > the places you might need to change when you add a new OS. > That might or might not be what you want. That is the inherent advantage of using an enumerated type, of course. My point is that the nature of the information does not correspond to a known fixed set. > In my current project, I have two levels of distinction -- OS (Unix > vs. Windows, for example) and OS_Flavor (Solaris vs. Linux, for > example). I've not needed to distinguish (for example) different > versions of Linux, and it's probably a good idea to avoid that fine > level of distinction if possible. That you need only a few levels of distinction is a property of your current project, not a property of the set of known OS types. That should be separated. What I would do in your case is to make my own project-specific enumerated type and decide the appropriate current literal value at startup based on the the string-based values returned from querying the OS. If the reported OS value cannot be correlated to one of your assumed OS types, then you must decide what to do, which is likely to either assume it's a default known one (e.g. some sort of "generic" Unix) or else bail out. > > It's akin to having some app that processes first names as enumerated values > > instead of strings. It's a mistake because the set of values are open ended > > and are not known in advance, and can change depending on where you execute. > > You probably don't port to a new OS quite as often as you add names to > your database of telephone numbers or whatever. And you probably don't > use wildly different code based on first names, which needs updating > every time you add a new first name. That is essentially true in practice, I admit. I guess what I care about is that the built in OS query that would live somewhere under the System or Ada hierarchy would not return an enumerated type, but rather a string. That is, the enumeration should not be built into the language, since it is not at all a stable enough set of values for the long term. Imagine being able to code to an updated set only every 10 years, which seems to be Ada's upgrade cycle. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.