informatique et high-tech (les meilleures news) %) - Page 832

(d'ailleurs je viens de vérifier dans le K&R : "Les membres d'une structure se situent à des adresses croissantes dans l'ordre de leurs déclarations.")

ha ouf ca me rassure
bon KK raconte du caca quoi...

bearbecue (./24928) :

mais que l'ordre est spécifié par l'implémentation.

he ben, heureusement qu'en pratique c'est jamais le cas.

Ce n'est pas le compilateur qui réarrange, mais le système d'exploitation! Encore une fois: POSIX spécifie qu'une structure doit avoir les champs x, y et z, mais ne spécifie pas dans quel ordre. Donc le système d'exploitation peut déclarer la structure dans l'ordre y, z, x si ça l'arrange (et évidemment le compilateur respectera).

bearbecue (./24932) :
bon KK raconte du caca quoi...

C'est toi qui n'as pas compris.

je crois que vous parlez pas de la même chose, surtout ^^

Cette histoire n'a jamais implique le compilateur, en fait

./24928 > En théorie, le compilateur JIT de .NET fait ça. Je dis en théorie car c'est documenté, mais j'ai jamais vérifié en pratique, et de toutes façons, cela peut être désactivé avec un attribut. Pour les class, le layout par défaut est auto, et pour les struct le layout par défaut est manuel. Après en .NET ça peut marcher car le JIT est une entité omnisciente (et il y a des règles spéciales pour l'interop), donc c'est pas pareil qu'en C/C++.

Mais du coup c'est en effet pas une question de compilateur.
Par contre pour moi, l'ordre des champs d'une structure, tel que spécifié dans le code, je considère ça comme faisant partie de l'API et non de l'ABI… Je ne serais jamais convaincu par l'argument de Kevin.

habituellement API c'est la compatbilite cote source (et ca inclue tout, meme l'odre dans les structures car ca change certaines choses comme pour les unions, les champs de bits, ou juste meme les initialisation d'une structure pre C99 avec la possibilite de nommer le champs a l'initialisation)

L'ABI elle est la compatibilité au niveau objet

ça rentrerait dans l'ABI si y'avait des contraintes spécifiques à l'architecture, comme par ex. une struct qui décrit les sous-champs d'un registre hardware. Sinon c'est de l'ABI par décision unilatérale des développeurs. Dans le cas contraire ça ressemble plutot à des choix incompatibles d'APIs.

Ca ne pose effectivement pas de problème tant que les structs qui subissent ça sont opaques

what ?

visiblement j'ai tjrs pas compris
(et jsuis pas le seul on dirait)

de quoi tu parles?
de l'ABI des fonctions qu'un OS expose a ses programmes? lol

hmm j'ai écrit *une* petite merdouille

si le hard x86 imposait que int roduce; soit avant char avoual; alors que l'ARM imposait l'inverse, alors ce serait l'ABI.

si c'est un choix fait par les dévs de lunix pour matcher d'autres OS... Hmm bon OK c'est l'API

Je ne savais pas que "penguin" était une insulte. Pen² ne va pas être content

J'ai lance un grep la sur un arbre du kernel il y a vraiment ces mots qui trainent

Documentation/DocBook/kernel-locking.tmpl:1424: If you don't see why, please stay the fuck away from my code.
arch/m68k/include/asm/sun3ints.h:30:/* master list of VME vectors -- don't fuck with this */
arch/mips/sgi-ip22/ip22-setup.c:42: * fucking with the memory controller because it needs to know the
Documentation/DocBook/kernel-hacking.tmpl:1306: * give up. I'm serious, I am going to kick the living shit
arch/sparc/lib/checksum_32.S:327: * give up. I'm serious, I am going to kick the living shit
drivers/net/sunhme.c:930: /* Remember: "Different name, same old buggy as shit hardware." */
arch/alpha/include/asm/uaccess.h:146:/* Those lucky bastards with ev56 and later CPUs can do byte/word moves. */
drivers/atm/horizon.c:2397: // later; the greedy bastards would deserve it


...

excellent

Le coup des "fuck" dans le kernel( ok, code source du kernel) j'en avait entendu parler en 2000/2001 je crois.
Y'avais pas eu l'Australie qui avait poussée une gueulante sur ce point là justement ?

Et en quoi ça les concernerait ?

Parce que tu comprends c'est indécent les gros mots, il faut penser aux mineurs.

C'est de la salubrité publique dans tout son ridicule.

Zerosquare > ça y est, tu commences à indexer stack overflow ?

Pas encore ^^

C'est le dernier site qu'il a a faire

Kevin Kofler (./24921) :

flanker (./24909) :
(accessoirement, VP9 n'est pas plus libre que le H265…)

Si. Et si. Arrête de perpétrer ce mensonge! Le VP9 est couvert par une licence gratuite pour les brevets logiciels compatible avec les logiciels libres (la même que pour le VP8). Le H.265 est couvert par le même type de racket de brevets (licence payante et incompatible avec les licences des logiciels libres) que le H.264.

Le VP9 est couvert par les mêmes brevets, mais Google a payé une licence sur les brevets pour tout le monde et pour *le VP9 uniquement*. Un peu comme la licence du H264 qui est gratuite en lecture (au moins dans les navigateurs).

L'implémentation de référence du VP9 (libvp9) est libre, tout comme l'est x264 (même si ce n'est pas l'implémentation de référence pour le H264/5, c'est du GPL). Mais dès que tu veux modifier un peu le code au niveau de l'algo, tu sors de la licence payée par Google et tu dois te débrouiller avec le consortium MPEG (tout comme H264/5).

La seule différence, c'est que tu peux faire gratuitement une implémentation matérielle de VP9 (alors qu'elle est payante pour H264/5).

(vlan)

(non, flan )

ethernet!

A 10Gbit/s le point Vince?

C'est donc un (double) PGV ! (Point à Grande Vitesse)

Presque une raison d'acheter un mac:

http://www.hopperapp.com/

(quand on compare avec le prix d'IDApro + HexRay... on est presque gagnant )

Licence nomme pour IDApro:

IDApro seul : 869 EUR
HEXX86W x86 Decompiler 1800 EUR
HEXX64W x64 Decompiler 1800 EUR
HEXARMW ARM Decompiler 1800 EUR

Pour avoir a peu pret la meme chose (IDA fait surement encore plus que Hopper mais bon.. )

En même temps, il tourne aussi sous Linux, donc pas besoin de MacOS X pour ça

il n'y as pas (encore) toutes les fonctions sous Linux apriori.


Ya et le dev est français