pourquoi "timer_t" est-il défini dans "time.h" sous Linux mais pas OS X

Pendant que je lisais un fichier de code source C, j'ai trouvé ces déclarations. (Ce code source a été écrit pour le programme système Linux. Il s'agit d'informations très importantes)

#include <time.h>
#include <stdio.h>

static timer_t* _interval_timer;
...

Au début, je voulais en savoir plus sur le 'timer_t'. J'ai donc recherché «time.h» sur Google pour obtenir des informations d'en-tête. Mais, il n'y avait pas de mots sur 'timer_t', mentionnant seulement 'time_t'.

Par curiosité, j'ai cherché et ouvert le fichier de bibliothèque standard 'time.h' c sur mon ordinateur 'mac' (comme vous le savez, le dossier / usr / include stocke les fichiers de bibliothèque standard c.) Mais ce fichier était le même que le précédent googlé.

Enfin, j'ai allumé mon système d'exploitation linux (ubuntu) à l'aide d'une machine virtuelle et ouvert le 'time.h' dans le dossier de bibliothèque standard linux c (le chemin du dossier est le même que OSX). Comme je m'y attendais, le fichier 'time.h' sous Linux a la déclaration de timer_t.

J'ai ajouté les lignes de code qui déclarent le type 'timer_t' ci-dessous.

#if !defined __timer_t_defined && \
((defined _TIME_H && defined __USE_POSIX199309) || defined __need_timer_t)
# define __timer_t_defined      1

# include <bits/types.h>

/* Timer ID returned by `timer_create'.  */
typedef __timer_t timer_t;

Ma question est la suivante.

Pourquoi 'timer_t' n'est défini que dans la bibliothèque standard linux c?
Cette situation se produit-elle souvent? Je veux dire, existe-t-il des fonctions ou des attributs définis différemment entre différents systèmes d'exploitation?

linux c darwin

— casamia
source

Le type timer_tn'est pas "uniquement défini sous linux", par exemple sous Windows / Cygwin, il est également défini. Selon les définitions des fichiers d'en-tête (Linux et Cygwin), il semble que ce soit un type standard POSIX. (Au-delà du fait que certaines plates-formes peuvent ne pas être conformes aux normes, je ne vois aucune situation spécifique qui "se produit couramment", comme vous l'avez formulée.) WRT votre question générale sur les différences dans les bibliothèques de langues; cela dépend si les fournisseurs respectent les normes ou avec quelles versions ils se conforment.

— Janis

Voici une référence de POSIX: pubs.opengroup.org/onlinepubs/009695399/functions/…

— teppic

@MarkPlotnick: C'est une réponse

— Courses de légèreté en orbite

@LightningRacisinObrit Je regrette d'avoir écrit une réponse (partielle) en tant que commentaire. Je l'ai retiré.

— Mark Plotnick

Réponses:

Unix et C ont une histoire entrelacée, car ils ont tous deux été développés à la même époque chez Bell Labs dans le New Jersey et l'un des principaux objectifs de C était d'implémenter Unix en utilisant un langage portable de haut niveau, indépendant de l'architecture. Cependant, il n'y a pas eu de normalisation officielle avant 1983. POSIX , "l'interface du système d'exploitation portable" est une norme de système d'exploitation IEEE datant de l'époque des "Guerres Unix" . Elle a évolué depuis et est désormais la norme la plus largement mise en œuvre. OSX est officiellement conforme à POSIX, et Linux officieusement - il y a une logistique et des coûts associés à la conformité officielle auxquels les distributions Linux ne participent pas.

Une grande partie de ce sur quoi POSIX s'est concentré est l'élaboration de choses qui ne font pas partie de l'ISO C. Time.h l'est, mais la version ISO n'inclut pas le timer_ttype ou les fonctions qui l'utilisent. Celles-ci proviennent de l'extension POSIX , d'où cette référence dans l'en-tête linux:

#if !defined __timer_t_defined && \
((defined _TIME_H && defined __USE_POSIX199309)

Le __USE_POSIX199309est un symbole de glibc interne qui est définie dans features.h quand _POSIX_C_SOURCE >= 199309L, ce qui signifie que POSIX.1b doit être pris en charge (voir feature_test_macros manpage). Ceci est également pris en charge avec _XOPEN_SOURCE >= 600.

Existe-t-il des fonctions ou des attributs définis différemment entre différents systèmes d'exploitation?

Je pense qu'en ce qui concerne C, parmi les systèmes POSIX, il y a un effort pour éviter cela, mais cela arrive. Certaines extensions GNU (par exemple sterror_r()) ont des signatures incompatibles de leurs homologues POSIX. Cela se produit peut-être lorsque POSIX prend l'extension mais la modifie, ou bien ce ne sont que des alternatives imaginées par GNU - vous pouvez opter pour l'une ou l'autre en utilisant une méthode appropriée #define.

— boucle d'or
source

Très agréable! Quelle gentille explication!

— casamia

Les normes POSIX et C visaient en partie à séparer C de Unix - les deux étaient si étroitement liés qu'il n'était parfois pas clair ce qui allait où.

— teppic

timer_test utilisé par les API timer_ dans POSIX, telles que timer_create(). Dans la version UNIX 03 de POSIX, ceux-ci sont une partie facultative de POSIX, et macOS ne l'a pas implémenté. Linux et Solaris, et peut-être d'autres UN * Xes, l'ont fait.

Le code que vous regardiez pourrait donc fonctionner sur Linux et Solaris, mais ne fonctionnera pas sur macOS, à moins qu'Apple n'implémente les API de temporisation à l'avenir. (Ils font partie de la version actuelle de la spécification POSIX, donc Apple devra le faire s'ils veulent se conformer à la version 4, plutôt qu'à la version 3, de la spécification.)

— user392227
source