English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Distinguish between osx and linux programmatically
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-07-08 (17:47)
From: Romain Beauxis <toots@r...>
Subject: Re: [Caml-list] Distinguish between osx and linux programmatically
Le jeudi 8 juillet 2010 12:01:24, Richard Jones a écrit :
> Actually I misunderstood the link I posted
> (http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html#NOTES)
> thinking it meant that the string fields in the structure could have
> variable width.  Reading it again, they don't.

And they are terminated by a '\0' symbol so we can pass them to 

> Nevertheless I still think this is not a useful addition to stdlib,
> but for different reasons:
> (1) You'd have to emulate it on non-Unix platforms, but it's unclear
> what you'd emulate it with.  Windows has a completely different and
> much richer concept of OS version.  This sort of version probing
> complexity doesn't belong in the core library, but in an external "OS
> version" library where detection rules can be frequently updated.

Well, we already have emulation for many things in OCaml, including much more 
complex parts of the POSIX/UNIX API, like signals, select, threads etc..

Most of these functions, when not implemented raise a (mostly) undocumented 
exception on Windows..

I see no reason why the uname "emulation" could not as well raise an exception 
when it is not implemented (e.g. under Win32).

> (2) Your program only ever calls out to uname once.  The cost of
> running an external program is negligible.

In the general case, I prefer to avoid running external programs. This is way 
to much OS-dependent. A builting alternative, if available, is always better..