C'est pas bien grave ça, il y a toujours quelqu'un pour te dire que t'es nul.
Ils ne disaient pas (pour autant que je sache) qu'elles étaient nulles, mais ils étaient moins encourageants pour qu'elles s'orientent vers des études scientifiques que des gars du même niveau. Nuance. Mais à part ça, t'inquiète pas, il y a des filles qui n'écoutent pas et font ce qu'elles veulent quand même, et qui finissent major de promotion ;)
Ceci dit, l'inertie culturelle et sociale est quand même assez forte... Ca dépend de l'environnement familial, des profs qu'on a, d'amis... A part ça, presque tous mes profs de math au collège et au lycée étaient des femmes, et un peu moins en physique. Comme quoi...
D'ailleurs, il n'y a pas besoin de faire des études sociologiques poussées pour s'en rendre compte, il suffit de causer avec des amis/profs/collègues sur leurs orientations profressionnelles. Je connais plusieurs femmes qui, au lycée, voulaient faire des études scientifiques, mais leurs profs n'étaient pas forcément super enthousiastes ou encourageants - alors que des gars avec à peu près les mêmes notes étaient mieux vus.
Sinon, dans ma promo, moins de 10 % de fille dans l'option info de mon école... (mais d'autres options remplissent largement, allez savoir pourquoi)
En fait, le truc c'est que les geek, quand ils sont en groupe, se sentent forts et ne sont pas du tout timides ou mijorés et aiment bien se raconter des blagues sur des histoires de PC et des histoires de cul.
Hein ? Bah merde alors, je suis geek et les blagues de cul ne me font pas rire (enfin, les lourdes, quoi. Quand Desproges fait de l'humour sur la sexualité, oui ça me fait rire. Mais bon, Desprogres n'était pas un geek.).
D'ailleurs, je ne vois pas pourquoi un groupe qui se forme autour d'une curiosité technique/attrait du libre/autre intérêt qu'on peut trouver dans l'informatique tendrait automatiquement à faire des blagues salaces... Il y a sûrement des choses qui m'échappent, mais il me semble qu'on peut être geek et de bon goût(TM). Enfin, j'essaye (et je pense ne pas avoir de réputation de gros lourd auprès de mes amis/collègues).
En plus, j'oubliais le principal, tu ne répondais pas vraiment à sa question: Kriss demandait comment traiter ligne par ligne, et tu donnes un exemple caractère par caractère ! fgets est la fonction ISO qui permet de faire ça, mais son usage n'est pas trivial: cf. https://linuxfr.org/comments/713347.html#713347 pour un de mes posts précédents à ce sujet.
Bah si, il y en a !
#include "stdio.h"
Normalement, c'est avec les < et >, mais il est vrai que ça marche aussi avec (à condition que tu n'aies pas placé un autre fichier stdio.h dans ton chemin d'inclusion).
//Ouvre le fichier passé en paramètre 1
FILE *fd = fopen(argv[1], "r");
//Caractère lu
char c;
//Lis chaque caractère du fichier
while ((c = getc(fd)) != EOF)
Deux erreurs: tu ne vérifies pas le résultat de fopen (peut-être que le fichier n'a pas été ouvert ?), et tu utilises une variable de type char pour stocker le résultat de getc. http://c-faq.com/stdio/getcharc.html
This is a simple, permissive non-copyleft free software license with practical problems like those of the original BSD license, including incompatibility with the GNU GPL.
Mais la notion de "compatibilité" dépend de ce que tu veux faire:
- si c'est livrer une application qui contient un module sous licence Apache, et un sous GPL, non modifiés, alors ça peut être OK suivant le niveau d'intrication entre les différents composants (notion de "derived work", si je me souviens bien du phrasé de la GPL que je n'ai pas sous les yeux).
- Si c'est pour modifier les sources d'un module Apache et d'un module GPL pour les mélanger, alors je pense que l'incompatibilité survient.
Mais, comme toujours dans ces histoires, pour déterminer s'il y a conflit ou non, il faut être très prudent quant au niveau de dépendance entre les composants, aux modifications que tu leur portes... A part l'extrait de la page de la FSF que j'ai cité, ceci n'est que mon avis perso...
Peut-être tenter la compilation avec les options "-ansi -std=c99" ? Tiens, d'ailleurs, ces deux options qui traînent dans mes quelques Makefile faits main sont-elles orthogonales ? Je les mets par habitude, il faudrait que je lise la page de manuel...
Ces deux options sont incompatibles. -ansi est un raccourci pour -std=c89, i.e. pour indiquer à gcc de suivre la norme C ANSI 89, qui est identique (à la mise en page près) à C ISO 90 (sans l'amendement 1). -std=c99 indique à gcc de suivre la norme C ISO 99 (plus TC1 et TC2).
Tu ne dois donc en garder qu'une sur les deux options. Au passage, je n'ai pas trouvé si la doc indiquait quel norme ou standard gcc suit si on en spécifie deux (cf. http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/C-Dialect-Option(...) ). On pourrait faire le test avec un programme invoquant un "silent change", mais je pense que le plus simple est de faire attention à avoir des makefile propres dès le départ, plutôt que de se poser ce genre de questions...
<mode="pinaillage mais pas tant que ça">Il s'agit d'un standard dans un des sens anglais du terme, qui est traduit par norme en français. La langue anglais n'a pas de moyen de différencier directement standard et norme, sinon par des expressions plus longues commes "standard de facto".
Mais j'admets que l'erreur de traduction est très répandue... Ce qui ne l'excuse pas.</mode>
Ceci dit, pour en revenir au sujet de la discussion, les commentaire d'une ligne "à la C++" commencés par // ont été effectivement introduits dans la norme C dans la version C99, étant donné que nombre d'implémentations le proposaient déjà comme extension.
Par ailleurs, gcc propose aussi le mode -std=gnu99 pour disposer de la norme C ISO 99 + les extensions GNU (le "standard" par défaut de GCC étant gnu89, et ce probablement jusqu'à ce que toute la norme C99 soit correctement implémentée, ce qui risque de prendre encore du temps. Patience, cette norme n'est sortie qu'il y a 7 ans, après tout...)
sudo permet de lancer un programme sous un autre compte que celui de l'utilisateur courant. Cette commande (à ma connaissance, qui est partielle) ne gère pas d'elle-même le problème de la déconnexion. nohup permet de lancer un programe sous le compte de l'utilisateur, et qui continue de tourner après la déconnexion de l'utilisateur.
Quand l'utilisateur quitte son shell, le système envoie le signal SIGHUP à tous les programmes lancés depuis ce shell (ou plus précisément les processus "fils" du shell), ce qui a pour effet de terminer ces programmes. nohup permet de lancer un programme de telle manière que le signal SIGHUP ne le tue pas.
Note qu'il existe aussi screen qui permer de garder des sessions shell ouvertes même si on se déconnecte, pour se reconnecter ensuite et reprendre la session, mais celà est peut-être plus élaboré que ce dont tu as besoin.
video_out_xxmc.c:59: error: 'XINE_XVMC_ACCEL_VLD' undeclared here (not in a function)
video_out_xxmc.c:61: error: 'XINE_XVMC_ACCEL_IDCT' undeclared here (not in a function)
video_out_xxmc.c:62: error: 'XINE_XVMC_ACCEL_MOCOMP' undeclared here (not in a function)
Les macros XINE_XVMC_ACCEL_VLD et autres doivent être définies dans des fichiers introuvables à la compilation... Peut-être manque-t-il des ficheirs d'en-têtes, ou un autre package, pour pouvoir compiler le tout ?
Posté par alf .
En réponse au message scanf didju..
Évalué à 1.
je crois qu'un printf("\n"); faisait l'affaire
printf("\n") ne fait que vider le buffer du flux stdout (une implémentation pourrait profiter de ce moment pour vider les tampons d'autres flux sortants en même temps, pour optimiser les accès I/O, mais c'est aléatoire). Le flux stdin ne peut être "vidé" ainsi, comme je l'ai dit plus bas.
Posté par alf .
En réponse au message scanf didju..
Évalué à 1.
Pour palier a ce problème sous windows un fflush(stdin) suffisait et bien ici que neni. Cela ne va pas.
Appliquer fflush à un flux entrant comme stdin résulte en un comportement indéfini. Windows peut aussi bien faire dans ce cas ce que tu voudrais qu'il fasse, comme une autre implémentation (ou le même Windows un autre jour) peut ne rien faire... cf. http://c-faq.com/stdio/stdinflush.html et http://c-faq.com/stdio/stdinflush2.html
Posté par alf .
En réponse au message scanf didju..
Évalué à 0.
Je ne sais pas si c'est la meilleure façon de faire ...
Si. Enfin, presque: la meilleure façon de le faire, c'est d'utiliser une fonction spécifique qui encapsule le fgets car, comme je l'ai dit ici ( http://linuxfr.org/comments/713347.html#713347 ), son utilisation n'est pas triviale. http://cbfalconer.home.att.net/download/index.htm propose une fonction fggets simple d'utilisation qui prend une ligne entière d'un flux pour la mettre dans une zone allouée avec un *alloc.
Pour traiter la chaîne "brute" ainsi récupérée, il faut ensuite utiliser des fonctions comme sscanf ou strto*, suivant les besoins, en vérifiant les conditions d'erreur.
En effet... Ce qui m'a trompé, c'est "The core of the Single UNIX Specification, Version 3 is also IEEE Std 1003.1". C'est le "noyau" de la SUS qui est POSIX, et pas toute la SUS... Mea culpa. Je ferai plus attention la prochaine fois que je donnerai le lien.
On peut avoir deux spécifications techniquement identiques sans que ça soit des copies (ce qui violerait le copyright).
Moui. Dans l'hypothèse de deux groupes indépendants qui auraient la même idée et la publieraient séparément, je suis d'accord. Mais dans le cas SUS/POSIX, qu'elles soient identiques (mis à part les extensions SUS) sans être copies l'une de l'autre... ça me semblerait une grosse coïncidence. Mais peut-être s'agit-il d'un cas semblable au Working Group du langage C au sein de l'ISO, qui possède les droits sur les drafts de la norme C, alors que l'ISO possède les droits sur les normes, ce qui fait que le WG a pu décider de publier les drafts en accès libre sur leur site.
Ne connaissant rien à OCaml (j'ai bien fait du Caml en prépa, mais c'était déjà il y a un moment, et on n'a pas utilisé le son), je ne peux tenter une réponse qu'à la deuxième question: les fora de linuxfr sont (je pense) créés suivant la demande.. Si beaucoup de question sur OCaml venaient de manière réguilère sur Programmation.autre , je pense que la création d'un forum dédié serait approuvée, sinon faut voir. Le forum Programmation.SQL n'a pas un traffic terrible, donc on peut penser qu'on pourrait créer des fora avec la même fréquentation; mais c'est aux admins de décider (enfin, c'est l'impression que j'en ai, je ne suis pas dans l'équipe Linuxfr).
Si tu n'utilises pas les arguments, un void suffit.
f_in = fopen("in", "r");
Pense à vérifier si fopen a bien marché.
file = strdup("out1");
strdup est une extension GNU (je n'ai rien contre les extensions, c'est juste pour signaler qu'il y pourra y avoir des problèmes de portabilité par la suite).
Et vérifie aussi que la fonction a bien marché, sinon le fopen avec une valeur nulle causera un comportement indéfini.
Tu as oublié de comparer le début de buf avec "DEBUT". Et si une ligne du fichier d'entrée est plus longue que BUFSIZ, tu tronques les lignes...
De plus, si la ligne comprend un expace au plein milieu, ton fscanf ne prendra pas la fin de la ligne.
Tu pourrais rajouter le fclose dans ce block, pour éviter d'avoir un nombre indéterminé de fichiers ouverts en même temps (ça évite de planter si on ouvre trop de fichiers...).
Pour ton malloc: sizeof(char) vaut 1 par définition, donc tu peux simplifier l'écriture en
file = malloc(strlen("out") + cpt);
Pour la première étape, on a cpt == 1, donc tu réserves 4 caractères (car strlen("out") == 3). Or, tu places ensuite la chaîne "out", puis la chaîne de caractères représentant cpt+1 en décimal, c'est-à-dire "2". Tu aboutis donc à 5 caractères: 'o', 'u', 't', '2', '\0'.
Tu as donc effectué un débordement de tampon, et provoqué un comportement indéfini.
Mais, pour cpt > 1, ta formule marche efefctivement. Note quand même que faire le + cpt réserve plus de caractères qu'il n'en faut. Peut-être as-tu fait exprès, sachant que cpt caractères sont toujours suffisants pour afficher le nombre cpt+1 (si cpt > 1...), mais il faudrait au moins le metre en commentaire.
La ligne
file = malloc(strlen("out") + cpt + 1);
est donc suffisante; mais il ne faut pas oublier qu'on prend plus de place mémoire que nécessaire...
Par flemme, on va dire que la réécriture de ce code pour ne pas prendre plus de mémoire que nécessaire est laissé en exercice au lecteur ;)
Par ailleurs, il serait bon de vérifier que malloc n'a pas échoué, à moins de tenir à tester les comportements indéfinis de ton implémentation ;)
Et il faudrait aussi noter que le "32" pour le buffer du sprintf est purement arbitraire (très largement suffisant, mais juste pour noter en commentaire dans le code).
POSIX is a registered trademark of the IEEE.
[...]
Although originated to refer to the original IEEE Std 1003.1-1988, the name POSIX more correctly refers to a family of related standards: IEEE Std 1003.n (where n is a number) and the parts of ISO/IEC 9945. The term POSIX was originally used as a synonym for IEEE Std 1003.1-1988. A preferred term for that standard, POSIX.1, emerged. This maintained the advantages of readability of the symbol ``POSIX'' without being ambiguous with the POSIX family of standards.
[...]
Q3. What is the latest version of POSIX.1?
The 2004 edition of the 1003.1 standard was published on April 30th 2004, and updates the 2001 edition of the standard to include Technical Corrigendum 1 (TC1) and Technical Corrigendum 2 (TC2). The 2004 Edition is formally known as:
IEEE Std 1003.1, 2004 Edition
The Open Group Technical Standard Base Specifications, Issue 6
Includes IEEE Std 1003.1-2001, IEEE Std 1003.1-2001/Cor 1-2002 and IEEE Std 1003.1-2001/Cor 2-2004
and its worth noting that within the text the standard is still referred to as IEEE Std 1003.1-2001.
The core of the Single UNIX Specification, Version 3 is also IEEE Std 1003.1. The latest 2004 edition incorporates IEEE Std 1003.1-2001 and two technical corrigendum. IEEE Std 1003.1-2001 is a major revision and incorporates IEEE Std 1003.1-1990 (POSIX.1) and its subsequent amendments, and IEEE Std 1003.2-1992 (POSIX.2) and its subsequent amendments, combined with the core volumes of the Single UNIX Specification, Version 2. It is technically identical to The Open Group, Base Specifications, Issue 6; they are one and the same documents, the front cover having both designations.
Mais il est vrai que, en faisant un rapide tour sur le site ieee.org , j'ai trouvé une page de souscription payante pour accéder aux normes IEEE... Finalement, je me suis peut-être gourré, mais dans ce cas, il faudra qu'on m'explique pourquoi Open Group prétend distribuer un document technically identical à la dernière version de la norme POSIX, alors que l'IEEE interdit sa reproduction gratuite ( http://shop.ieee.org/ieeestore/Product.aspx?product_no=SE952(...) ).
Sinon, je me demande si les autotools ne pourrait pas gérer cela tous seuls sans avoir à écrire des scripts m4 particuliers pour chaque bibliothèque qu'on souhaite utiliser et qui pourrait être dans des répertoires différents de /usr/include et autre.
Bah non, autoconf ne peut pas deviner de lui-même dans quels dossiers telle bibliothèque peut être placée, ni les quatre milliards de combinaisons possibles de flags pour le compilateur suivant les options et versions de ta bibliothèque...
Il faut créer un petit bout de script pour lui permettre de le faire, et c'est ce qui est dans le lien que je t'ai donné: le fichier m4 fourni permet à autoconf de gérer proprement la bibliothèque netcdf. Autoconf ne fait pas de la divination; il utilise simplement les scripts dont il dispose pour savoir comment gérer tous ce qu'on lui demande.
Attached is an autoconf script for use with netCDF. This script is for
people who write and distribute their own software packages that will be
made by the users with './configure' AND that require netCDF to be
installed on the user's platform. (In other words, this script is for
software developers, not end users.) The script checks in various places
I've found the netCDF library to be lurking in over the years
Je suppose que l'algorithme est déjà bien défini (traitement d'erreurs, notemment).
Pour le codage en C: fgets sert à lire une ligne de texte. Mais attention, cette fonction n'est pas simple à utiliser. Elle s'arrête soit:
- quand le marqueur de fin de ligne '\n' est rencontré
- quand le buffer que tu lui as passé est plein
- en cas d'erreur interne (I/O, par exemple).
Dans le troisième cas, fgets renvoie NULL; pour différencier les deux premiers, il faut chercher le caractère '\n' dans le buffer (pour chercher un caractère dans une chaîne: strchr). Si la ligne n'est pas complète, il vaut mieux réallouer un buffer plus grand.
Et tout ça est C ISO. Il n'y a pas besoin de dépendre d'une bibliothèque externe, mais il faut avouer que ça peut être utile; Pour lire une ligne d'un fichier sans s'embêter avec fgets/strchr/realloc, tu peux utiliser des choses déjà existantes, comme la fonction fggets de CB Falconer, un participant régulier de comp.lang.c, qui évite tous ces problèmes http://cbfalconer.home.att.net/download/index.htm
. Cette fonction (implementée en C ISO, donc portable), distribuée en domaine public, t'épargne les tests à n'en plus finir. Tu auras juste à écrire quelque chose comme : char *ligne=NULL;
FILE *fd = fopen("ton_fichier", "r");
if (fd == NULL)
{ /* traitement d'erreur */ }
while (fggets(&ligne, fd) == 0)
{
/* la boucle principale */
}
Ensuite, pour comparer deux chaînes (dans le cas de 'DEBUT' et 'FIN'): strcmp.
Avec ça, tu devrais déjà avoir de quoi faire. Si tu as d'autres questions, ou que l'explication n'est pas claire, n'hésite pas à redemander.
Pour vc1decbit.c: il s'agit d'une macro utilisée pour tracer des messages de debug (DEBUG2) qui est en cause, ou plutôt son utilisation. Note qu'en mode non-debug, cette macro est définie par une expression nulle, le warning n'apparaît donc qu'en mode DEBUG (plus précisément, quand la macro NDEBUG est definie).
Exemple, ligne 473: DEBUG2(vc1DEBUG_BIT, "Initialise Bitstream Start=0x%08x Length=%d\n",
(int)pBuffer, Length);
Sans aller voir la fonction qui est utilisée, on sent qu'elle doit être basée sur uen fonction de la famille de printf() (à vérifier). Si c'est le cas, alors ils utilisent le format %x pour afficher en hexadécimal les valeurs du pointeur pBuffer. Vu qu'il ne s'agit que d'un message de debug, on peut je pense changer la ligne (qui, de toute façon, invoque au mieux un comportement implementation-defined) en: DEBUG2(vc1DEBUG_BIT, "Initialise Bitstream Start=%p Length=%d\n",
(void *)pBuffer, Length);
Ainsi, on ne risque pas de warning, et c'est portable. L'affichage sera juste un peu différent, mais si c'est juste pour le debug, changer le format d'affichage ne devrait pas gêner outre mesure.
Note que le cast en void * est nécessaire.
Ce n'est pas un problème spécifique à un passage de 32 à 64 bits, mais juste une utilisation de propriétés implementation-defined (voire undefined) de gestion des pointeurs qui a été mis en évidence par un changement d'architecture...
Ainsi, les 2 premiers paramètres passés à vc1RECON_ReconstructMB sont définis comme des tableaux, mais le passage en paramètre d'un tableau le convertit implicitement en pointeur. Comme il s'agit de tableaux multi-dimensionels, 6.5.2.1 dit que TCoefs est converti en un pointeur vers HWD16 [64], alors que la fonction attend un pointeur vers const HWD16 [64]. Pour vc1recon.c: les lignes 110 et 120 ont le même problême que pour vc1decblk.c: un assignation de pointeurs de type diférents, la différence étant due au qualificateur const.
Apres une petite recherche sur comp.lang.c, j'ai trouvé dans la FAQ ceci: http://c-faq.com/ansi/constmismatch.html
Pour résumer, le moyen de contourner le problème est de faire un cast. Pas propre, tout ça...
Ou alors il faudrait enlever le const du prototype des fonctions en cause. Cette dernière solution aurait au moins le mérite de ne plus causer de problème; mais je supose que les const sont là pour optimiser un chouia le code. On peut les virer au moins pour commencer (il vaut mieux faire du code qui marche et ensuite l'optimiser, que créer un code optimisé et ensuite le corriger).
Note que la ligne 120 de vc1recon.c pose un autre problème: un paramètre formel de la fonction, de type tableau multidimensionel (donc, en réalité, pointeur sur tableau), est réassigné ! C'est légal du point de vue du C (pour autant que je sache), mais c'est très moche...
[^] # Re: Solution de facilité
Posté par alf . En réponse au journal Pourquoi aussi peu de femmes dans les métiers de l'informatique ?. Évalué à 1.
Ils ne disaient pas (pour autant que je sache) qu'elles étaient nulles, mais ils étaient moins encourageants pour qu'elles s'orientent vers des études scientifiques que des gars du même niveau. Nuance. Mais à part ça, t'inquiète pas, il y a des filles qui n'écoutent pas et font ce qu'elles veulent quand même, et qui finissent major de promotion ;)
Ceci dit, l'inertie culturelle et sociale est quand même assez forte... Ca dépend de l'environnement familial, des profs qu'on a, d'amis... A part ça, presque tous mes profs de math au collège et au lycée étaient des femmes, et un peu moins en physique. Comme quoi...
[^] # Re: Solution de facilité
Posté par alf . En réponse au journal Pourquoi aussi peu de femmes dans les métiers de l'informatique ?. Évalué à 2.
D'ailleurs, il n'y a pas besoin de faire des études sociologiques poussées pour s'en rendre compte, il suffit de causer avec des amis/profs/collègues sur leurs orientations profressionnelles. Je connais plusieurs femmes qui, au lycée, voulaient faire des études scientifiques, mais leurs profs n'étaient pas forcément super enthousiastes ou encourageants - alors que des gars avec à peu près les mêmes notes étaient mieux vus.
Sinon, dans ma promo, moins de 10 % de fille dans l'option info de mon école... (mais d'autres options remplissent largement, allez savoir pourquoi)
[^] # Re: Mouairf mais...
Posté par alf . En réponse au journal Pourquoi aussi peu de femmes dans les métiers de l'informatique ?. Évalué à 2.
Hein ? Bah merde alors, je suis geek et les blagues de cul ne me font pas rire (enfin, les lourdes, quoi. Quand Desproges fait de l'humour sur la sexualité, oui ça me fait rire. Mais bon, Desprogres n'était pas un geek.).
D'ailleurs, je ne vois pas pourquoi un groupe qui se forme autour d'une curiosité technique/attrait du libre/autre intérêt qu'on peut trouver dans l'informatique tendrait automatiquement à faire des blagues salaces... Il y a sûrement des choses qui m'échappent, mais il me semble qu'on peut être geek et de bon goût(TM). Enfin, j'essaye (et je pense ne pas avoir de réputation de gros lourd auprès de mes amis/collègues).
[^] # Re: man
Posté par alf . En réponse au message Traitement de ligne de fichier. Évalué à 1.
fgets est la fonction ISO qui permet de faire ça, mais son usage n'est pas trivial: cf. https://linuxfr.org/comments/713347.html#713347 pour un de mes posts précédents à ce sujet.
[^] # Re: man
Posté par alf . En réponse au message Traitement de ligne de fichier. Évalué à 1.
#include "stdio.h"Normalement, c'est avec les < et >, mais il est vrai que ça marche aussi avec (à condition que tu n'aies pas placé un autre fichier stdio.h dans ton chemin d'inclusion).//Ouvre le fichier passé en paramètre 1 FILE *fd = fopen(argv[1], "r"); //Caractère lu char c; //Lis chaque caractère du fichier while ((c = getc(fd)) != EOF)Deux erreurs: tu ne vérifies pas le résultat de fopen (peut-être que le fichier n'a pas été ouvert ?), et tu utilises une variable de type char pour stocker le résultat de getc. http://c-faq.com/stdio/getcharc.html# FAQ ?
Posté par alf . En réponse au message Conflits de license, ou : pladoyer pour le double cursus droit / informatique. Évalué à 2.
Mais la notion de "compatibilité" dépend de ce que tu veux faire:
- si c'est livrer une application qui contient un module sous licence Apache, et un sous GPL, non modifiés, alors ça peut être OK suivant le niveau d'intrication entre les différents composants (notion de "derived work", si je me souviens bien du phrasé de la GPL que je n'ai pas sous les yeux).
- Si c'est pour modifier les sources d'un module Apache et d'un module GPL pour les mélanger, alors je pense que l'incompatibilité survient.
Mais, comme toujours dans ces histoires, pour déterminer s'il y a conflit ou non, il faut être très prudent quant au niveau de dépendance entre les composants, aux modifications que tu leur portes... A part l'extrait de la page de la FSF que j'ai cité, ceci n'est que mon avis perso...
[^] # Re: fflush(stdin) = comportement indéfini
Posté par alf . En réponse au message scanf didju.. Évalué à 0.
[^] # Re: c99, ansi ou autre ?
Posté par alf . En réponse au message Compilation avec gcc. Évalué à 0.
Tu ne dois donc en garder qu'une sur les deux options. Au passage, je n'ai pas trouvé si la doc indiquait quel norme ou standard gcc suit si on en spécifie deux (cf. http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/C-Dialect-Option(...) ). On pourrait faire le test avec un programme invoquant un "silent change", mais je pense que le plus simple est de faire attention à avoir des makefile propres dès le départ, plutôt que de se poser ce genre de questions...
[^] # Re: c99, ansi ou autre ?
Posté par alf . En réponse au message Compilation avec gcc. Évalué à 0.
Mais j'admets que l'erreur de traduction est très répandue... Ce qui ne l'excuse pas.</mode>
Ceci dit, pour en revenir au sujet de la discussion, les commentaire d'une ligne "à la C++" commencés par // ont été effectivement introduits dans la norme C dans la version C99, étant donné que nombre d'implémentations le proposaient déjà comme extension.
Par ailleurs, gcc propose aussi le mode -std=gnu99 pour disposer de la norme C ISO 99 + les extensions GNU (le "standard" par défaut de GCC étant gnu89, et ce probablement jusqu'à ce que toute la norme C99 soit correctement implémentée, ce qui risque de prendre encore du temps. Patience, cette norme n'est sortie qu'il y a 7 ans, après tout...)
[^] # Re: fflush(stdin) = comportement indéfini
Posté par alf . En réponse au message scanf didju.. Évalué à 0.
int c; while((c = getchar()) != '\n' && c != EOF) /* discard */ ;(j'ai quand même rajouté la définition de c pour éviter que quelqu'un l'utilise avec un char)[^] # Re: NoHup
Posté par alf . En réponse au message recherche de command adapter. Évalué à 0.
nohup permet de lancer un programe sous le compte de l'utilisateur, et qui continue de tourner après la déconnexion de l'utilisateur.
Quand l'utilisateur quitte son shell, le système envoie le signal SIGHUP à tous les programmes lancés depuis ce shell (ou plus précisément les processus "fils" du shell), ce qui a pour effet de terminer ces programmes. nohup permet de lancer un programme de telle manière que le signal SIGHUP ne le tue pas.
Note qu'il existe aussi screen qui permer de garder des sessions shell ouvertes même si on se déconnecte, pour se reconnecter ensuite et reprendre la session, mais celà est peut-être plus élaboré que ce dont tu as besoin.
# Dépendances ?
Posté par alf . En réponse au message xine-lib sur fedora core 5. Évalué à 0.
Les macros XINE_XVMC_ACCEL_VLD et autres doivent être définies dans des fichiers introuvables à la compilation... Peut-être manque-t-il des ficheirs d'en-têtes, ou un autre package, pour pouvoir compiler le tout ?
[^] # Re: Vieux souvenirs....
Posté par alf . En réponse au message scanf didju.. Évalué à 1.
printf("\n") ne fait que vider le buffer du flux stdout (une implémentation pourrait profiter de ce moment pour vider les tampons d'autres flux sortants en même temps, pour optimiser les accès I/O, mais c'est aléatoire). Le flux stdin ne peut être "vidé" ainsi, comme je l'ai dit plus bas.
# fflush(stdin) = comportement indéfini
Posté par alf . En réponse au message scanf didju.. Évalué à 1.
Appliquer fflush à un flux entrant comme stdin résulte en un comportement indéfini. Windows peut aussi bien faire dans ce cas ce que tu voudrais qu'il fasse, comme une autre implémentation (ou le même Windows un autre jour) peut ne rien faire... cf. http://c-faq.com/stdio/stdinflush.html et http://c-faq.com/stdio/stdinflush2.html
[^] # Re: fgets + sscanf
Posté par alf . En réponse au message scanf didju.. Évalué à 0.
Si. Enfin, presque: la meilleure façon de le faire, c'est d'utiliser une fonction spécifique qui encapsule le fgets car, comme je l'ai dit ici ( http://linuxfr.org/comments/713347.html#713347 ), son utilisation n'est pas triviale. http://cbfalconer.home.att.net/download/index.htm propose une fonction fggets simple d'utilisation qui prend une ligne entière d'un flux pour la mettre dans une zone allouée avec un *alloc.
Pour traiter la chaîne "brute" ainsi récupérée, il faut ensuite utiliser des fonctions comme sscanf ou strto*, suivant les besoins, en vérifiant les conditions d'erreur.
[^] # Re: Bieng !
Posté par alf . En réponse au message resultat de compilation. Évalué à 0.
[^] # Re: Pour vérifier le fichier maintenant
Posté par alf . En réponse au message reconnaitre un nom de fichier. Évalué à 0.
Moui. Dans l'hypothèse de deux groupes indépendants qui auraient la même idée et la publieraient séparément, je suis d'accord. Mais dans le cas SUS/POSIX, qu'elles soient identiques (mis à part les extensions SUS) sans être copies l'une de l'autre... ça me semblerait une grosse coïncidence. Mais peut-être s'agit-il d'un cas semblable au Working Group du langage C au sein de l'ISO, qui possède les droits sur les drafts de la norme C, alors que l'ISO possède les droits sur les normes, ce qui fait que le WG a pu décider de publier les drafts en accès libre sur leur site.
J'en apprends tous les jours ;)
# Reponse au 2)
Posté par alf . En réponse au message Faire du son avec Ocaml. Évalué à 1.
[^] # Re: ma solution
Posté par alf . En réponse au message Chaine de caractère. Évalué à 1.
Si tu n'utilises pas les arguments, un void suffit.
Pense à vérifier si fopen a bien marché.
strdup est une extension GNU (je n'ai rien contre les extensions, c'est juste pour signaler qu'il y pourra y avoir des problèmes de portabilité par la suite).
Et vérifie aussi que la fonction a bien marché, sinon le fopen avec une valeur nulle causera un comportement indéfini.
Idem: vérifier le succès de fopen
Tu as oublié de comparer le début de buf avec "DEBUT". Et si une ligne du fichier d'entrée est plus longue que BUFSIZ, tu tronques les lignes...
De plus, si la ligne comprend un expace au plein milieu, ton fscanf ne prendra pas la fin de la ligne.
Tu pourrais rajouter le fclose dans ce block, pour éviter d'avoir un nombre indéterminé de fichiers ouverts en même temps (ça évite de planter si on ouvre trop de fichiers...).
Pour ton malloc: sizeof(char) vaut 1 par définition, donc tu peux simplifier l'écriture en
Pour la première étape, on a cpt == 1, donc tu réserves 4 caractères (car strlen("out") == 3). Or, tu places ensuite la chaîne "out", puis la chaîne de caractères représentant cpt+1 en décimal, c'est-à-dire "2". Tu aboutis donc à 5 caractères: 'o', 'u', 't', '2', '\0'.
Tu as donc effectué un débordement de tampon, et provoqué un comportement indéfini.
Mais, pour cpt > 1, ta formule marche efefctivement. Note quand même que faire le + cpt réserve plus de caractères qu'il n'en faut. Peut-être as-tu fait exprès, sachant que cpt caractères sont toujours suffisants pour afficher le nombre cpt+1 (si cpt > 1...), mais il faudrait au moins le metre en commentaire.
La ligne est donc suffisante; mais il ne faut pas oublier qu'on prend plus de place mémoire que nécessaire...
Par flemme, on va dire que la réécriture de ce code pour ne pas prendre plus de mémoire que nécessaire est laissé en exercice au lecteur ;)
Par ailleurs, il serait bon de vérifier que malloc n'a pas échoué, à moins de tenir à tester les comportements indéfinis de ton implémentation ;)
Et il faudrait aussi noter que le "32" pour le buffer du sprintf est purement arbitraire (très largement suffisant, mais juste pour noter en commentaire dans le code).
[^] # Re: Pour vérifier le fichier maintenant
Posté par alf . En réponse au message reconnaitre un nom de fichier. Évalué à 1.
Et j'ai aussi http://www.opengroup.org/austin/papers/posix_faq.html
Donc il s'agirait bien de la dernière version de la norme POSIX qui serait dispo sur ce site.
Ainsi que http://www.unix.org/version3/ieee_std.html
Mais il est vrai que, en faisant un rapide tour sur le site ieee.org , j'ai trouvé une page de souscription payante pour accéder aux normes IEEE... Finalement, je me suis peut-être gourré, mais dans ce cas, il faudra qu'on m'explique pourquoi Open Group prétend distribuer un document technically identical à la dernière version de la norme POSIX, alors que l'IEEE interdit sa reproduction gratuite ( http://shop.ieee.org/ieeestore/Product.aspx?product_no=SE952(...) ).
[^] # Re: Pour vérifier le fichier maintenant
Posté par alf . En réponse au message reconnaitre un nom de fichier. Évalué à 0.
[^] # Re: google ?
Posté par alf . En réponse au message Détecter l'emplacement d'une bibliothèque et de ses entêtes. Évalué à 0.
Bah non, autoconf ne peut pas deviner de lui-même dans quels dossiers telle bibliothèque peut être placée, ni les quatre milliards de combinaisons possibles de flags pour le compilateur suivant les options et versions de ta bibliothèque...
Il faut créer un petit bout de script pour lui permettre de le faire, et c'est ce qui est dans le lien que je t'ai donné: le fichier m4 fourni permet à autoconf de gérer proprement la bibliothèque netcdf. Autoconf ne fait pas de la divination; il utilise simplement les scripts dont il dispose pour savoir comment gérer tous ce qu'on lui demande.
# google ?
Posté par alf . En réponse au message Détecter l'emplacement d'une bibliothèque et de ses entêtes. Évalué à 1.
# Un peu de C...
Posté par alf . En réponse au message Chaine de caractère. Évalué à 1.
Pour le codage en C: fgets sert à lire une ligne de texte. Mais attention, cette fonction n'est pas simple à utiliser. Elle s'arrête soit:
- quand le marqueur de fin de ligne '\n' est rencontré
- quand le buffer que tu lui as passé est plein
- en cas d'erreur interne (I/O, par exemple).
Dans le troisième cas, fgets renvoie NULL; pour différencier les deux premiers, il faut chercher le caractère '\n' dans le buffer (pour chercher un caractère dans une chaîne: strchr). Si la ligne n'est pas complète, il vaut mieux réallouer un buffer plus grand.
Et tout ça est C ISO. Il n'y a pas besoin de dépendre d'une bibliothèque externe, mais il faut avouer que ça peut être utile; Pour lire une ligne d'un fichier sans s'embêter avec fgets/strchr/realloc, tu peux utiliser des choses déjà existantes, comme la fonction fggets de CB Falconer, un participant régulier de comp.lang.c, qui évite tous ces problèmes http://cbfalconer.home.att.net/download/index.htm
. Cette fonction (implementée en C ISO, donc portable), distribuée en domaine public, t'épargne les tests à n'en plus finir. Tu auras juste à écrire quelque chose comme :
char *ligne=NULL;
FILE *fd = fopen("ton_fichier", "r");
if (fd == NULL)
{ /* traitement d'erreur */ }
while (fggets(&ligne, fd) == 0)
{
/* la boucle principale */
}
Ensuite, pour comparer deux chaînes (dans le cas de 'DEBUT' et 'FIN'): strcmp.
Avec ça, tu devrais déjà avoir de quoi faire. Si tu as d'autres questions, ou que l'explication n'est pas claire, n'hésite pas à redemander.
[^] # Re: Problème de programmation C
Posté par alf . En réponse au message warning: cast from pointer to integer of different size. Évalué à 2.
Exemple, ligne 473:
DEBUG2(vc1DEBUG_BIT, "Initialise Bitstream Start=0x%08x Length=%d\n",
(int)pBuffer, Length);
Sans aller voir la fonction qui est utilisée, on sent qu'elle doit être basée sur uen fonction de la famille de printf() (à vérifier). Si c'est le cas, alors ils utilisent le format %x pour afficher en hexadécimal les valeurs du pointeur pBuffer. Vu qu'il ne s'agit que d'un message de debug, on peut je pense changer la ligne (qui, de toute façon, invoque au mieux un comportement implementation-defined) en:
DEBUG2(vc1DEBUG_BIT, "Initialise Bitstream Start=%p Length=%d\n",
(void *)pBuffer, Length);
Ainsi, on ne risque pas de warning, et c'est portable. L'affichage sera juste un peu différent, mais si c'est juste pour le debug, changer le format d'affichage ne devrait pas gêner outre mesure.
Note que le cast en void * est nécessaire.
Ce n'est pas un problème spécifique à un passage de 32 à 64 bits, mais juste une utilisation de propriétés implementation-defined (voire undefined) de gestion des pointeurs qui a été mis en évidence par un changement d'architecture...
Pour vc1decblk.c: le problème vient de:
vc1recon.h:
void vc1RECON_ReconstructMB (const HWD16 pTCoefs[6][64], const UBYTE8
pPredBlk[6][64], vc1_sReferencePicture *pRefPic, vc1_sPosition *pPosition, vc1_eProfile eProfile)
vc1decblk.c:
vc1_eResult vc1DECBLK_DecodeBlockLayer(
vc1DEC_sState * pState,
vc1DEC_sBitstream * pBitstream)
{
HWD16 TCoefs[6][64] = {{0}};
UBYTE8 PredBlk[6][64];
/* ... */
vc1RECON_ReconstructMB(TCoefs,
PredBlk,
pState->pCurrentRef,
pPosition,
pState->sSeqParams.eProfile);
Ainsi, les 2 premiers paramètres passés à vc1RECON_ReconstructMB sont définis comme des tableaux, mais le passage en paramètre d'un tableau le convertit implicitement en pointeur. Comme il s'agit de tableaux multi-dimensionels, 6.5.2.1 dit que TCoefs est converti en un pointeur vers HWD16 [64], alors que la fonction attend un pointeur vers const HWD16 [64]. Pour vc1recon.c: les lignes 110 et 120 ont le même problême que pour vc1decblk.c: un assignation de pointeurs de type diférents, la différence étant due au qualificateur const.
Apres une petite recherche sur comp.lang.c, j'ai trouvé dans la FAQ ceci: http://c-faq.com/ansi/constmismatch.html
Pour résumer, le moyen de contourner le problème est de faire un cast. Pas propre, tout ça...
Ou alors il faudrait enlever le const du prototype des fonctions en cause. Cette dernière solution aurait au moins le mérite de ne plus causer de problème; mais je supose que les const sont là pour optimiser un chouia le code. On peut les virer au moins pour commencer (il vaut mieux faire du code qui marche et ensuite l'optimiser, que créer un code optimisé et ensuite le corriger).
Note que la ligne 120 de vc1recon.c pose un autre problème: un paramètre formel de la fonction, de type tableau multidimensionel (donc, en réalité, pointeur sur tableau), est réassigné ! C'est légal du point de vue du C (pour autant que je sache), mais c'est très moche...