WhatsApp, Snapchat, Telegram, HipChat, Slack... les emails bientôt obsolètes ? - Page 6

Clair, et même d'autre complications: l'autre jour chez un sous-contractant, on a identifié des problèmes bizarres qu'ils avaient en activant l'EDAC (un mécanisme de protection de la mémoire). Chaque donnée écrite est complémentée d'un mot de contrôle par le microcontrôleur, et ils ne comprenaient pas pourquoi parfois ils avaient des erreur d'EDAC alors qu'ils ne faisaient jamais de lecture avant écriture (comme il se doit).
Sauf que lorsqu'ils faisaient des accès sur 8 bits, le processeur fait une lecture 32 bits, en modifie 8, et réécrit les 32, d'où le plantage à cause des 24 bits non initialisés

edit: cross

ah, joli

Ouais

(et sinon pitié, arrêtez avec les char, les int et les long. Y'a (u)intxx_t depuis le C99, et ses variantes s'il vous faut une taille minimum plutôt qu'une taille exacte, etc.)

Zeph (./146) :
./130 : sans déconner ? Chez moi Slack donne ça, et je n'ai qu'une instance ouverte (quoi que signifient les 6 processus qui apparaissent) :



Je ne sais pas par quel miracle ça passe de 166mo chez eux à 1go chez moi, mais à côté de ça Pidgin prend 22mo...

C'est peut-être la consommation mémoire quand tu n'as aucune conversation et que ta liste de contacts est vide ? ^^

(Ah tiens, c'est dans la norme ? C'est une bonne chose, je pensais que c'était des fioritures des compilateurs — de toute façon un char est un caractère, sinon c'est un byte, comme dans tous les vrais langages d'hommes )

stdio.h
stdint.h

ca commence pareil

Comme le dit zero, char on le garde uniquement pour les chaines, void * pour des pointeur generiques pour tout le reste quand on a besoin d'une taille garantie on utilise les (u)intXX_t, et si on veux une taille minimum mais laisser le compilateur faire son boulot d'optimisation on utilise (u)int_leastXX_t

Et si on veux faire d'un pointeur un handle, on utilise uintptr_t (intptr_t n'as pas de sens)

Tous les autres types sont a proscrire.

Zeph (./146) :
mais à côté de ça Pidgin prend 22mo...

Tiens, tu utilises du GTK+ maintenant? N'était-ce pas toi qui refusais d'utiliser TiEmu à cause de GTK+?

squalyl (./155) :
stdio.h
stdint.h

ca commence pareil

(utilisez inttypes.h au lieu de stdint.h, ça supporte plus de trucs.)

Ca permet surtout de faire des choses soupayrMoche™© :

printf("myvar=%" PRIu16 "\n", myvar);

ah c'est inttypes qui supporte cette syntaxe?

ah c'est très très standard en plus!

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html

Pen^2 (./154) :
(Ah tiens, c'est dans la norme ? C'est une bonne chose, je pensais que c'était des fioritures des compilateurs — de toute façon un char est un caractère, sinon c'est un byte, comme dans tous les vrais langages d'hommes )

Oui, stdint.h est dans la norme depuis 18 années (!), le problème est qu'il y en a toujours qui en sont restés à la norme d'il y a 27-28 années.

Godzil (./160) :
Ca permet surtout de faire des choses soupayrMoche™© :

printf("myvar=%" PRIu16 "\n", myvar);

Je suis d'accord que la syntaxe est moche, mais c'est toujours mieux que de devoir caster en int explicitement les arguments de printf.

L'autre jour je suis tombé sur des prototypes de fonctions K&R

Zero: tu peux aussi utiliser les bon type dans ton printf

%u pour unsigned (16b) %lu pour un unsigned long (32b) etc..

%d et %f ne sont pas les seul cibles valides xD

Sauf que justement, si tu utilises ça avec des arguments (u)intxx_t, le résultat n'est pas portable. Et puis autant se débarrasser complètement des int.

godzil: oui les uint64_t font chier parce que leur type change selon la plate forme

linux 32 et pitet windows: unsigned long long int
linux 64: unsigned long int suffit

c'est bien relou, un truc comme inttypes aide dans ce cas.

Oui mais c'est super moche

pas sur. tu recommandes quoi sinon?

Kevin Kofler (./158) :
Tiens, tu utilises du GTK+ maintenant? N'était-ce pas toi qui refusais d'utiliser TiEmu à cause de GTK+?

Ben si mais j'ai du baisser mes critères, je n'ai trouvé aucun meilleur client IRC sous Windows donc même malgré sa dépendance à GTK+ Pidgin reste la meilleure alternative pour moi.

Ajouter des tag propres dans printf plutôt que de jouer avec ces monstruosités, déjà que les %@ dans une chêne c'est moche, la ça casse complètement le truc, autant soit déprécier printf en faveur de quelque chose de plus propre (et qui pourrais mettre de faire comme en python, avec format, l'ordre des paramètres dans la chaîne n'est pas dépendant de l'ordre des paramètres d'appel de la fonction).

Ou alors simplement ajouter des %quelque chose qui de demande pas de casser la chaine comme ca

%u8 %u16 %u32 %s8 %s16 %s32

Comme ca on peux garder garder ce qui est avant la lettre pour spécifier le formatage, et le nombre après u pour unsigned, s pour signed donne la taille de la bestiole.

Ça serait certainement mieux oui, mais inttypes.h a l'avantage de marcher avec les compilos existants sans demander de modifs - et ça marche même avec les compilos pré-C99 pour peu qu'on prenne un peu de temps pour créer soi-même un inttypes.h adapté.

Et puis soyons honnêtes : en 2017, on n'utilise pas le C parce que c'est le meilleur langage qui existe, mais pour des raisons pragmatiques

Et le fait que c'est le meilleur langage qui existe est une raison pragmatique

Tout a fait d'accord

Ah bon, ce n'est pas J2ME ?

ask Hell plutot.

https://arstechnica.com/tech-policy/2017/04/secure-messaging-app-confide-sued-over-alleged-security-flaws/

Visiblement, le type ne s'est pas dit que même si l'appli avait eu une protection anti-screenshot imparable, il suffit de prendre une photo de l'écran.

Et que je sache il n'est pas possible d'empecher un screenshot.

Oui ce n'est pas possible, en tout cas simplement:

https://forums.developer.apple.com/thread/61124

J'aimerais bien savoir comment l'app fait pour "empecher les screenshot" comme le dit Ars

Peut-être de manière indirecte, comme dit dans le 2ème commentaire du lien que tu as posté ? Y'a pas besoin que ce soit imparable, juste suffisant pour arrêter un utilisateur moyen.