Ecriture bien spécifique de code C - Page 5

Folco (./108) :

extern void CommandHelp(char);
extern void CommandAbout(char);
extern void CommandConfig(char);
extern void CommandFlags(char);

J'ai une erreur parce que je ne passe pas de nom à ce paramètre qui ne m'intéresse pas. La solution élégante du C++ qui consiste à ne pas mettre de nom de variable provoque une erreur en C.

Pen^2 (./110) :

public const char* const s1= str+0 ;
public const char* const s2= str+3 ;
public const char* const s3= str+6 ;
public const char* const s4= str+9 ;

Kevin Kofler (./121) :
j'utiliserais #define pour ça, ça donne du code beaucoup plus efficace (pas de pointeurs globaux à reloger).

Kevin Kofler (./121) :
Ce n'est pas ici ton problème, mais au moment de la définition.

Folco (./122) :
C'est bizarre, il y a toujours moyen de faire un lea/pea Str(pc) avec une chaine, pourquoi toujours créer une adresse absolue pour les chaines ?

Ben en fait, je ne peux pas définir les fonctions autrement, parce qu'elles sont appelées en tant que Callback par une lib qui ne connait que le proto "void (*func)(char)".Et quand la lib appelle une fonction, elle n'a aucun moyen de savoir que la fonction n'a pas besoin de ce foutu char ^^

Zerosquare (./125) :
L'en-tête des fichiers BMP est une structure.

Si tu veux avoir une structure qui ne contient aucun padding (donc 100% telle que tu la déclares), il faut utiliser l'attribut "packed" dans la déclaration de ta stucture (c'est spécifique à GCC, il n'existe pas de façon standard de le faire en C).

#pragma pack(1)
struct
{
}
#pragma pack()

	.file	"test.c"
.globl test
	.data
	.align 4
	.type	test, @object
	.size	test, 12
test:
	.long	10
	.byte	20
	.zero	3
	.long	30
.globl test_packed
	.type	test_packed, @object
	.size	test_packed, 9
test_packed:
	.long	10
	.byte	20
	.long	30
.globl test_pragma
	.type	test_pragma, @object
	.size	test_pragma, 9
test_pragma:
	.long	10
	.byte	20
	.long	30
	.ident	"GCC: (Gentoo 4.4.3-r2 p1.2) 4.4.3"
	.section	.note.GNU-stack,"",@progbits

Kevin Kofler (./130) :
Et utiliser une extension VC non portable à la place? Clang accepte aussi __attribute__((packed)) si je ne me trompe; parmi les compilateurs courants, il n'y a que VC qui n'accepte que ses propres extensions. Quant aux compilateurs moins courants, ils ne gèrent pas forcément ni l'une ni l'autre syntaxe, parce que ni l'un ni l'autre n'est du C standard.

Folco (./134) :
Comment ça se passe au niveau des registres ?

Est-ce que la callback attend que les registre a2-a6/d3-d7 aient les même valeurs qu'au moment où P
a appelé la fonction de L ?

Ou est-ce que L
peut modifier ces registres à sa guise avant d'appeler C ? (du moment qu'elle les restaure avant le return vers P évidemment)

En fait, je ne sais pas où chercher ces fonctions, je ne comprends même pas les expressions __attribute__((stkparm)) ou autres au niveau de la syntaxe C...

Est-ce que la callback attend que les registre a2-a6/d3-d7 aient les même valeurs qu'au moment où P a appelé la fonction de L ?

Kevin Kofler (./135) :
(mais généralement la moins efficace)

Kevin Kofler (./135) :
Pour un callback, il est important d'utiliser une convention d'appel standard parce que la fonction L doit connaître la convention d'appel utilisée, c'est pour ça qu'on utilise généralement stkparm pour ça

Folco (./138) :
Y a-t-il des contre-indications ?

Folco (./138) :
Si j'écris une fonction de lib qui a ce proto : void libfunc (void (*callback) (char a = %d0, int b = %d1, short* c = %a0)) (à la syntaxe près évidemment)Le programme P appellera L en fournissant l'adresse d'une callback qui aura le même proto, non ? Alors en quoi serait-ce gênant ?

Zerosquare (./139) :

Folco (./138) :
Y a-t-il des contre-indications ?

Ne pas utiliser en cas de grossesse, d'allaitement, chez les enfants de moins de 6 ans...