Le 27-05-2010, ? propos de Unix pour autre processeur que i386...., David Remacle ?crivait dans fr.comp.os.unix :
Bonjour,
Bonjour,
J'ai cherché via google pour savoir si il y a des systèmes Unix certifié unix 03 mais qui ne sont pas pour processeur intel...
Car j'ai vu que Leopard avait été certifié unix 03 uniquement pour intel et pas pour les processeur ppc.
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03. MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui concerne les sémaphores.
Je me demandais alors si la certification unix 03 était surtout pour les processeur intel.
Je ne vois pas pourquoi. Solaris est Unix 03 pour sparc.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 27-05-2010, ? propos de
Unix pour autre processeur que i386....,
David Remacle ?crivait dans fr.comp.os.unix :
Bonjour,
Bonjour,
J'ai cherché via google pour savoir si il y a des systèmes Unix certifié
unix 03 mais qui ne sont pas pour processeur intel...
Car j'ai vu que Leopard avait été certifié unix 03 uniquement pour intel
et pas pour les processeur ppc.
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03.
MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui
concerne les sémaphores.
Je me demandais alors si la certification unix 03 était surtout pour les
processeur intel.
Je ne vois pas pourquoi. Solaris est Unix 03 pour sparc.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 27-05-2010, ? propos de Unix pour autre processeur que i386...., David Remacle ?crivait dans fr.comp.os.unix :
Bonjour,
Bonjour,
J'ai cherché via google pour savoir si il y a des systèmes Unix certifié unix 03 mais qui ne sont pas pour processeur intel...
Car j'ai vu que Leopard avait été certifié unix 03 uniquement pour intel et pas pour les processeur ppc.
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03. MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui concerne les sémaphores.
Je me demandais alors si la certification unix 03 était surtout pour les processeur intel.
Je ne vois pas pourquoi. Solaris est Unix 03 pour sparc.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
David Remacle wrote in message <1jj5sch.s0otcb7d1ieeN%:
J'ai cherché via google pour savoir si il y a des systèmes Unix certifié unix 03 mais qui ne sont pas pour processeur intel...
Quel intérêt ? Cette certification est un torchon sans valeur (exemple : macos, très fier de sa certification, est non-conforme sur le comportement de realloc sur un pointeur nul).
David Remacle wrote in message
<1jj5sch.s0otcb7d1ieeN%david.remacle@nospamfree.fr>:
J'ai cherché via google pour savoir si il y a des systèmes Unix certifié
unix 03 mais qui ne sont pas pour processeur intel...
Quel intérêt ? Cette certification est un torchon sans valeur (exemple :
macos, très fier de sa certification, est non-conforme sur le comportement
de realloc sur un pointeur nul).
David Remacle wrote in message <1jj5sch.s0otcb7d1ieeN%:
J'ai cherché via google pour savoir si il y a des systèmes Unix certifié unix 03 mais qui ne sont pas pour processeur intel...
Quel intérêt ? Cette certification est un torchon sans valeur (exemple : macos, très fier de sa certification, est non-conforme sur le comportement de realloc sur un pointeur nul).
david.remacle
JKB wrote:
Le 27-05-2010, ? propos de Unix pour autre processeur que i386...., David Remacle ?crivait dans fr.comp.os.unix : > Bonjour,
Bonjour,
> J'ai cherché via google pour savoir si il y a des systèmes Unix certifié > unix 03 mais qui ne sont pas pour processeur intel... > > Car j'ai vu que Leopard avait été certifié unix 03 uniquement pour intel > et pas pour les processeur ppc.
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03. MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui concerne les sémaphores.
> Je me demandais alors si la certification unix 03 était surtout pour les > processeur intel.
Je ne vois pas pourquoi. Solaris est Unix 03 pour sparc.
JKB
merci pour ses précision JKB :)
JKB <knatschke@koenigsberg.fr> wrote:
Le 27-05-2010, ? propos de
Unix pour autre processeur que i386....,
David Remacle ?crivait dans fr.comp.os.unix :
> Bonjour,
Bonjour,
> J'ai cherché via google pour savoir si il y a des systèmes Unix certifié
> unix 03 mais qui ne sont pas pour processeur intel...
>
> Car j'ai vu que Leopard avait été certifié unix 03 uniquement pour intel
> et pas pour les processeur ppc.
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03.
MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui
concerne les sémaphores.
> Je me demandais alors si la certification unix 03 était surtout pour les
> processeur intel.
Je ne vois pas pourquoi. Solaris est Unix 03 pour sparc.
Le 27-05-2010, ? propos de Unix pour autre processeur que i386...., David Remacle ?crivait dans fr.comp.os.unix : > Bonjour,
Bonjour,
> J'ai cherché via google pour savoir si il y a des systèmes Unix certifié > unix 03 mais qui ne sont pas pour processeur intel... > > Car j'ai vu que Leopard avait été certifié unix 03 uniquement pour intel > et pas pour les processeur ppc.
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03. MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui concerne les sémaphores.
> Je me demandais alors si la certification unix 03 était surtout pour les > processeur intel.
Je ne vois pas pourquoi. Solaris est Unix 03 pour sparc.
JKB
merci pour ses précision JKB :)
Éric Lévénez
Le 27/05/10 16:29, David Remacle a écrit :
J'ai cherché via google pour savoir si il y a des systèmes Unix certifié unix 03 mais qui ne sont pas pour processeur intel...
Bien sûr : <http://www.opengroup.org/openbrand/register/xy.htm>
Car j'ai vu que Leopard avait été certifié unix 03 uniquement pour intel et pas pour les processeur ppc.
Pourquoi Apple aurait payé pour une certification coûteuse sur un CPU qui était abandonné officiellement ?
Je me demandais alors si la certification unix 03 était surtout pour les processeur intel.
Non.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/05/10 16:29, David Remacle a écrit :
J'ai cherché via google pour savoir si il y a des systèmes Unix certifié
unix 03 mais qui ne sont pas pour processeur intel...
Bien sûr : <http://www.opengroup.org/openbrand/register/xy.htm>
Car j'ai vu que Leopard avait été certifié unix 03 uniquement pour intel
et pas pour les processeur ppc.
Pourquoi Apple aurait payé pour une certification coûteuse sur un CPU
qui était abandonné officiellement ?
Je me demandais alors si la certification unix 03 était surtout pour les
processeur intel.
Non.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
J'ai cherché via google pour savoir si il y a des systèmes Unix certifié unix 03 mais qui ne sont pas pour processeur intel...
Bien sûr : <http://www.opengroup.org/openbrand/register/xy.htm>
Car j'ai vu que Leopard avait été certifié unix 03 uniquement pour intel et pas pour les processeur ppc.
Pourquoi Apple aurait payé pour une certification coûteuse sur un CPU qui était abandonné officiellement ?
Je me demandais alors si la certification unix 03 était surtout pour les processeur intel.
Non.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 27/05/10 16:35, JKB a écrit :
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03. MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui concerne les sémaphores.
Et si tu parles des sémaphores anomynes, tu oublies d'indiquer que les sémaphores sont une option de Posix. Et que des options il y en a des tas comme les threads, les timers... Et dans ces options, il est possible de n'implémenter que certains sous-systèmes, des sous-options.
Je ne sais même pas si il existe un système qui implémente toutes les options définies et toutes les options de ces options.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/05/10 16:35, JKB a écrit :
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03.
MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui
concerne les sémaphores.
Et si tu parles des sémaphores anomynes, tu oublies d'indiquer que les
sémaphores sont une option de Posix. Et que des options il y en a des
tas comme les threads, les timers... Et dans ces options, il est
possible de n'implémenter que certains sous-systèmes, des sous-options.
Je ne sais même pas si il existe un système qui implémente toutes les
options définies et toutes les options de ces options.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03. MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui concerne les sémaphores.
Et si tu parles des sémaphores anomynes, tu oublies d'indiquer que les sémaphores sont une option de Posix. Et que des options il y en a des tas comme les threads, les timers... Et dans ces options, il est possible de n'implémenter que certains sous-systèmes, des sous-options.
Je ne sais même pas si il existe un système qui implémente toutes les options définies et toutes les options de ces options.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
tth
Nicolas George a raconté :
Quel intérêt ? Cette certification est un torchon sans valeur (exemple : macos, très fier de sa certification, est non-conforme sur le comportement de realloc sur un pointeur nul).
Quelques détails sur ce realloc pommé ?
Nicolas George a raconté :
Quel intérêt ? Cette certification est un torchon sans valeur (exemple :
macos, très fier de sa certification, est non-conforme sur le
comportement de realloc sur un pointeur nul).
Quel intérêt ? Cette certification est un torchon sans valeur (exemple : macos, très fier de sa certification, est non-conforme sur le comportement de realloc sur un pointeur nul).
Quelques détails sur ce realloc pommé ?
JKB
Le 27-05-2010, ? propos de Re: Unix pour autre processeur que i386...., Éric Lévénez ?crivait dans fr.comp.os.unix :
Le 27/05/10 16:35, JKB a écrit :
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03. MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui concerne les sémaphores.
Et si tu parles des sémaphores anomynes, tu oublies d'indiquer que les sémaphores sont une option de Posix. Et que des options il y en a des tas comme les threads, les timers... Et dans ces options, il est possible de n'implémenter que certains sous-systèmes, des sous-options.
Je ne sais même pas si il existe un système qui implémente toutes les options définies et toutes les options de ces options.
Ce qui fait surtout tache pour un truc pensé aussi longtemps que Posix, c'est qu'il est parfaitement impossible d'écrire une macro remplaçant les appels aux sémaphores anonymes par des appels aux sémaphores nommés. Résultat des courses, tu caviardes ton code à grands coups de #ifdef Darwin... Passons.
Je trouve aussi que certaines fonctions de base devraient faire partie du socle commun Posix et que MacOS X en oublie quelques unes. Après, on peut ergoter sur le fait qu'il s'agit de fonctions optionnelles. Le fait est qu'on utilise certainement plus facilement sem_init() que les projections sur les sphères de Riemann.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 27-05-2010, ? propos de
Re: Unix pour autre processeur que i386....,
Éric Lévénez ?crivait dans fr.comp.os.unix :
Le 27/05/10 16:35, JKB a écrit :
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03.
MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui
concerne les sémaphores.
Et si tu parles des sémaphores anomynes, tu oublies d'indiquer que les
sémaphores sont une option de Posix. Et que des options il y en a des
tas comme les threads, les timers... Et dans ces options, il est
possible de n'implémenter que certains sous-systèmes, des sous-options.
Je ne sais même pas si il existe un système qui implémente toutes les
options définies et toutes les options de ces options.
Ce qui fait surtout tache pour un truc pensé aussi longtemps que
Posix, c'est qu'il est parfaitement impossible d'écrire une macro
remplaçant les appels aux sémaphores anonymes par des appels aux
sémaphores nommés. Résultat des courses, tu caviardes ton code à
grands coups de #ifdef Darwin... Passons.
Je trouve aussi que certaines fonctions de base devraient faire
partie du socle commun Posix et que MacOS X en oublie quelques unes.
Après, on peut ergoter sur le fait qu'il s'agit de fonctions
optionnelles. Le fait est qu'on utilise certainement plus facilement
sem_init() que les projections sur les sphères de Riemann.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 27-05-2010, ? propos de Re: Unix pour autre processeur que i386...., Éric Lévénez ?crivait dans fr.comp.os.unix :
Le 27/05/10 16:35, JKB a écrit :
Il me semblait qu'il fallait être POSIX 2001 pour être Unix 03. MacOS X n'est pas entièrement POSIX 2001, au moins en ce qui concerne les sémaphores.
Et si tu parles des sémaphores anomynes, tu oublies d'indiquer que les sémaphores sont une option de Posix. Et que des options il y en a des tas comme les threads, les timers... Et dans ces options, il est possible de n'implémenter que certains sous-systèmes, des sous-options.
Je ne sais même pas si il existe un système qui implémente toutes les options définies et toutes les options de ces options.
Ce qui fait surtout tache pour un truc pensé aussi longtemps que Posix, c'est qu'il est parfaitement impossible d'écrire une macro remplaçant les appels aux sémaphores anonymes par des appels aux sémaphores nommés. Résultat des courses, tu caviardes ton code à grands coups de #ifdef Darwin... Passons.
Je trouve aussi que certaines fonctions de base devraient faire partie du socle commun Posix et que MacOS X en oublie quelques unes. Après, on peut ergoter sur le fait qu'il s'agit de fonctions optionnelles. Le fait est qu'on utilise certainement plus facilement sem_init() que les projections sur les sphères de Riemann.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 28-05-2010, ? propos de Re: Unix pour autre processeur que i386...., tth ?crivait dans fr.comp.os.unix :
Nicolas George a raconté :
Quel intérêt ? Cette certification est un torchon sans valeur (exemple : macos, très fier de sa certification, est non-conforme sur le comportement de realloc sur un pointeur nul).
Quelques détails sur ce realloc pommé ?
J'allais poser la même question parce que je ne suis jamais tombé sur ce problème (pourtant, des problèmes de malloc(), realloc() et free(), j'en ai vu des beaux...) et que la page man de MacOS X (10.5.8) que j'ai sous la main ne spécifie rien de particulier. Le malloc en question semble être celui de BSD.
Ce qui est plus amusant (enfin, si je puis dire), c'est que certaines fonctions de la libc de MacOS censées utiliser malloc() pour allouer son résultat utilise une version _statique_ (car _inline_ du malloc, ce qui fait que l'utilisation d'un autre allocateur par un programme le fait planter à moins de surcharger tous les appels systèmes foireux. Je pense en particulier à strdup()...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 28-05-2010, ? propos de
Re: Unix pour autre processeur que i386....,
tth ?crivait dans fr.comp.os.unix :
Nicolas George a raconté :
Quel intérêt ? Cette certification est un torchon sans valeur (exemple :
macos, très fier de sa certification, est non-conforme sur le
comportement de realloc sur un pointeur nul).
Quelques détails sur ce realloc pommé ?
J'allais poser la même question parce que je ne suis jamais tombé
sur ce problème (pourtant, des problèmes de malloc(), realloc() et
free(), j'en ai vu des beaux...) et que la page man de MacOS X
(10.5.8) que j'ai sous la main ne spécifie rien de particulier. Le
malloc en question semble être celui de BSD.
Ce qui est plus amusant (enfin, si je puis dire), c'est que
certaines fonctions de la libc de MacOS censées utiliser malloc()
pour allouer son résultat utilise une version _statique_ (car
_inline_ du malloc, ce qui fait que l'utilisation d'un autre allocateur
par un programme le fait planter à moins de surcharger tous les appels
systèmes foireux. Je pense en particulier à strdup()...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 28-05-2010, ? propos de Re: Unix pour autre processeur que i386...., tth ?crivait dans fr.comp.os.unix :
Nicolas George a raconté :
Quel intérêt ? Cette certification est un torchon sans valeur (exemple : macos, très fier de sa certification, est non-conforme sur le comportement de realloc sur un pointeur nul).
Quelques détails sur ce realloc pommé ?
J'allais poser la même question parce que je ne suis jamais tombé sur ce problème (pourtant, des problèmes de malloc(), realloc() et free(), j'en ai vu des beaux...) et que la page man de MacOS X (10.5.8) que j'ai sous la main ne spécifie rien de particulier. Le malloc en question semble être celui de BSD.
Ce qui est plus amusant (enfin, si je puis dire), c'est que certaines fonctions de la libc de MacOS censées utiliser malloc() pour allouer son résultat utilise une version _statique_ (car _inline_ du malloc, ce qui fait que l'utilisation d'un autre allocateur par un programme le fait planter à moins de surcharger tous les appels systèmes foireux. Je pense en particulier à strdup()...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Éric Lévénez
Le 28/05/10 09:18, JKB a écrit :
Je trouve aussi que certaines fonctions de base devraient faire partie du socle commun Posix et que MacOS X en oublie quelques unes. Après, on peut ergoter sur le fait qu'il s'agit de fonctions optionnelles. Le fait est qu'on utilise certainement plus facilement sem_init() que les projections sur les sphères de Riemann.
Pendant des années j'ai utilisé des Unix où pipe() était bidirectionnel grâce aux STREAMS qui sont Posix, mais il y a maintenant tellement d'implémentation Posix sans les STREAMS que le pipe revient 40 ans en arrière avec une implémentation garantie monodirectionnelle. Chacun voit les limites de la norme là où il travaille...
C'est comme pour le langage C. J'utilise beaucoup les calculs complexes du C99 alors que d'autres utilisateurs peuvent se contenter d'un ancien compilateur (15 ou 20 ans) sans ces calculs complexes.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 28/05/10 09:18, JKB a écrit :
Je trouve aussi que certaines fonctions de base devraient faire
partie du socle commun Posix et que MacOS X en oublie quelques unes.
Après, on peut ergoter sur le fait qu'il s'agit de fonctions
optionnelles. Le fait est qu'on utilise certainement plus facilement
sem_init() que les projections sur les sphères de Riemann.
Pendant des années j'ai utilisé des Unix où pipe() était bidirectionnel
grâce aux STREAMS qui sont Posix, mais il y a maintenant tellement
d'implémentation Posix sans les STREAMS que le pipe revient 40 ans en
arrière avec une implémentation garantie monodirectionnelle. Chacun voit
les limites de la norme là où il travaille...
C'est comme pour le langage C. J'utilise beaucoup les calculs complexes
du C99 alors que d'autres utilisateurs peuvent se contenter d'un ancien
compilateur (15 ou 20 ans) sans ces calculs complexes.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Je trouve aussi que certaines fonctions de base devraient faire partie du socle commun Posix et que MacOS X en oublie quelques unes. Après, on peut ergoter sur le fait qu'il s'agit de fonctions optionnelles. Le fait est qu'on utilise certainement plus facilement sem_init() que les projections sur les sphères de Riemann.
Pendant des années j'ai utilisé des Unix où pipe() était bidirectionnel grâce aux STREAMS qui sont Posix, mais il y a maintenant tellement d'implémentation Posix sans les STREAMS que le pipe revient 40 ans en arrière avec une implémentation garantie monodirectionnelle. Chacun voit les limites de la norme là où il travaille...
C'est comme pour le langage C. J'utilise beaucoup les calculs complexes du C99 alors que d'autres utilisateurs peuvent se contenter d'un ancien compilateur (15 ou 20 ans) sans ces calculs complexes.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
JKB
Le 28-05-2010, ? propos de Re: Unix pour autre processeur que i386...., Éric Lévénez ?crivait dans fr.comp.os.unix :
Le 28/05/10 09:18, JKB a écrit :
Je trouve aussi que certaines fonctions de base devraient faire partie du socle commun Posix et que MacOS X en oublie quelques unes. Après, on peut ergoter sur le fait qu'il s'agit de fonctions optionnelles. Le fait est qu'on utilise certainement plus facilement sem_init() que les projections sur les sphères de Riemann.
Pendant des années j'ai utilisé des Unix où pipe() était bidirectionnel grâce aux STREAMS qui sont Posix, mais il y a maintenant tellement d'implémentation Posix sans les STREAMS que le pipe revient 40 ans en arrière avec une implémentation garantie monodirectionnelle. Chacun voit les limites de la norme là où il travaille...
C'est comme pour le langage C. J'utilise beaucoup les calculs complexes du C99 alors que d'autres utilisateurs peuvent se contenter d'un ancien compilateur (15 ou 20 ans) sans ces calculs complexes.
Je ne me pose pas ce genre de questions. Tous les calculs complexes sont faits chez moi en Fortran. L'interface vers le C est faite avec BIND=C et je n'ai plus de problèmes...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 28-05-2010, ? propos de
Re: Unix pour autre processeur que i386....,
Éric Lévénez ?crivait dans fr.comp.os.unix :
Le 28/05/10 09:18, JKB a écrit :
Je trouve aussi que certaines fonctions de base devraient faire
partie du socle commun Posix et que MacOS X en oublie quelques unes.
Après, on peut ergoter sur le fait qu'il s'agit de fonctions
optionnelles. Le fait est qu'on utilise certainement plus facilement
sem_init() que les projections sur les sphères de Riemann.
Pendant des années j'ai utilisé des Unix où pipe() était bidirectionnel
grâce aux STREAMS qui sont Posix, mais il y a maintenant tellement
d'implémentation Posix sans les STREAMS que le pipe revient 40 ans en
arrière avec une implémentation garantie monodirectionnelle. Chacun voit
les limites de la norme là où il travaille...
C'est comme pour le langage C. J'utilise beaucoup les calculs complexes
du C99 alors que d'autres utilisateurs peuvent se contenter d'un ancien
compilateur (15 ou 20 ans) sans ces calculs complexes.
Je ne me pose pas ce genre de questions. Tous les calculs complexes
sont faits chez moi en Fortran. L'interface vers le C est faite avec
BIND=C et je n'ai plus de problèmes...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 28-05-2010, ? propos de Re: Unix pour autre processeur que i386...., Éric Lévénez ?crivait dans fr.comp.os.unix :
Le 28/05/10 09:18, JKB a écrit :
Je trouve aussi que certaines fonctions de base devraient faire partie du socle commun Posix et que MacOS X en oublie quelques unes. Après, on peut ergoter sur le fait qu'il s'agit de fonctions optionnelles. Le fait est qu'on utilise certainement plus facilement sem_init() que les projections sur les sphères de Riemann.
Pendant des années j'ai utilisé des Unix où pipe() était bidirectionnel grâce aux STREAMS qui sont Posix, mais il y a maintenant tellement d'implémentation Posix sans les STREAMS que le pipe revient 40 ans en arrière avec une implémentation garantie monodirectionnelle. Chacun voit les limites de la norme là où il travaille...
C'est comme pour le langage C. J'utilise beaucoup les calculs complexes du C99 alors que d'autres utilisateurs peuvent se contenter d'un ancien compilateur (15 ou 20 ans) sans ces calculs complexes.
Je ne me pose pas ce genre de questions. Tous les calculs complexes sont faits chez moi en Fortran. L'interface vers le C est faite avec BIND=C et je n'ai plus de problèmes...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
