..:: Topic des Codeurs Couche-Tard [0] ::..

Pylades · Le 27/05/2010, à 21:08

Le +5 est un bonus spécial, qui ne compte pas vraiment dans les scores, mais si tu insistes, je peux apprendre le python et faire que ça compte vraiment dans son score.

nesthib · Le 27/05/2010, à 21:14

non c'était juste pour t'embêter
(après si tu veux me rajouter 10 points à moi j'insisterai)

Pylades · Le 27/05/2010, à 21:17

T’as pas trouvé la référence à Saint Isaac, t’as pas de points !

Bon je ne sais pas si j’attends le retour de grim7reaper pour me remettre à ma lib. Je ne sais pas quoi faire, là, en fait. C’est terrible les vacances. ^^

nesthib · Le 27/05/2010, à 22:04

plopiplop

GMT+3

helly · Le 27/05/2010, à 22:07

BN pythonneux

Pylades · Le 27/05/2010, à 22:09

Déjà ?
Lavettes !

Bon, j’ai repris ma lib, moi. J’ai refait des headers propres, et adapté le makefile en conséquence.
Ça a permis de faire du ménage.

helly · Le 27/05/2010, à 22:11

pylade, il y a un bon mois a écrit :

Demain ma lib sera finie

Pylades · Le 27/05/2010, à 22:16

helly a écrit :

pylade, il y a un bon mois a écrit :
Demain ma lib sera finie

Mensonges ! Calomnies !
J’ai juste dit que cela avançait, et que cela pourrait sortir dans la semaine. Mais en fait j’ai décidé d’aller plus loin, et tout et tout. Là, cela fonctionne, mais je suis en train de valgrinder. Et puis je compte encore ajouter quelques petites fonctionnalités.

nesthib · Le 27/05/2010, à 22:17

comment tu te fais chambrer Pylade

Pylades · Le 27/05/2010, à 22:28

nesthib a écrit :

comment tu te fais chambrer Pylade

Bof…

Sinon, pour ceux qui utiliseraient memcheck, ça vous dit quelque chose :

Invalid write of size 8
 Address 0x519a138 is 0 bytes after a block of size 8 alloc'd

Ça me le fait aussi pour les reads. Je ne comprends pas ces messages. 0 bytes, il est marrant, lui…

gnuuat · Le 27/05/2010, à 22:36

T'utilises un système 64 bits ?
En gros, je penses qu'il essaie de te dire que quand il écrit dans ce segment, ça ne fonctionne pas ^^ .

Edit : en fait, si tu donnais le dump valgrind, ça serait plus facile de t'aider...

Dernière modification par gnuuat (Le 27/05/2010, à 22:47)

grim7reaper · Le 27/05/2010, à 22:46

Bon(joir|soir) en coup de vent all.

Pylade a écrit :

Sinon, pour ceux qui utiliseraient memcheck, ça vous dit quelque chose :
Invalid write of size 8
 Address 0x519a138 is 0 bytes after a block of size 8 alloc'd
Ça me le fait aussi pour les reads. Je ne comprends pas ces messages. 0 bytes, il est marrant, lui…

Tu écris, respectivement lis, juste en dehors (d'où le 0) d'un bloc de 8 bytes (en gros tu overflow espèce de vilain ).
Par exemple le code suivant (tiré de valgrind.org)

#include <stdlib.h>
#include <stdio.h>

int main(void) {
  char *chptr;
  char *chptr1;
  int i = 1;
  chptr = (char *) malloc(512);
  chptr1 = (char *) malloc (512);
  for ( i; i <= 513; i++ ) {
    chptr[i] = '?';        /* error when i = 513 invalid write */
    chptr1[i] = chptr[i];  /* error when i = 513 invalid read and write */
  }

  free(chptr1);
  free(chptr);
}

produit

==3016==  ...
==3016== Invalid write of size 1
==3016==    at 0x80484DA: main (in /jfs/article/sample2)
==3016==    by 0x40271507: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==3016==    by 0x80483B1: free@@GLIBC_2.0 (in /jfs/article/sample2)
==3016==    Address 0x40CA0224 is 0 bytes after a block of size 512 alloc'd
==3016==    at 0x400483E4: malloc (vg_clientfuncs.c:100)
==3016==    by 0x80484AA: main (in /jfs/article/sample2)
==3016==    by 0x40271507: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==3016==    by 0x80483B1: free@@GLIBC_2.0 (in /jfs/article/sample2)
==3016== 
==3016== Invalid read of size 1
==3016==    at 0x80484EB: main (in /jfs/article/sample2)
==3016==    by 0x40271507: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==3016==    by 0x80483B1: free@@GLIBC_2.0 (in /jfs/article/sample2)
==3016==    Address 0x40CA0224 is 0 bytes after a block of size 512 alloc'd
==3016==    at 0x400483E4: malloc (vg_clientfuncs.c:100)
==3016==    by 0x80484AA: main (in /jfs/article/sample2)
==3016==    by 0x40271507: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==3016==    by 0x80483B1: free@@GLIBC_2.0 (in /jfs/article/sample2)
==3016== 
==3016== Invalid write of size 1
==3016==    at 0x80484EB: main (in /jfs/article/sample2)
==3016==    by 0x40271507: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==3016==    by 0x80483B1: free@@GLIBC_2.0 (in /jfs/article/sample2)
==3016==    Address 0x40CA0454 is 0 bytes after a block of size 512 alloc'd
==3016==    at 0x400483E4: malloc (vg_clientfuncs.c:100)
==3016==    by 0x80484BF: main (in /jfs/article/sample2)
==3016==    by 0x40271507: __libc_start_main (../sysdeps/generic/libc-start.c:129)
==3016==    by 0x80483B1: free@@GLIBC_2.0 (in /jfs/article/sample2)

Quand on arrive au Valgrind ça sent la fin, ta lib va bientôt connaître sa première release .

Pinaise, j'aurais pu marquer 10 points tout les soirs cette semaine, mais bon j'ai pas vraiment la tête à ça en ce moment .

Dernière modification par grim7reaper (Le 27/05/2010, à 22:59)

helly · Le 27/05/2010, à 23:00

BN sanglant

Dernière modification par helly (Le 27/05/2010, à 23:00)

cm-t · Le 27/05/2010, à 23:04

Plop-t

\\Ouranos// · Le 27/05/2010, à 23:04

helly a écrit :

BN sanglant

Sans gland ?

No métaporn inside

gnuuat · Le 27/05/2010, à 23:08

Bon, ceci va être un cross-post .
Je viens de découvrir à ma grande stupéfaction que je ne faisait pas une utilisation sémantique de cat.

En effet, cat est un pogramme de concaténation... Et je m'en sers souvent pour lire des fichiers.
Bon, j'utilise surtout less, mais il m'arrive d'utiliser cat quand je ne veux pas avoir de pagination etc...

Mais si je ne peux plus utiliser cat pour une lecture simple d'un fichier, que puis-je utiliser ?

J'ai tester read < file, et c'est nul .

Et pr est encore pire .

Dernière modification par gnuuat (Le 27/05/2010, à 23:11)

Pylades · Le 27/05/2010, à 23:42

grim7reaper a écrit :

Tu écris, respectivement lis, juste en dehors (d'où le 0) d'un bloc de 8 bytes (en gros tu overflow espèce de vilain ).
Par exemple le code suivant (tiré de valgrind.org)
[…}

Gné ? Là il écrivent avec ptr[513] alors qu’ils n’ont alloué que 512 bytes, c’est normal qu’ils overflow (il n’ont droit qu’à ptr[511])…
Mais moi, je suis réglo. Enfin, j’ai l’impression.
De toutes, façons, je suis crevé de chez crevé, donc là je ne peux plus rien faire. On verra quand j’aurais les idées claires.

grim7reaper a écrit :

Pinaise, j'aurais pu marquer 10 points tout les soirs cette semaine, mais bon j'ai pas vraiment la tête à ça en ce moment .

Rien de grave, j’espère ?

gnuuat · Le 27/05/2010, à 23:55

Hop, petit remède crade au problème ./viewtopic.php?pid=3509288#p3509288, je referai ça en propre plus tard, si j'en ai pas la flemme :

/*
** Copyright (c) 2010, Free Software Foundation
**
** Permission to use, copy, modify, and/or distribute this software for any
** purpose with or without fee is hereby granted, provided that the above
** copyright notice and this permission notice appear in all copies.
**
** THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
** WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
** MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
** ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
** WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
** ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
** OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#include <fcntl.h>

#define BUFF_SIZE 2048
#define MIN_FILE 1
#define MSG_SYNOPSIS "rd [FILE]...\n"
#define MSG_SEPARATION "-- END OF FILE --\n"
#define MSG_CANNOT "Open error on file"

void	rd(char *filename)
{
  char	buff[BUFF_SIZE];
  int	readed;
  int	fd;
  
  fd = open(filename, O_RDONLY);
  if (fd != -1)
    {
      do
	{
	  bzero(buff, BUFF_SIZE);
	  readed = read(fd, buff, BUFF_SIZE);
	  write(STDOUT_FILENO, buff, BUFF_SIZE);
      	}
      while (readed > 0);
    }
  else
    {
      write(STDERR_FILENO, MSG_CANNOT, strlen(MSG_CANNOT));
      write(STDERR_FILENO, filename, strlen(filename));
      write(STDERR_FILENO, "\n", 1);
    }
  close(fd);
}


int	main(int argc, char **argv)
{
  int	status;

  status = EXIT_SUCCESS;
  if (argc > MIN_FILE)
    {
      while (--argc >= MIN_FILE)
	{
	  rd(argv[argc]);
	  write(STDOUT_FILENO, MSG_SEPARATION, strlen(MSG_SEPARATION));
	}
    }
  else
    {
      write(STDERR_FILENO, MSG_SYNOPSIS, strlen(MSG_SYNOPSIS));
      status = EXIT_FAILURE;
    }
  return (EXIT_SUCCESS);
}

Copiez ça dans un fichier nommé "rd.c", puis éxécutez la commande suivante dans un terminal :

gcc ./CHEMIN_DU_FICHIER_C/rd.c -o ./DESTINATION_BINAIRE/rd

Remplacez évidemment CHEMIN_DU_FICHIER_C et DESTINATION_BINAIRE par ce qui correspond le plus.

L'avantage de cette solution, c'est qu'elle est rapide et simple, comme le veut l'esprit UNIX .
Le "crade", c'est juste parce que tout est dans un fichier, sans makefile et quelques trucs de code, mais ça ne va rien faire à votre système.

Dernière modification par gnuuat (Le 28/05/2010, à 00:08)

gnuuat · Le 28/05/2010, à 00:04

Bon, et le crade est aussi mi parce que dans le man gcc que je propose, je met pas de flags de compilation et tout, mais dans mon makefile yen aura...
J'ai juste voulu faire simple (et compréhensible pour des novices, comme le veut l'esprit Ubuntu).

echo 'plop' > plop.txt;rd ./plop.txt

Pylades · Le 28/05/2010, à 00:10

gnuuat a écrit :

T'utilises un système 64 bits ?
En gros, je penses qu'il essaie de te dire que quand il écrit dans ce segment, ça ne fonctionne pas ^^ .
Edit : en fait, si tu donnais le dump valgrind, ça serait plus facile de t'aider...

Comment t’as deviné ?

Tiens, si tu veux te faire plaisir ! ^^

==5500== Memcheck, a memory error detector
==5500== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==5500== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==5500== Command: ./debug -fi hello!
==5500== 
==5500== Invalid write of size 8
==5500==    at 0x401997: new_long_option (user.c:60)
==5500==    by 0x400822: main (debug.c:13)
==5500==  Address 0x519a138 is 0 bytes after a block of size 8 alloc'd
==5500==    at 0x4C25153: malloc (vg_replace_malloc.c:195)
==5500==    by 0x400AB2: smalloc (atropt.c:12)
==5500==    by 0x4017A0: new_option (user.c:17)
==5500==    by 0x401AA9: new_option_table (user.c:88)
==5500==    by 0x4007E3: main (debug.c:10)
==5500== 
==5500== 
==5500== HEAP SUMMARY:
==5500==     in use at exit: 0 bytes in 0 blocks
==5500==   total heap usage: 20 allocs, 20 frees, 428 bytes allocated
==5500== 
==5500== All heap blocks were freed -- no leaks are possible
==5500== 
==5500== For counts of detected and suppressed errors, rerun with: -v
==5500== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

grim7reaper · Le 28/05/2010, à 01:28

Pylade a écrit :

Mais moi, je suis réglo. Enfin, j’ai l’impression.

Apparemment pas . Mais bon il est vrai que Valgrind fais quelques fois de faux positif (m'est encore jamais arrivé sur un de mes codes mais je sais que ça existe, déjà vu pour certaines libs).

grim7reaper a écrit :
Pinaise, j'aurais pu marquer 10 points tout les soirs cette semaine, mais bon j'ai pas vraiment la tête à ça en ce moment .
Rien de grave, j’espère ?

Oui (suffisament pour faire passer ma vie de testing en unstable) et non (il n'y a pas non plus de kernel panic en vue).

C'est "seulement" beaucoup de trucs qui me tombe dessus dans un moment pas forcément opportun (loi de Murphy tout ça...). Pris séparement ça se gère plus ou moins bien, mais tous ensemble && surtout en ce moment c'est plus hardcore.

On verra si j'en vois le bout, pour le moment rien en vue .

Bon courage pour ton debug .

BN all.

Dernière modification par grim7reaper (Le 28/05/2010, à 01:29)

samυncle · Le 28/05/2010, à 01:30

Pylades · Le 28/05/2010, à 01:36

grim7reaper a écrit :

Oui (suffisament pour faire passer ma vie de testing en unstable) et non (il n'y a pas non plus de kernel panic en vue).
C'est "seulement" beaucoup de trucs qui me tombe dessus dans un moment pas forcément opportun (loi de Murphy tout ça...). Pris séparement ça se gère plus ou moins bien, mais tous ensemble && surtout en ce moment c'est plus hardcore.
On verra si j'en vois le bout, pour le moment rien en vue .
Bon courage pour ton debug .
BN all.

Arf.
Bon, et bien bonne chance.

Et pour mon debug, je n’ai plus que ça à faire de mes journées, alors… ^^

samυncle · Le 28/05/2010, à 02:03

.

Pylades · Le 28/05/2010, à 02:12

Bonne nuit les codeurs !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1951 Le 27/05/2010, à 21:08

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1952 Le 27/05/2010, à 21:14

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1953 Le 27/05/2010, à 21:17

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1954 Le 27/05/2010, à 22:04

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1955 Le 27/05/2010, à 22:07

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1956 Le 27/05/2010, à 22:09

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1957 Le 27/05/2010, à 22:11

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1958 Le 27/05/2010, à 22:16

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1959 Le 27/05/2010, à 22:17

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1960 Le 27/05/2010, à 22:28

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1961 Le 27/05/2010, à 22:36

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1962 Le 27/05/2010, à 22:46

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1963 Le 27/05/2010, à 23:00

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1964 Le 27/05/2010, à 23:04

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1965 Le 27/05/2010, à 23:04

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1966 Le 27/05/2010, à 23:08

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1967 Le 27/05/2010, à 23:42

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1968 Le 27/05/2010, à 23:55

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1969 Le 28/05/2010, à 00:04

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1970 Le 28/05/2010, à 00:10

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1971 Le 28/05/2010, à 01:28

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1972 Le 28/05/2010, à 01:30

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1973 Le 28/05/2010, à 01:36

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1974 Le 28/05/2010, à 02:03

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#1975 Le 28/05/2010, à 02:12

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

Pied de page des forums