Étienne a écrit 707 commentaires

Il me semblait que le #pragma n'était destiné qu'au compilateur et non au pré-processeur. Si tel n'est pas le cas alors je comprend que la phase de pré-processing interne à gcc ne soit pas identique à un appel à gcc -E en ce qui concerne les #pragma.

Étienne

Pourquoi alors est-ce qu'un gcc -E (ou un cpp) me laisse le #pragma ?

Merci de l'info, c'est pas que j'en ai besoin maintenant mais c'est toujours bon à savoir.

Ceci dit je me demande pourquoi le fait d'avoir un #pragma dans une macro ne marche pas étant donné que c'est supposé être utilisé par le compilateur et non par le preprocesseur.

Étienne

J'ai réussi à faire ce que tu veux mais en compilant en 2 phase, c'est à dire que j'appelle moi-même le préprocesseur et je l'envoie sur l'entrée du compilateur ainsi :

Fichier source :
#define OPT_SIZE #pragma Osize

OPT_SIZE

int main()
{
return 0;
}

$ gcc -E prep.c | gcc -o prep -x c -

J'ai l'impression que c'est par manque de temps (peut-être de temps de calcul) parce que sur certaines parties (vers la fin), on a des effets de vent sur l'herbe qui rendent pas mal et qui donne un meilleur effet que lorsque les animaux se déplacent sur de l'herbe statique.

Étienne

faut vraiment être conne pour se mettre en ménage avec un "puritain".

On en apprend tous les jours sur linuxfr. Aujourd'hui, découvrez le Puritanisme musulman avec Moun's et GeneralZod.

