Malloc (Peut on configurer la flexibilité de l'OS)

Bonjour à tous,

(Un petit code vaux mieux qu'un long discourt)
char * MyZone = (char*) malloc(1024);
for (int i=0;i<2048;i++)
{
    MyZone[i]=0;
}

Ce code ne va pas planter (selon les OS) pourtant il devrait.
Ceci est due à une certaine flexibilité du noyau qui alloue plus de mémoire virtuel que ce que l'on demande.

Ma question : Peut-on restreindre cette allocation pour qu'il n'alloue que le stricte minimum (c'est à dire 1024) afin qu'il nous retourne une erreur lorsqu'on essai d'accéder a MyZone[1024]

Y'a t'il possibilité de configurer ça à la compilation du noyau, ou dans un fichier de config ?

Je vous remercie d'avance de votre aide !

Je me suis mal exprimé quand je dit flexibilité le mot tolérant est plus adéquate de plus si vous connaissez une autre méthode que de modifier le noyau et sa configuration (comme une fonction c++) je suis aussi preneur :)

Merci d'avance.

La rigueur du développeur ne serait pas suffisante ?

ciao...
BruNews, MVP VC++

:) Certainement mais j'aimerais réellement faire cette expérience (si cela est possible).

De plus, ce type de configuration permet de vérifier que votre programme ne plantera pas un jour sans raisons.
(Car même le développeur le plus rigoureux à déjà eu ce genre de problèmes (Sur 3 lignes ont voit l'erreur mais sur 10 000 c'est moins évident)

Il y à bien des softs du type valgrind qui aide le développeurs (Pour les leaks en particulier) mais ceci serait une vrai aide suplémentaire.

Si quelqu'un connai un moyen, je suis toujours preneur.

Merci.

Salut,

Je suis surpris de tes dire. Il me semble que ceci arrive quand tu développes en mode debug.
Il me semblait qu'en mode release, un plantage était quasi assuré.
Mais je dis peut être des bêtises...
Après tests, sous VS2008 en mode release, plantage du programme à cause de mémoire corrompu, mais cela dépend de ce que tu as comme données derrière....
En mode debug, plantage lors du free sur le buffer.

Dans le cas ou je me trompe:
J'ai développé une mini lib d'allocation dynamique qui "remplace" malloc, calloc, free, realloc et strdup.
Lorsque tu l'utilises en mode debug, elle t'indique une erreur si tu essaies de libérer un bloc mémoire corrompu (tu as écris avant ou après la taille que tu as alloué), et elle t'indique également les blocs non libérés lorsque tu fermes la librairie. Si elle n'est pas configurée en mode debug, elle n'ajoute presque rien à une utilisation lambda de malloc&co.
Si ça t'intéresse, je peux mettre cette lib sur cppfrance. Je me suis inspiré d'un des codes de JCDjcd. J'avais trouvé l'idée intéressante, je l'ai reprise à mes fins en l'adaptant à mes besoins.

--

Vive le C

Savon

salut

sous gcc, en compilant avec l'option -g, et en lancant ton programme avec valgrind, il te liste les erreurs (et t'insulte quand t'as fait une betise :) )

brunews :
max@max-desktop:~$ valgrind konqueror

[...]

==6973==
==6973== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 336 from 4)
==6973== malloc/free: in use at exit: 1,491,952 bytes in 7,825 blocks.
==6973== malloc/free: 427,662 allocs, 419,837 frees, 90,934,292 bytes allocated.
==6973== For counts of detected errors, rerun with: -v
==6973== searching for pointers to 7,825 not-freed blocks.
==6973== checked 2,444,152 bytes.
==6973==
==6973== LEAK SUMMARY:
==6973==    definitely lost: 8,512 bytes in 171 blocks.
==6973==      possibly lost: 32 bytes in 1 blocks.
==6973==    still reachable: 1,483,408 bytes in 7,653 blocks.
==6973==         suppressed: 0 bytes in 0 blocks.
==6973== Rerun with --leak-check=full to see details of leaked memory.


et je ne suis pas sous debian testing, mais sous ubuntu stable.

Windows ONLY:
julienbj
malloc() est un appel HeapAlloc() sur GetProcessHeap() en mode sérialisé.
Mode debug ou release n'entre pour rien dans l'affaire, c'est une question de taille de page mémoire, 4 Ko.
Si donc on appelle malloc pour 1024 une 1ere fois, il reste 3 Ko de libre derrière. Tant qu'on n'y aura pas mis des données vitales, rien à craindre.

ciao...
BruNews, MVP VC++