... mais il va falloir attendre un siècle!
Plus exactement, 99 ans tout pile, jusqu'au 9 juin 2104.
Vous voyez toujours pas de quoi je parle? Un petit indice? Ben ça se passera très exactement le 9 juin 2104 à 05:10:42 du matin...
Toujours pas la moindre idée? Histoire de pousser un peu plus loin la précision, et de vous donner un nouvel indice, l'évènement tant attendu aura lieu le 9 juin 2104 à 05:10:42 et 424 millièmes du matin!
Comment ça vous avez toujours pas deviné?!?! Mais quelle epoch vivons-nous, c'est incroyable l'inculture des jeunes gens de nos jours...
# May the 64bits be with you !
Posté par zephred . Évalué à 8.
[^] # Re: May the 64bits be with you !
Posté par Julien CARTIGNY (site web personnel) . Évalué à 10.
[^] # Re: May the 64bits be with you !
Posté par imalip . Évalué à 3.
[^] # Re: May the 64bits be with you !
Posté par XHTML/CSS inside (site web personnel) . Évalué à 8.
J'arriiiiiiiiiive =======>[]
[^] # Re: May the 64bits be with you !
Posté par SoWhat . Évalué à 1.
Malheureusement je n'ai pas de machine 64 bits sous la main pour vérifier, mais j'aurais tendance à penser que le long est toutjours codé sur 32 bits, alors que le 'long long int' est lui codé sur 64.
[^] # Re: May the 64bits be with you !
Posté par totof2000 . Évalué à 1.
Il me semble si j'ai bien suivi mes cours de C qu'un int correspond a un entier codé sur 16 bits pour un proc 16 bits, 32 bits pour un proc 32 bits, et sur archi 64 bits, ca correspond a 64 bits.
Donc un long int devrait faire 128 bits sur archi 64 bits.
....
[^] # Re: May the 64bits be with you !
Posté par Anonyme . Évalué à 7.
[^] # Re: May the 64bits be with you !
Posté par Sisyphe Plâtrier . Évalué à 1.
Ce que j'avais retenu, c'est
char < short int
short int <= int
int <= long int
long int < long long int quand ça existe.
En général int a le nombre de bits du bus de données de l'architecture. Parfois c'est tombé sur un nombre qui n'était pas une puissance (entière) de 2.
[^] # Re: May the 64bits be with you !
Posté par Anonyme . Évalué à 3.
[^] # Re: May the 64bits be with you !
Posté par imalip . Évalué à 3.
char <= short int
C'est comme ca qu'on peut se retrouver avec une archi ou :
char == short int == long int == int
Le truc amusant c'est de faire une pile UDP/TCP/IP avec ca. Vous aimez les masques et les decalages ? (oui, c'est du vecu)
[^] # Re: May the 64bits be with you !
Posté par Florent C. . Évalué à -3.
Donc, pour résumer, en C, seule la taille du type char est garantie par la norme : un octet, soit un byte de 8 bits.
D'ailleurs, le fait que les bytes fassent 8 bits sur l'architecture proposée est la condition sine qua none à toute implémentation du langage.
[^] # Re: May the 64bits be with you !
Posté par ckyl . Évalué à 3.
Tu confonds byte et octet. La taille du char n'est pas garantie; ce qui l'est c'est sizeof(char) == 1 byte ce qui est bien différent. Par contre un char doit faire au moins 8 bits c'est indiqué par la section 5.2.4.2.1 du C99 avec la macro CHAR_BIT. CHAR_BIT défini combien il y a de bits dans un byte.
Si tu veux des types de taille connu tu utilises le C99 et les types défini dans <stdint.h>
[^] # Re: May the 64bits be with you !
Posté par Guillaume G. . Évalué à 3.
[^] # Re: May the 64bits be with you !
Posté par ckyl . Évalué à 4.
L'article de wikipédia donne une bonne base, http://en.wikipedia.org/wiki/Byte(...) . La clause qui défini le byte est celle-ci : "addressable unit of data storage large enough to hold any member of the basic character set of the execution environment" [1]. Comme indiqué plus haut la taille minimale d'un byte est de 8, il n'y a pas de taille maximale. On connait la taille sur l'environement courant à l'aide de CHAR_BIT. Il me semble que la traduction française de byte est multiplet.
L'octet, en français ou en anglais, est un groupe de 8 bits.
> Quelle honte pour moi et pour le système universitaire de ce pays...
Les profs sont bien trop occupés à expliquer qu'il faut initialiser ses données ou allouer sa mémoire. Le C est souvent considéré comme facile car il y a peu de concepts de haut niveau. On peut coder un "Hello world" sans avoir besoin de 25h de cours théorique pour comprendre ce que l'on fait [2]. Pourtant c'est un langage très, trop, complexe avec une norme imbitable issu de 30 ans de normalisation, des comportements à la con partout [3]. Le C c'est le Pentium des langages. C'est pourri mais tout le monde utilise.
[1] Pour le folklore undefined behavior et unspecified behavoir sont défini avant le byte, tout l'état d'esprit du C :-)
[2] Essayez d'expliquer chaque ligne d'un Hello World en java...
[3] S'en chercher bien loin, défninir le comportement de fonctions basiques telles que snprintf/strncat/strncpy sans s'aider de la page de man.
[^] # Re: May the 64bits be with you !
Posté par Florent C. . Évalué à -2.
Relis ce que j'ai écrit : "un octet, soit un byte de 8 bits." C'est pas clair ?
Sinon pour le reste il me semble que je dis la même chose que toi.
[^] # Re: May the 64bits be with you !
Posté par ckyl . Évalué à 2.
Bha non c'est totalement faux
http://www-s.ti.com/sc/psheets/spru034h/spru034h.pdf(...) page 101. Un exemple de plateforme sur lequel les char sont sur 32 bits.
La dessus sizeof(char) == sizeof(short) == sizeof(int) == 1. Et un byte fait 32 bits.
[^] # Re: May the 64bits be with you !
Posté par Florent C. . Évalué à -2.
Je voulais dire au moins 8 bits
[^] # Re: May the 64bits be with you !
Posté par ckyl . Évalué à 2.
Les implémentations doivent fournir des types qui couvrent AU MOINS ces plages de valeurs la:
short : -32767 .. +32767
int: -32767 .. +32767
long: -2147483647 .. +2147483647
Ces valeurs sont contenues dans (SHORT|INT|LONG)_(MIN|MAX) dans <stdint.h>
Après les implémentations peuvent faire ce quelles veulent. On notera aussi une référence qui indique que le int devrait de préférence est le mot machine (avec la contrainte énnoncée ci dessus).
Ainsi on a un short qui est au moins sur 2 octets, et pas bytes, un int est aussi au moins sur 2 octets un long au moins sur 4.
> Donc un long int devrait faire 128 bits sur archi 64 bits.
Rien est moins sur. Il n'y a aucune mention d'un type 128 bits dans le C99. Les plus grand que l'on trouvent sont le long long qui lui est obligatoirement sur au moins 64 bits et le int64_t qui lui est exactement sur 64 bits (un long long correspondant à un int_least64_t).
[^] # Re: May the 64bits be with you !
Posté par Raphael Junqueira . Évalué à 3.
Par contre sous windows (histoire d'emmerder le monde) le long reste 32bits (il faut alors utiliser le tres portable __int64)
[^] # Re: May the 64bits be with you ! time_t fait pour cela
Posté par free2.org . Évalué à 3.
Ouais enfin c'est pas bien dur de changer le typedef pour en faire ce qu'on veux !
C'est même d'ailleurs exactement pour cela que time_t est utilisé, et pas autre chose.
[^] # Re: May the 64bits be with you !
Posté par gc (site web personnel) . Évalué à 3.
p4:
int:4
long int:4
long long:8
long long int:8
amd64:
int:4
long int:8
long long:8
long long int:8
# ...
Posté par Mr Kapouik (site web personnel) . Évalué à 4.
[^] # Re: ...
Posté par boris . Évalué à 10.
[^] # Re: ...
Posté par lsartran . Évalué à 7.
[^] # Re: ...
Posté par nicoprog . Évalué à 4.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les enfants, un grand moment de l'Histoire se prépare...
Posté par yoho (site web personnel) . Évalué à 2.
# Timestamp
Posté par alexissoft . Évalué à 4.
[^] # Re: Timestamp
Posté par WH (site web personnel) . Évalué à 3.
# C'est un signe !
Posté par olosta . Évalué à 5.
Désolé....
Quoi qu'il en soit, essayez de voir la bande annonce d'h2g2 elle est énorme.
[^] # Re: C'est un signe !
Posté par Sixel . Évalué à 2.
Désolé....
Mais faut pas, car tu commences à chauffer!
Quoi qu'il en soit, essayez de voir la bande annonce d'h2g2 elle est énorme.
Absolument, mais ça va être trooooooop long d'attendre cet été...
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
# lol
Posté par Anonyme . Évalué à -4.
C'est drole en lisant ton journal j'ai deviné que c'etait toi ;)
[^] # Re: lol (à chaque fois que tu lol, c'est un petit chaton qui meurt)
Posté par Sixel . Évalué à 2.
Et ben figure-toi que j'ai eu exactement le même sentiment à ton égard à la lecture de ce commentaire : http://linuxfr.org/comments/586373.html#586373(...)
Clair, concis, efficace, du nard' dans ses grands jours :D
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
# 2038
Posté par boris . Évalué à 10.
[^] # Re: 2038
Posté par Sasuke . Évalué à 3.
[^] # Re: 2038
Posté par Mark Havel . Évalué à 2.
[^] # Re: 2038
Posté par Mr YouP . Évalué à 6.
(j'ai eu chaud)
[^] # Re: 2038
Posté par dab . Évalué à 8.
Tu as raison, il faut être optimiste.
[^] # Re: 2038
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
# erreur de calcul
Posté par fabien . Évalué à 10.
2^32 = 2147483648 secondes soit 596523 heures 14 min et 8 sec depuis le 1er janvier 1970.
ce qui nous fait exactment le 19 janvier 2038 a 3h14 et 8 secondes du matin.
voilà.
[^] # Re: erreur de calcul
Posté par fabien . Évalué à 2.
[^] # Re: erreur de calcul
Posté par Maxime (site web personnel) . Évalué à 2.
[^] # Re: erreur de calcul
Posté par fabien . Évalué à 3.
j'ai donc appuyé sur "poster un commentaire" sans avoir fais de reload.
je ne sais pas combien de temps j'ai mis pour le calculer, mais c'est un peu plus compliqué que faire 1 plus 1. tu t'en doute j'espere.
j'ai converti le 1/1/1970 en jour julien pour y additionner les jours (24855), et puis j'ai reconverti dans l'autre sens. il y a peut être plus simple, si tu veux je te donne le detail du calcul :)
PS : là ou je me suis dit que c'est n'importe quoi c'est quand il a été question de milieme... alors qu'on ne copte que des secondes
[^] # Re: erreur de calcul
Posté par boris . Évalué à 3.
Il y avait plus simple pour ton calcul, effectivement : http://en.wikipedia.org/wiki/Unix_time(...) :)
[^] # Re: erreur de calcul
Posté par fabien . Évalué à 2.
par principe, et comme je sais le faire, j'aime bien calculer moi même. c'est comme avec le logiciel libre, certains aiment bien compiler eux-même (adepte de LFS bonsoir)
[^] # Re: erreur de calcul
Posté par fabien . Évalué à 2.
PS : au passage je me suis planté d'une seconde
---
cat findumonde.c << EOF
#include <stdio.h>
#include <stdint.h>
#include <time.h>
int main(void)
{
time_t t = INT32_MAX;
struct tm *gmt = gmtime(&t);
printf(asctime(gmt));
}
EOF
gcc -o t findumonde.c && ./t
Tue Jan 19 03:14:07 2038
La borne sup, c'est pas 2^31 mais 2^31-1 :-)
[^] # Re: erreur de ... code
Posté par Christophe HENRY (site web personnel) . Évalué à 3.
....
cat > findumonde.c << EOF
#include <stdio.h>
#include <stdint.h>
#include <time.h>
int main(void)
{
time_t t = INT32_MAX;
struct tm *gmt = gmtime(&t);
printf(asctime(gmt));
}
EOF
Ne pas oublier la redirection de fichier, le > après cat
[^] # Re: erreur de calcul
Posté par WH (site web personnel) . Évalué à 2.
# Hurd et E17
Posté par Beretta_Vexee . Évalué à 3.
[^] # Re: Hurd et E17
Posté par Thomas Maurin (site web personnel) . Évalué à 4.
# Normalement, ceci est le 42ème commentaire, ca tombe bien...
Posté par Sixel . Évalué à 2.
System.out.println(new SimpleDateFormat("dd/MM/yyyy HH:mm:ss SSS").parse("09/06/2104 05:10:42 424").getTime());
Et n'oubliez pas votre serviette!
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.