Journal Les enfants, un grand moment de l'Histoire se prépare...

Posté par  .
Étiquettes : aucune
0
9
juin
2005
... 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  . Évalué à 8.

    Il se sera écoulé 2^32 secondes depuis le 1er janvier 1970. Mais d'ici là, toutes les bécanes seront, au moins, en 64bits, je ne me fait donc pas trop de soucis ! ;-P
    • [^] # Re: May the 64bits be with you !

      Posté par  (site web personnel) . Évalué à 10.

      Je pensais que c'était la date où apple changerait de fabriquant de puce pour retourner chez IBM.
    • [^] # Re: May the 64bits be with you !

      Posté par  . Évalué à 1.

      Ca suffit pas de passer au 64b bits. Sous linux, le type time_t est en fait un 'long int'. Donc si de base le 'long int' n'est pas codé sur 64 bits, ou si le type de 'time_t' n'est pas modifié, alors tu as perdu.
      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  . Évalué à 1.

        si de base le 'long int' n'est pas codé sur 64 bits

        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  . Évalué à 7.

          le int s'arrete a 32b, meme sur un proc 64b.
          • [^] # Re: May the 64bits be with you !

            Posté par  . Évalué à 1.

            URL ?
            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  . Évalué à 3.

              En fait pour etre plus precis, la taille des short, int, ... peuvent varier d'un compilateur et d'une plate-forme a un autre. Sur solaris, le int est sur 32b par exemple. Le mieux est de ne pas faire de supposition sur la taille d'un int.
            • [^] # Re: May the 64bits be with you !

              Posté par  . Évalué à 3.

              euh, si j'ai bonne memoire, c'est plutot
              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  . Évalué à -3.

                Ah, enfin quelqu'un qui ne dit pas une ânerie sur le C.

                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  . Évalué à 3.

                  Tu dis absolument n'importe quoi.

                  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  . Évalué à 3.

                    Euh, pour ma culture personnelle et comme il n'est jamais trop tard pour apprendre : c'est quoi la différence entre byte et octet ? (Dire que j'ai réussi à avoir quatre diplômes d'enseignement supérieur en informatique en croyant que ces deux mots désignaient la même chose, à savoir 8 bits. Quelle honte pour moi et pour le système universitaire de ce pays...)
                    • [^] # Re: May the 64bits be with you !

                      Posté par  . Évalué à 4.

                      Question difficile dans le sens général mais ici on parle de la signification de Byte dans le langage C.

                      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  . Évalué à -2.

                    Tu confonds byte et octet

                    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  . Évalué à 2.

          Alors le C99 dit exactement ca (je résume un peu)

          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  . Évalué à 3.

        Non justement le long sous unix correspond a la longeur d'un mot machine (donc en 64bits, 64bits) par contre le long long reste sur bien des plateformes 64bits. Et seul le int reste en 32bits.

        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  . Évalué à 3.

        Sous linux, le type time_t est en fait un 'long int'.
        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  (site web personnel) . Évalué à 3.

      linux/gcc

          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  (site web personnel) . Évalué à 4.

    Il se sera passe 99 ans depuis que tu aura publier ton journal ?
    • [^] # Re: ...

      Posté par  . Évalué à 10.

      Non, c'est le jour où tu comprendras les participes passés.
      • [^] # Re: ...

        Posté par  . Évalué à 7.

        Les participes passer ?
        • [^] # Re: ...

          Posté par  . Évalué à 4.

          nan lé partysip assé ;-)
  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Timestamp

    Posté par  . Évalué à 4.

    Ce sera la fin du timestamp unix :)
  • # C'est un signe !

    Posté par  . Évalué à 5.

    9 juin 2104 à 05:10:42 et 424

    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  . Évalué à 2.

      9 juin 2104 à 05:10:42 et 424
      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  . Évalué à -4.

    Deja foncedé ? ;)
    C'est drole en lisant ton journal j'ai deviné que c'etait toi ;)
  • # 2038

    Posté par  . Évalué à 10.

    En fait la date butoire est le 19 janvier 2038 à 03:14:08 UTC, puisque time_t est signé.
    • [^] # Re: 2038

      Posté par  . Évalué à 3.

      Je me disais bien que tout le monde se trompait ... J'ai du faire un tour sur wikipedia pour être sur : http://en.wikipedia.org/wiki/Unix_epoch(...)
    • [^] # Re: 2038

      Posté par  . Évalué à 2.

      Effectivement, ça me semblait bien curieux aussi, après qu'un de mes prof nous ait que ce bug de fin du calendrier surviendrait en 2038 si le problème n'était pas réglé d'une manière ou d'une autre d'ici là (Unix meurt et est remplacé par autre chose, on corrige l'affaire tant qu'il est encore temps...).
    • [^] # Re: 2038

      Posté par  . Évalué à 6.

      ouf, un an après l'âge de la retraite pour moi :)

      (j'ai eu chaud)
      • [^] # Re: 2038

        Posté par  . Évalué à 8.

        ouf, un an après l'âge de la retraite pour moi :)
        Tu as raison, il faut être optimiste.
      • [^] # Re: 2038

        Posté par  (site web personnel) . Évalué à 2.

        Tu es sûr qu'il ne faudra pas 83 annuités à cette époque? Ce serait une extrapolation raisonnable si la tendance actuelle se poursuit...
  • # erreur de calcul

    Posté par  . Évalué à 10.

    et non, c'est signé, il faut prendre 2^31.
    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  . Évalué à 2.

      ha zut, j'avais pas vu que quelqun avait donné la date juste avant moi... (le temps de la calculer en fait)
      • [^] # Re: erreur de calcul

        Posté par  (site web personnel) . Évalué à 2.

        environ 30 mn pour le calculer :) allez avoue que c'est pas ca ;)
        • [^] # Re: erreur de calcul

          Posté par  . Évalué à 3.

          en 30 min, j'ai lu les reponses, et sans reloadé et j'ai fais le calcul.
          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  . Évalué à 3.

            Mon, je m'excuse auprès du mec que j'ai incendié, il semble en effet que le participe passé est une notion d'un autre âge pour pas mal de monde.... Ouuuhh je me sens vieux tout à coup, et c'est à cause de vous bande de sales geeks.

            Il y avait plus simple pour ton calcul, effectivement : http://en.wikipedia.org/wiki/Unix_time(...) :)
            • [^] # Re: erreur de calcul

              Posté par  . Évalué à 2.

              ouais, j'avais pas pensé a wikipedia.

              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  . Évalué à 2.

                pour info, voici le message que j'ai recu de Kurosu qui ne peut pas le poster par manque d'XP.
                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  (site web personnel) . Évalué à 3.

                  cat: findumonde.c: Aucun fichier ou répertoire de ce type

                  ....

                  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  (site web personnel) . Évalué à 2.

      En tout cas, je comprends mieux désormais pourquoi je reçois de temps en temps des spams datés de Janvier 2038.
  • # Hurd et E17

    Posté par  . Évalué à 3.

    GNU/Hurd L4 et E17 deviendront stable ?
  • # Normalement, ceci est le 42ème commentaire, ca tombe bien...

    Posté par  . Évalué à 2.

    La soluce, en Java du moins :

    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.