Tu ne peux pas supprimer un site des root servers. Parce que le DNS est hiérarchique (cf Domain_Name_System#Un_syst.C3.A8me_distribu.C3.A9) et les root servers ne te donnent que les dns pour les tld. Par exemple c'est eux qui te diront quels sont les serveurs DNS pour le tld .af. Mais si tu ne contrôle pas ces DNS tu ne peux rien faire (tu peux éventuellement bannir tous les sites afghans).

Étienne

Ca n'empêche que les principes de base "éthiques" des logiciels libres peuvent également s'appliquer au support.

Lorsque tu demande une nouvelle fonctionnalité sur un soft parce que tu en as besoin (c'est une demande particulière), rien ne te garantie qu'elle sera traitée. C'est pareil pour le support, tu peux faire sans et t'appuyer sur la communauté mais tu n'as aucune garantie. Si les entreprises payent des milliers d'euros de licences RedHat, c'est parce qu'en cas de problème elles veulent être sûr d'avoir un interlocuteur, de la même manière que pour être sûr d'avoir une nouvelle fonctionnalité, il faut payer quelqu'un pour la développer.

Étienne

Et ça a aussi l'énorme avantage de correctement supprimer les fichier contenant un espace. Ce qui n'est pas le cas du bourrin rm $(cat fichier)

Étienne

Il y a juste une petite coquille, tu fais 2 read au lieu d'un :
while read i
do
    rm "$i"
done < fichier


Étienne

On espère qu'EDF est au courant et qu'en cas de problème, vous avez un courant alternatif.

donc ils utilisent le C++ comme un C amélioré
Ou comme du Java

petit joueur ;) :
telnet linuxfr.org 443

Sinon attaquer directement un miroir debian en https, je crois qu'il n'y en a pas des masses mais https://ftp.iitm.ac.in/debian (miroir situé en Inde) doit faire l'affaire.
Pour en trouver un plus près de chez toi, regarde sur http://www.debian.org/mirror/list et fait les test sur chaque serveur http pour vérifier s'il accepte le https.

Etienne

C'est tout à fait exact et je ne prétends pas dire qu'il n'y a pas eu d'erreur, néanmoins, je pense que le mainteneur Debian n'est pas le seul en cause, sans doute que le code n'était pas aussi clair qu'il aurait dû l'être pour cette partie sensible (voir à ce propos cette réaction : http://www.aigarius.com/blog/2008/05/14/too-similar-to-be-di(...) ).
Comme dans tous les problème de sécurité, c'est une ensemble de déficiences qui sont à la source du problème :
- Au départ, le code n'est pas suffisamment explicite et utilise entre autre une variable non initialisée comme source d'aléa
- Le mainteneur veut supprimer les erreurs remontées
- Il demande conseil sans expliquer suffisamment ce qu'il veut faire
- Sur la mailing-list openssl-dev on ne lui explique pas suffisamment le fonctionnement
- Il corrige et supprime un peu trop de code (le mieux est l'ennemi du bien)
- Il est tout seul comme mainteneur d'openssl (en fait ils sont 2 mais il semble que le deuxième soit trop occupé) alors que ça fait 2 ans qu'il demande de l'aide ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332498 )
- Il n'y a pas de revue de la security team pour les packages sensible (manque de moyens et de bonnes volontés sans doute).


C'est clair qu'il a fait une grosse boulette, mais le processus a certainement manqué de quelques fusibles.

PS: la liste des erreurs n'est pas exhaustive, on pourrait noter un manque de remontée upstream comme il a déjà été dit

Il doit y avoir une option disable_vrfy_command = no dans ton fichier de config main.cfg (voir http://www.postfix.org/postconf.5.html#disable_vrfy_command ) il y a aussi l'option smtpd_junk_command_limit (sur la même page).

Etienne

Et si c'est vrai, c'est uniquement pour une version de debug.

Ce n'est pas ce que signifie "If it helps with debugging, I'm in favor of removing them. " que je traduit par "si ça aide au débuggage, je suis d'accord pour les supprimer". Et non pas "je suis d'accord pour les supprimer en version debug".

Les discussions sur linuxfr c'est mieux que le bistro du coin, avec tous les clichés sur la religion, la justice, la prison et même un peu de sexe. Sans oublier bien sûr les opinions éclairées de tous ceux qui n'ont aucune information.

Certains rétorqueront avec raison qu'il y a même, à travers ce commentaire entre autre, l'avis des gens qui n'ont rien à dire, à qui personne n'a rien demandé mais qui tiennent à le partager.


Patron encore un pt'it blanc.

Il est possible d'utiliser la commande jobs pour lister les processus en arrière plan et ainsi faire une boucle pendant les 5 secondes, par exemple :

#!/bin/bash
#
# Lance une commande rsh en forcant un kill après une durée de 5 sec
# pour eviter que rsh reste bloqué
#

# on execute le rsh en arrière plan
rsh "$@" &
# on récupère le PID du rsh
PID=$!

for i in $(seq 5)
do
    #options de jobs
    # -p affiche le PID des processus en backgroupd
    # -r n'affiche que les processus qui sont en cours d'execution (pas ceux qui sont déjà terminés)
    # Si le process est terminé, on peut quitter tranquillement.
    jobs -pr | grep -q $PID || exit
    sleep 1
done

# au bout de 5 sec on kill le pid en question
kill -TERM $PID 2> /dev/null


Je pense que tu trouveras toutes les informations complémentaires sur le site internet ;)

Excepté que le C++ peut être utilisé de façon simple.
Comparaison n'est pas raison.

La même chose et simplement pour gagner quelques caractères :
awk '/TIMESTAMP 12\/31\/2007/{print; exit;} {print;}'

En effet, avec awk /pattern/{ code;} exécute le code du bloque si la ligne correspond au pattern.
De même print $0; peut s'abréger en print;

Par rapport à la version en sed, c'est vrai que awk est un peu plus clair, sed ayant des commandes très abrégées.

Étienne

Une ligne de sed

sed -ne '/^TIMESTAMP 12\/31\/2007/q;p'

Pour l'explication :
- /pattern/q va exécuter la command q (quitter) si la ligne correspond au pattern.
- p afficher la ligne.

Dans cet ordre, on ne va pas afficher la ligne qui correspond au pattern, mais si on inverse les deux commandes :
sed -ne 'p;/^TIMESTAMP 12\/31\/2007/q'
On imprimer avant de quitter donc on affichera la ligne.

Etienne

Pour le réseau, la bibliothèque asio http://asio.sourceforge.net/ est pas mal du tout. Et pour les regex, boost dispose d'une bibliothèque pour cela (ou bien pcre++ qui est un wrapper assez fin en C++ autour de la bibliothèque pcre).

Étienne

Le serveur SSH va exécuter fortune mais ça ne ferme pas la connexion. Le script ~/.ssh/rc est exécuté mais pas "sourcé" par ton shell. Ton exit va juste te faire sortir du script rc, ensuite la connection ssh va continuer.
Par contre je pense qu'en mettant comme shell /bin/false (ou /sbin/nologin sur certaines distributions), tu va exécuter le script rc puis un shell qui quitte tout de suite.

Etienne