Posté par BAud (site web personnel) .
Évalué à 5 (+3/-0).
Dernière modification le 10 décembre 2025 à 10:40.
les soucis envisageables sont plus divers ;-)
notamment, si les champs retenus ne respecte pas ISO 8601 et sont de la forme — par exemple — JJ/MM/AA (oui, année sur 2 chiffres). Déjà que ça gère moyennement le déploiement au Québec ou aux USA qui mixent allègrement MM/JJ/AA et JJ/MM/AA (ah le passage au 12 janvier un 1er décembre suite à màj du serveur NTP /o\), ce pourquoi je préfère AAAA-MM-JJ qui respecte le principe de moindre surprise — ou étonnement ;-) après, on passe au bug Y10K mais ça donne plus de temps :D
bon, après il y aura la gestion de l'évaluation des dates de naissance (ou autres, comme date de début de contrat) nous ayant donné la joie de gérer des choses en 2038, 2039, 2040, 2041, 2042 dès le 1er janvier 2000 lorsque le choix (malencontreux) a été fait de conserver une date sur 2 chiffres pour réduire la saisie de 2 caractères… (ne rigolez pas, c'est encore le cas à pas mal d'endroit…).
même si à la base, 2038 a été identifié comme la fin de EPOCH en 32 bits, cela a révélé pas mal de soucis connexes… bon, après quand ce ne sont que les logs qui sont concernés, c'est un tout petit peu moins grave (sauf pour ceux qui exploitent les logs justement…).
je préfère AAAA-MM-JJ qui respecte le principe de moindre surprise — ou étonnement ;-) après, on passe au bug Y10K mais ça donne plus de temps :D
Au moins, il ne sera pas nécessaire de remplacer la représentation / les données existantes, 2025-12-10 est parfaitement compatible avec le format -MM-JJ qui permettra de représenter des années à 5 chiffres :-)
Bon, de là à ce que notre ère actuelle atteigne les 10 000 ans…
Moui, les semaines de 10 jours, ça fait moins de week-ends, c'est dommage!
Pourquoi pas le calendrier Eastman, dont je découvre un ancêtre dans cette pag: le calendrier Géorgien, un jeu de mot facétieux datant de 1745, qui n'aurait sûrement pas manqué de causer de nombreuses confusions si ça avait marché!
Posté par pas_pey .
Évalué à 2 (+1/-0).
Dernière modification le 10 décembre 2025 à 23:39.
Pas si le matériel est toujours 16 ou 32 bits, il faut rebalayer tout le code, réécrire la gestion des dates partout où il faut, et faire pareil avec toutes les interfaces binaires utilisant ces dates.
Ah oui, si le matos n’a pas évolué… :-) (coucou les distros qui abandonnent les archis 32 bits)
Ceci dit, je pensais surtout au patch du champ de date ; genre passer de short int à long int (dans tous les cas le doubler au moins) et recompiler pour leur architecture cible. Toute façon, recompiler pour un processeur 64 bits sans avoir fait ce changement n’aurait pas réglé le problème. ;-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je n'y connais rien en systèmes embarqués, mais l'article semble un brin pessimiste, non ?
Est-ce si difficile de mettre à jour le logiciel de ces trains ? Serait-ce parce que les processeurs embarqué sont des processeurs 32bits, et qu'il faudrait donc changer l'ordinateur de bord et pas seulement le logiciel ? Est-ce parce qu'il faut des années pour valider une modifications des logiciels embarqués ?
Est-ce parce que les procédures, compilateurs et simulateurs servant à qualifier les logiciels ont été perdus à la première réorganisation des services qui a lieu entre chaque année bissextile ?
Il n'y a probablement pas besoin de changer le matériel. On peut très bien manipuler des entiers 64 bit sur un processeur 32 bit (en C il suffit de déclarer l'entier en "nong int" ou "uint64_t" par exemple).
Mais si ça n'a pas été fait depuis le début et que ça utilise un système qui a traîné des pieds pendant 20 ans pour faire la mise à jour (quelque chose comme la glibc, par exemple), ben il faut mettre à jour tout le système. Grosse montée en version si ça n'a pas été fait au fil de l'eau: probablement que mettre à jour la glibc va aller avec une mise à jour du noyau, du compilateur, bref de tout le système.
Ensuite il faut corriger les erreurs de compilation que le nouveau compilateur a généré.
Jusque là, c'est la partie facile: tu peux faire ça tranquille dans ton bureau. Mais une fois que ça compile, tu peux pas dire "allez zou, on installe ça vendredi après-midi au centre de contrôle (ou sur les rames de métro si c'est embarqué dedans) et c'est parti". Il va falloir tester, probablement d'abord en simulation, mais à un moment sur le vrai matériel. Hors de question de le faire avec des gens dans les rames de métro, et il y a assez peu d'endroits où on peut faire des essais sur des voies qui ne sont pas en service.
Donc ça veut probablement dire fermeture de la ligne de métro pendant quelques jours pour vérifier si tout se passe bien, ou éventuellement essais de nuit si les métros sont fermés la nuit (c'est pas le cas dans toutes les villes) et que le temps de fermeture n'est pas déjà mobilisé par d'autres travaux (entretien des voies, …).
Pour le centre de contrôle tu pourrais peut-être t'en sortir en faisant tourner le nouveau logiciel en parallèle de l'ancien, et vérifier qu'ils font toujours "la même chose", si le truc a été architecturé pour avoir deux contrôleurs en parallèle.
Le problème des systèmes embarqués est assez réduit ici: c'est l'accès au calculateur pour le mettre à jour. Dans le cas d'un train ça peut se faire lors d'une visite régulière au centre de maintenance. Par contre il faut s'assurer de ne pas avoir oublié de le faire sur un train.
On a donc des problèmes de gestion de flotte, des problèmes de capacité à tester en situation réelle, et peut-être de la gestion d'obsolescence logicielle.
Ce sont des grand système ancien, il faut donc retrouver comment la date est gérée et valider que la modification est correct. C'est long, chiant et compliqué.
Tu as ta date en uint32 maintenant c'est un struct. Il faut revoir partout ou c'est utilisé.
Repasser les test unitaires si il existent, et compile encore. En gros, même si le kernel utilise 64 bits, faut-il encore que le code utilisateur l'utilise aussi sur 64 bit et ne passe pas par une couche de compatibilité.
Ce problème était connu en 2010, je ne comprends pas que cela n'a pas été gérer à l'époque.
Par contre, le patch pour Linux 32 bit date de 2020.
Ce problème était connu en 2010, je ne comprends pas que cela n'a pas été gérer à l'époque.
C'est en fait le coeur du problème.
Que le problème soit présent à l'origine, ok, que ce soit difficile / long à corriger et déployer, ok, qu'à la conception un problème aussi connu qui allait concerner des appareils car leur durée de vie est ultra longue ne soit pas identifié et qu'aucune maintenance normale prévue n'a été mise en place depuis c'est un problème.
D'après l'article, Alstom avait bien identifié le problème puisque ils ont interdit la saisie de dates postérieures à 2037. Ils ont été condamnés parce que la justice a décidé que c'était de la dissimulation de vice.
Non, les temps sont longs surtout quand il n'y a pas de budget (car pas de rentrée d'argent liée au développement). Les grosses entreprises prennent un temps fou pour bouger et cela ne prend pas en compte le fait qu'ils font très souvent appel à de la sous-traitance pour développer certains équipements.
S'ils étaient rigoureux, il faudrait modifier la documentation d'entrée (spécifications), la documentation du code et le code, écrire des tests, dérouler les tests. Si les tests sont partiels, il faut prouver que seuls les tests rejoués sont nécessaires. Les tests unitaires sont rapides et ne sont pas en cause ici, c'est les tests fonctionnels qui prennent du temps. Il faut tester fonctionnellement l'équipement seul, puis l'équipement dans une environnement simulé puis l'équipement dans un environnement réel. Tout cela en gardant à l'esprit que :
Sur les 261 logiciels embarqués dans les trains MI09, 223 ont été analysés. Parmi eux, 38 sont confirmés comme porteurs du bug. Mais aucun n’est catégorisé comme « non impacté » avec la mention « approuvé » ou « preuve fournie », souligne le jugement. Une analyse exhaustive reste donc nécessaire.
Et là, on parle d'un type de train. Il faudrait donc faire tous les trains de la flotte dans le temps imparti sachant que :
Le tribunal a donné cinq ans à Alstom pour résoudre le problème, avec un calendrier précis assorti d’astreintes financières.
Pour donner un ordre d'idée de l'échelle de temps, j'ai pu travailler avec le systémier dont il est question dans l'article. Il y avait deux lignes à modifier dans une spécification d'interface (documentation), le contenu des lignes était connu. Temps de mise à jour du document : 2 mois.
Mon pronostric : il y aura des trains à l'arrêt le 19 janvier 2038.
Ah, et je n'ai pas parlé du temps de mise à jour de la flotte avec, pendant un certain temps, des trains en configuration hybride (tous les logiciels ne sont pas à jour). Cela implique beaucoup de choses supplémentaires (tests de compabilité, validations, autorisations…).
Pas certain qu'on ait couvert ce problème quand le projet AGC a démarré vers 2003, chez Bombardier à Crespin (racheté par Alstom des années plus tard).
Il s'agit des machines faisant office d'IHM pour les conducteurs des trains. Matériel Kontron et OS Linux fournis par une boîte belge qui se trouve (trouvait ?) à Wemmel à côté de Bruxelles (le nom m'échappe). Boîte rachetée par Kontron d'ailleurs.
Le problème n'a pas été couvert je pense. Mais je me rappelle vaguement des discussions sur le sujet … Peut-être que le contrat de maintenance s'arrêtait bien avant 2037 ! 34 ans de "vue au loin", c'est beaucoup, même dans le cadre de matériel ferroviaire, nan ?
J'vous ai raconté la fois où un gars de cette boîte belge a modifié un .h que je lui ai fourni, à considérer comme un contrat / une interface à implémenter ? Il a ajouté :
#define true 0
#define false 1
pour inverser un comportement par défaut qui l'embêtait.
Et moi de passer 1/2 journée dans un debugger pour comprendre pourquoi un if( <quelque chose qui revoit true> ) partait vers le else … À devenir fou …
Posté par guppy .
Évalué à 2 (+0/-0).
Dernière modification le 11 décembre 2025 à 16:45.
hum…
J'ai déjà entendu ça plusieurs fois, je supposais que c'était une légende urbaine. Pour que ça pose problème il faudrait écrire if (is_valid == true), mais qui écrit ça alors qu'il suffit d'écrire if (is_valid) ? ou alors quelque chose m'échappe
Le problème se pose si on a quelque chose du genre dans le .h :
// Ze big boolette
#define true 0
#define false 1
// Le contrat dont j'ai demandé l'implémentation
class A
{
public:
...
// quiDependeDe est optionel, et prend une valeur par défaut
// valeur qui embêtait l'implémenteur, d'où ze big boolette
bool faireUnTruc(bool quiDependeDe = true);
...
};
Et dans le .cpp, faireUnTruc(...) retourne true ou false selon le sens du vent et l'âge du capitaine.
C'est à l'endroit où j'exploite le code sous-traité que se pose le problème :
...
if( zeA.faireUnTruc(peuImporteMonBool) )
{
// Code exécuté si true, mais ...
}else{
// Code exécuté si false, mais ...
}
...
faireUnTruc(...) peut renvoyer true, on peut même le debugger pas à pas et observer le return true.
Au retour, le test deviendra if( 0 ) et l'exécution partira dans le else, et quelques neurones partent dans le néant.
La première hypothèse qui vient quand on observe ça, c'est : ah, je suis dans l'une de ces rares situations où l'IDE a loupé des choses, oublié de recompiler certains morceaux de code, etc (réellement vécu, mais c'est une autre histoire). On vire tout le build, et on recompile, on re-debug pas à pas, et on grille à nouveau quelques neurones.
La seconde hypothèse, c'est : wow, le compilo est buggé ???
Et une demi-journée plus tard, on s'aperçoit que deux lignes ont été ajoutées, et que le compilo a encore raison …
Ensuite, on décroche son téléphone, et on gueule …
# 32 bits
Posté par vmagnin (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
?
https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038
[^] # Re: 32 bits
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+3/-2).
La bonne nouvelle c’est que c’est de l’open source et qu’il va suffire de (peut-être patcher et certainement) recompiler en 64 bits puis redéployer ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: 32 bits
Posté par BAud (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 10 décembre 2025 à 10:40.
les soucis envisageables sont plus divers ;-)
notamment, si les champs retenus ne respecte pas ISO 8601 et sont de la forme — par exemple — JJ/MM/AA (oui, année sur 2 chiffres). Déjà que ça gère moyennement le déploiement au Québec ou aux USA qui mixent allègrement MM/JJ/AA et JJ/MM/AA (ah le passage au 12 janvier un 1er décembre suite à màj du serveur NTP /o\), ce pourquoi je préfère AAAA-MM-JJ qui respecte le principe de moindre surprise — ou étonnement ;-) après, on passe au bug Y10K mais ça donne plus de temps :D
bon, après il y aura la gestion de l'évaluation des dates de naissance (ou autres, comme date de début de contrat) nous ayant donné la joie de gérer des choses en 2038, 2039, 2040, 2041, 2042 dès le 1er janvier 2000 lorsque le choix (malencontreux) a été fait de conserver une date sur 2 chiffres pour réduire la saisie de 2 caractères… (ne rigolez pas, c'est encore le cas à pas mal d'endroit…).
même si à la base, 2038 a été identifié comme la fin de EPOCH en 32 bits, cela a révélé pas mal de soucis connexes… bon, après quand ce ne sont que les logs qui sont concernés, c'est un tout petit peu moins grave (sauf pour ceux qui exploitent les logs justement…).
[^] # Re: 32 bits
Posté par raphj (site web personnel) . Évalué à 3 (+1/-0).
Au moins, il ne sera pas nécessaire de remplacer la représentation / les données existantes, 2025-12-10 est parfaitement compatible avec le format -MM-JJ qui permettra de représenter des années à 5 chiffres :-)
Bon, de là à ce que notre ère actuelle atteigne les 10 000 ans…
[^] # Re: 32 bits
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
…et que l’on conserve le même calendrier irrégulier
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: 32 bits
Posté par raphj (site web personnel) . Évalué à 5 (+3/-0).
Un révolutionnaire, je constate !
[^] # Re: 32 bits
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Moui, les semaines de 10 jours, ça fait moins de week-ends, c'est dommage!
Pourquoi pas le calendrier Eastman, dont je découvre un ancêtre dans cette pag: le calendrier Géorgien, un jeu de mot facétieux datant de 1745, qui n'aurait sûrement pas manqué de causer de nombreuses confusions si ça avait marché!
[^] # Re: 32 bits
Posté par pas_pey . Évalué à 2 (+1/-0). Dernière modification le 10 décembre 2025 à 23:39.
Pas si le matériel est toujours 16 ou 32 bits, il faut rebalayer tout le code, réécrire la gestion des dates partout où il faut, et faire pareil avec toutes les interfaces binaires utilisant ces dates.
[^] # Re: 32 bits
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Ah oui, si le matos n’a pas évolué… :-) (coucou les distros qui abandonnent les archis 32 bits)
Ceci dit, je pensais surtout au patch du champ de date ; genre passer de short int à long int (dans tous les cas le doubler au moins) et recompiler pour leur architecture cible. Toute façon, recompiler pour un processeur 64 bits sans avoir fait ce changement n’aurait pas réglé le problème. ;-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Difficulté de la mise à jour
Posté par Dareg . Évalué à 5 (+4/-0).
Je n'y connais rien en systèmes embarqués, mais l'article semble un brin pessimiste, non ?
Est-ce si difficile de mettre à jour le logiciel de ces trains ? Serait-ce parce que les processeurs embarqué sont des processeurs 32bits, et qu'il faudrait donc changer l'ordinateur de bord et pas seulement le logiciel ? Est-ce parce qu'il faut des années pour valider une modifications des logiciels embarqués ?
[^] # Re: Difficulté de la mise à jour
Posté par Pol' uX (site web personnel) . Évalué à 9 (+8/-1).
Est-ce parce que les procédures, compilateurs et simulateurs servant à qualifier les logiciels ont été perdus à la première réorganisation des services qui a lieu entre chaque année bissextile ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Difficulté de la mise à jour
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+14/-0).
Il n'y a probablement pas besoin de changer le matériel. On peut très bien manipuler des entiers 64 bit sur un processeur 32 bit (en C il suffit de déclarer l'entier en "nong int" ou "uint64_t" par exemple).
Mais si ça n'a pas été fait depuis le début et que ça utilise un système qui a traîné des pieds pendant 20 ans pour faire la mise à jour (quelque chose comme la glibc, par exemple), ben il faut mettre à jour tout le système. Grosse montée en version si ça n'a pas été fait au fil de l'eau: probablement que mettre à jour la glibc va aller avec une mise à jour du noyau, du compilateur, bref de tout le système.
Ensuite il faut corriger les erreurs de compilation que le nouveau compilateur a généré.
Jusque là, c'est la partie facile: tu peux faire ça tranquille dans ton bureau. Mais une fois que ça compile, tu peux pas dire "allez zou, on installe ça vendredi après-midi au centre de contrôle (ou sur les rames de métro si c'est embarqué dedans) et c'est parti". Il va falloir tester, probablement d'abord en simulation, mais à un moment sur le vrai matériel. Hors de question de le faire avec des gens dans les rames de métro, et il y a assez peu d'endroits où on peut faire des essais sur des voies qui ne sont pas en service.
Donc ça veut probablement dire fermeture de la ligne de métro pendant quelques jours pour vérifier si tout se passe bien, ou éventuellement essais de nuit si les métros sont fermés la nuit (c'est pas le cas dans toutes les villes) et que le temps de fermeture n'est pas déjà mobilisé par d'autres travaux (entretien des voies, …).
Pour le centre de contrôle tu pourrais peut-être t'en sortir en faisant tourner le nouveau logiciel en parallèle de l'ancien, et vérifier qu'ils font toujours "la même chose", si le truc a été architecturé pour avoir deux contrôleurs en parallèle.
Le problème des systèmes embarqués est assez réduit ici: c'est l'accès au calculateur pour le mettre à jour. Dans le cas d'un train ça peut se faire lors d'une visite régulière au centre de maintenance. Par contre il faut s'assurer de ne pas avoir oublié de le faire sur un train.
On a donc des problèmes de gestion de flotte, des problèmes de capacité à tester en situation réelle, et peut-être de la gestion d'obsolescence logicielle.
[^] # Re: Difficulté de la mise à jour
Posté par Nicolas Boulay (site web personnel) . Évalué à 7 (+4/-0). Dernière modification le 10 décembre 2025 à 09:12.
Ce sont des grand système ancien, il faut donc retrouver comment la date est gérée et valider que la modification est correct. C'est long, chiant et compliqué.
Tu as ta date en uint32 maintenant c'est un struct. Il faut revoir partout ou c'est utilisé.
Repasser les test unitaires si il existent, et compile encore. En gros, même si le kernel utilise 64 bits, faut-il encore que le code utilisateur l'utilise aussi sur 64 bit et ne passe pas par une couche de compatibilité.
Ce problème était connu en 2010, je ne comprends pas que cela n'a pas été gérer à l'époque.
Par contre, le patch pour Linux 32 bit date de 2020.
"La première sécurité est la liberté"
[^] # Re: Difficulté de la mise à jour
Posté par Renault (site web personnel) . Évalué à 7 (+4/-0).
C'est en fait le coeur du problème.
Que le problème soit présent à l'origine, ok, que ce soit difficile / long à corriger et déployer, ok, qu'à la conception un problème aussi connu qui allait concerner des appareils car leur durée de vie est ultra longue ne soit pas identifié et qu'aucune maintenance normale prévue n'a été mise en place depuis c'est un problème.
[^] # Re: Difficulté de la mise à jour
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+7/-0).
D'après l'article, Alstom avait bien identifié le problème puisque ils ont interdit la saisie de dates postérieures à 2037. Ils ont été condamnés parce que la justice a décidé que c'était de la dissimulation de vice.
[^] # Re: Difficulté de la mise à jour
Posté par nico4nicolas . Évalué à 3 (+1/-0).
Non, les temps sont longs surtout quand il n'y a pas de budget (car pas de rentrée d'argent liée au développement). Les grosses entreprises prennent un temps fou pour bouger et cela ne prend pas en compte le fait qu'ils font très souvent appel à de la sous-traitance pour développer certains équipements.
S'ils étaient rigoureux, il faudrait modifier la documentation d'entrée (spécifications), la documentation du code et le code, écrire des tests, dérouler les tests. Si les tests sont partiels, il faut prouver que seuls les tests rejoués sont nécessaires. Les tests unitaires sont rapides et ne sont pas en cause ici, c'est les tests fonctionnels qui prennent du temps. Il faut tester fonctionnellement l'équipement seul, puis l'équipement dans une environnement simulé puis l'équipement dans un environnement réel. Tout cela en gardant à l'esprit que :
Et là, on parle d'un type de train. Il faudrait donc faire tous les trains de la flotte dans le temps imparti sachant que :
Pour donner un ordre d'idée de l'échelle de temps, j'ai pu travailler avec le systémier dont il est question dans l'article. Il y avait deux lignes à modifier dans une spécification d'interface (documentation), le contenu des lignes était connu. Temps de mise à jour du document : 2 mois.
Mon pronostric : il y aura des trains à l'arrêt le 19 janvier 2038.
Ah, et je n'ai pas parlé du temps de mise à jour de la flotte avec, pendant un certain temps, des trains en configuration hybride (tous les logiciels ne sont pas à jour). Cela implique beaucoup de choses supplémentaires (tests de compabilité, validations, autorisations…).
# 2003 / AGC / Bombardier / Alstom
Posté par pseudonymous . Évalué à 10 (+12/-0).
Pas certain qu'on ait couvert ce problème quand le projet AGC a démarré vers 2003, chez Bombardier à Crespin (racheté par Alstom des années plus tard).
Il s'agit des machines faisant office d'IHM pour les conducteurs des trains. Matériel Kontron et OS Linux fournis par une boîte belge qui se trouve (trouvait ?) à Wemmel à côté de Bruxelles (le nom m'échappe). Boîte rachetée par Kontron d'ailleurs.
Le problème n'a pas été couvert je pense. Mais je me rappelle vaguement des discussions sur le sujet … Peut-être que le contrat de maintenance s'arrêtait bien avant 2037 ! 34 ans de "vue au loin", c'est beaucoup, même dans le cadre de matériel ferroviaire, nan ?
J'vous ai raconté la fois où un gars de cette boîte belge a modifié un .h que je lui ai fourni, à considérer comme un contrat / une interface à implémenter ? Il a ajouté :
pour inverser un comportement par défaut qui l'embêtait.
Et moi de passer 1/2 journée dans un debugger pour comprendre pourquoi un
if( <quelque chose qui revoit true> )partait vers leelse… À devenir fou …[^] # Re: 2003 / AGC / Bombardier / Alstom
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Effet de bord …débordant globalement
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: 2003 / AGC / Bombardier / Alstom
Posté par guppy . Évalué à 2 (+0/-0). Dernière modification le 11 décembre 2025 à 16:45.
hum…
J'ai déjà entendu ça plusieurs fois, je supposais que c'était une légende urbaine. Pour que ça pose problème il faudrait écrire
if (is_valid == true), mais qui écrit ça alors qu'il suffit d'écrireif (is_valid)? ou alors quelque chose m'échappe[^] # Re: 2003 / AGC / Bombardier / Alstom
Posté par pseudonymous . Évalué à 3 (+3/-0).
Le problème se pose si on a quelque chose du genre dans le .h :
Et dans le .cpp,
faireUnTruc(...)retournetrueoufalseselon le sens du vent et l'âge du capitaine.C'est à l'endroit où j'exploite le code sous-traité que se pose le problème :
faireUnTruc(...)peut renvoyertrue, on peut même le debugger pas à pas et observer lereturn true.Au retour, le test deviendra
if( 0 )et l'exécution partira dans leelse, et quelques neurones partent dans le néant.La première hypothèse qui vient quand on observe ça, c'est : ah, je suis dans l'une de ces rares situations où l'IDE a loupé des choses, oublié de recompiler certains morceaux de code, etc (réellement vécu, mais c'est une autre histoire). On vire tout le build, et on recompile, on re-debug pas à pas, et on grille à nouveau quelques neurones.
La seconde hypothèse, c'est : wow, le compilo est buggé ???
Et une demi-journée plus tard, on s'aperçoit que deux lignes ont été ajoutées, et que le compilo a encore raison …
Ensuite, on décroche son téléphone, et on gueule …
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.