🚀 go-pugleaf

Emmanuel Delahaye wrote:

>>> Please, pas de mauvaises habitudes. Objet > 10 bytes -> m�moire
>>> allou�e. Point.
>>
>> Pour moi, c'est g�n�ralement au-dessus de 4000 et quelques. Sauf dans
>> les fonctions r�cursives, de cours.
> 
> Ce serait interessant que ce soit contr�lable par le compilateur,
> genre
> 
> -Wmax-auto-object-size=<n>
> 
> avec n 1..65536
> 
> -Wmax-auto-object-size=32
> 
> main.c:42 Warning: The size of local object
> 'mechant_tableau_de_la_mort' exceeds 32 bytes.

Oui, ce serait int�ressant et pratique, cependant cela n'entre pas dans
les pr�rogatives d'un compilateur de s'occuper des normes de
programmation chez Dupont & Dupond Inc.

Il pourrait faire encore mieux et enlever une partie de leur boulot aux
pondeurs de normes de D&D Limited.

S'il est sp�cifi� au compilateur une taille de pile � utiliser pour une
unit� de compilation, il a les donn�es pour savoir si cette unit� peut
d�passer cette taille, il conna�t la place que prend un cadre de pile
(j'ai parfois l'impression de parler chinois), donc dans un fil
d'empilement de fonctions dans un m�me source, il peut conna�tre la
taille de la pile utilis� dans ce fil.

On peut faire mieux.
Evidemment, il arrive souvent que des fonctions appellent des fonctions
de biblioth�ques (je ne sais pas si j'ai bien orthographi� ce mot mais
au moins je n'ai pas dit 'librairie'), quel moyen y a-t-il de savoir la
place que prennent dans la pile ces fonctions ?
La solution est simple mais am�liorable : chaque librairie devrait �tre
livr�e avec une database indiquant pour chaque fonction extern la
taille de pile qu'elle peut prendre, par un calcul principalement �
base d'additions (donc d�j� compliqu�), au niveau du link environ on
peut calculer la taille qui peut �tre prise dans la pile � partir du
main( ), on a toute les donn�es pour savoir si on prend trop de place.
Certes, cela ne marche pas en cas de r�cursivit�, puisque le graphe
d'appel n'est plus acyclique, mais cela peut nous donner une indication
pr�cieuse : quel est le niveau de r�cursivit� que l'on ne doit pas
d�passer.

Cette approche a un d�faut, elle est tr�s statique, elle envisage un
plus long chemin sans tenir compte des donn�es qui influent sur le
chemin pris.
Comme exemple : consid�rant un graphe statique, on peut �tre amen� �
suivre sa plus longue branche alors que dans les faits, d'un point de
vue dynamique, la condition qui nous am�ne dans une branche peut
justement �tre celle qui peut nous en faire sortir rapidement.

Cela peut quand m�me �tre consid�r� comme une solution garde-fou.

En attendant d'avoir trouv� un hack pour impl�menter cela rapidement, je
pense que :
. Si l'on est dans une librairie utilis�e d'un peu partout comme la
libc, on veille � n'utiliser la pile qu'avec parcimonie et � bon
escient surtout quand on doit appeler une fonction qui a �t� refil�e en
param�tre, cette conne risquerait de nous rappeler.
. Dans une biblioth�que utilisateur, �a a moins d'importance, je pense
que la pile est souvent m�me sous-utilis�e. Attention, je ne parle pas
d'embarqu� et de ce genre de choses destin�es � r�gler la hauteur de la
flamme d'un briquet, il faut faire avec la place qu'on a.
;-)

-- 
En fin de compte, je vais en reprendre un autre.