[F] [mOved] Mon langage est mieux que le tien - Page 37

Le sizeof(int) et l'endianness, oui.

(oups, j'ai raté des posts ce matin )

Je suis content : j'ai trouvé un nouveau bug dans C18, le compilateur C pour les PIC18Fxxx de Microchip. Mais j'aurais été encore plus content si la chasse au bug n'avait pas duré des heures.

Pour les curieux :

- le bug : apparemment, quand machin est déclaré volatile, et qu'on écrit (void)machin; (donc un accès en lecture, mais sans stockage du résultat), C18 ne génère pas d'accès à machin.

- le cast en void n'est pas indispensable, mais ça évite des warnings, et ça montre que la formulation est délibérée.

- ce n'est pas un cas théorique : il y a des raisons valables de faire un accès en lecture sans stocker le résultat, quand la lecture a un effet secondaire, ce qui n'est pas rare pour des registres hardware.

- oui je sais, C18 est obsolète ; mais le code existant a été compilé avec, je veux pas introduire de régressions en changeant de compilo, et je suis pas payé pour ça de toute façon. Sans parler du fait que la licence existante ne doit probablement pas couvrir le nouveau compilateur - parce que oui bien sûr, ce bazar est payant, merci Microchip

- à première vue, XC8 (le nouveau compilateur) n'a pas ce bug.

Zerosquare (./1083) :
Sans parler du fait que la licence existante ne doit probablement pas couvrir le nouveau compilateur - parce que oui bien sûr, ce bazar est payant, merci Microchip

Si c'est ça le problème: SDCC contient un backend PIC16 (en développement) qui gère les PIC18Fxxx. Cela dit, ça ne résout pas ce problème:

oui je sais, C18 est obsolète ; mais le code existant a été compilé avec, je veux pas introduire de régressions en changeant de compilo, et je suis pas payé pour ça de toute façon.

(surtout que les différences entre C18 et SDCC risquent d'être plus grandes qu'entre C18 et XC8), et il y a aussi cet avertissement dans la documentation:

This port is not yet mature and still lacks many features. However, it can work for simple code.

mais je le mentionne quand-même au cas où.

pourquoi tu code en C pour un PIC ?
Vu comment le compilo est moisi, c'est moins risqué de faire de l'asm.

Parce que le code d'origine est en C, et que l'assembleur PIC est moisi.

Un compilateur obsolète et bugué par-dessus un assembleur moisi ? Enjoy

Voilà

Folco (./1087) :
Un compilateur obsolète et bugué par-dessus un assembleur moisi ? Enjoy

Ah pour developpé c'est vraiment le


GT Plus la !

Après les bugs hardware, après les bugs software, ce coup-ci c'est un bug de conception...

Explication : sur les PICs 16Fxxx/18Fxxx, si on ne lit pas les octets reçus sur le port série assez vite, le buffer de réception finit par être rempli et ça active un flag d'erreur. Jusque là, aucun souci.

Tant qu'on ne remet pas à zéro manuellement ce flag, on ne peut plus recevoir d'octets. Et comment on remet à zéro le flag ? Non pas en lisant simplement les octets dans le buffer (comme pour les autres conditions d'erreur), mais en désactivant puis réactivant le récepteur série.

Vous voyez le bug ? Moi je ne l'avais pas vu, et visiblement les mecs de Microchip non plus...

Le problème c'est que si au moment où on désactive/réactive le récepteur, il y a un octet en cours de réception, ce dernier n'est pas simplement perdu, il est corrompu sans avertissement. (À vrai dire, je pense que c'est même pire, et qu'une séquence de plusieurs octets peut être corrompue s'il n'y a pas de pause entre les octets consécutifs, mais je n'ai pas testé).

Conclusion : c'est un bug de conception et il n'y a rien à faire

Han ! Les copieurs ! Ils ont pompés les plans de la pile série de la Lynx !

En attendant, ça fait deux bugs tordus en quelques jours, et pour une fois ils ne sont pas de moi. J'aime déjà pas mes bugs, mais j'aime encore moins ceux des autres.

http://stackoverflow.com/questions/31140101/eclipse-mars-ant-task-references-missing-swt-library
Oui oui, on est bien en 2015. Et le bug avait déjà été reporté dans la release candidate.

Ah mais, je crois que j'avais eu un truc approchant sur le poste d'un collègue
De toute façon je sais pas ce qu'ils foutent, j'ai l'impression que les nouvelles versions n'apportent que très peu de chose, et que l'existant marche subtilement moins bien.
Mais bon, je suis sans doute mauvaise langue.
(merci en tout cas, ça pourra servir)

Zerosquare (./1095) :
Oui oui, on est bien en 2015.

Oui, c'est un scandale qu'en 2015, les utilisateurs utilisent toujours des dossiers avec des espaces dans le nom. (C'est connu depuis des années que ça ne fait que causer des problèmes.)

Mais c'est pourtant vrai que t'as le sens de l'humour, en fait !

(Il n'a quand même pas tord : en pratique c'est une source de problèmes donc ils auraient appelé ce dossier "programmes" dès le début, ça aurait évité des soucis à tout le monde. — je parle en tant qu'utilisateur)

Pen^2 (./1099) :
(Il n'a quand même pas tord : en pratique c'est une source de problèmes donc ils auraient appelé ce dossier "programmes" dès le début, ça aurait évité des soucis à tout le monde. — je parle en tant qu'utilisateur)

bof, savoir prendre en compte correctement les noms de fichiers valides est quand même la moindre des choses et un des trucs les plus faciles à tester

"Program Files" a une espace justement pour que les programmes s'habituent à gérer les noms avec des espaces, et ça date d'il y a 20 ans. Et en pratique, ça ne pose aucun problème aux programmes codés correctement ^^

Progra~1 FTW !!!!

(Depuis ce n'est plus program file, depuis au moins vista de mémoire)

Ça a changé dans la VF depuis Vista en effet, mais apparemment pas dans la VO : https://en.wikipedia.org/wiki/Program_Files

Zerosquare (./1101) :
"Program Files" a une espace justement pour que les programmes s'habituent à gérer les noms avec des espaces

Bref, ils font exprès de faire ch**r le monde.

Seulement les mauvais développeurs

flanker (./1100) :

Pen^2 (./1099) :
(Il n'a quand même pas tord : en pratique c'est une source de problèmes donc ils auraient appelé ce dossier "programmes" dès le début, ça aurait évité des soucis à tout le monde. — je parle en tant qu'utilisateur)

bof, savoir prendre en compte correctement les noms de fichiers valides est quand même la moindre des choses et un des trucs les plus faciles à tester

J'ai bien dit en tant qu'utilisateur : quand un truc est mal codé, on n'y peut rien... :/

Godzil (./1103) :
(Depuis ce n'est plus program file, depuis au moins vista de mémoire)

Bien sûr que si. C'est affiché "programmes" mais c'est un vague alias affiché seulement par l'explorer (même pas un lien symbolique). Son vrai nom est bien toujours "program files".

Dans la version allemande, en revanche, le dossier était appelé "Programme", et si un logiciel avait codé en dur "Program Files" au lieu d'utiliser l'API qui gère la localisation (ça aussi très courant – quelle idée d'utiliser des noms de dossiers traduits!), un dossier "Program Files" était créé à part. Maintenant, c'est devenu un alias pour "Program Files" comme dans la version française. (Je ne sais pas depuis quelle version parce que je n'utilise pas Windows moi-même. J'ai vu ça sur la machine Windows de mon collègue.)

Tu veux dire que c'était traduit en Allemand mais pas en Français ?! Super la cohérence
(ou alors tu fais référence à ton Millenium ?)

Kevin Kofler (./1108) :
quelle idée d'utiliser des noms de dossiers traduits!

Je suis assez d'accord, et ça m'a pas mal surpris que CentOS utilise le nom "bureau" en dur

Kevin Kofler (./1108) :
je n'utilise pas Windows moi-même. J'ai vu ça sur la machine Windows de mon collègue.

Bien sûr, bien sûr
Comme par hasard !

Kevin Kofler (./1105) :

Zerosquare (./1101) :
"Program Files" a une espace justement pour que les programmes s'habituent à gérer les noms avec des espaces

Bref, ils font exprès de faire ch**r le monde.

MS est loin d'être les seuls à forcer la main aux modifs et ils n'ont pas complètement tort parce que tlm sait que tant que le machin est marqué obsolète, personne n'en tient compte. Il faut que l'accès soit coupé pour que les gens passent enfin aux nouvelles API...