Interdire l'écriture entre fonctions

Version imprimable

Voir 40 message(s) de cette discussion en une page

22/12/2006, 10h43
fveysseire

Citation:

Envoyé par DaZumba

Un utilisateur de quoi ? Du code source ? Alors, il suffit d'avertir par un commentaire --

la fonction test est contenu dans une librairie dynamique de type .so je veux que quiconque veuille utiliser cette fonction soit obligé de déclarer les variables (correspondant aux paramètres de la fonction test ) de telle manière qu'il ne puisse écrire dedans.

Apparement d'après les différents post, utiliser des const sur des pointeurs ou double pointeurs dans le prototype de la fonction test ne suffit pas à cause des cast?
22/12/2006, 10h45
fveysseire

Sorry Emmanuel j'ai posté après ton dernier post.

Donc la réponse à ma question est non, a cause des cast.

Merci
22/12/2006, 10h50
Thierry Chappuis

Citation:

Envoyé par fveysseire

Le post original n'est pas correct, je souhaite obliger le main à rendre la variable pbyVar2 non modifiable dans le main.

Mais si tu déclares ta variable dans la main comme une constante, tu ne pourras pas non plus la modifier par l'intermédiaire de ta fonction test.

Si pour toi, l'utilisateur, c'est le programmeur responsable d'écrire la fonction main, tu n'as aucun moyen de le forcer à le faire autre que de le suggérer très fortement dans une documentation. Mais plus ce post avance, et plus j'ai du mal à voir où tu veux en venir. La façon la plus élégante que je connaisse de contrôler l'accès à une donnée, c'est d'utiliser un type abstrait de donnée et de forcer l'utilisateur à passer via une interface pour accéder à l'information. C'est d'ailleurs cette technique que l'on utilise quand on programme dans un style orienté-objet où l'encapsulation des données est essentielle.

Thierry
22/12/2006, 10h50
fveysseire

Citation:

Envoyé par Emmanuel Delahaye

Non. On peut concevoir des interfaces cohérentes, mais si un codeur veut passer outre, à coup de cast sauvages, on ne peut rien faire. Tu voudrais quoi ? Qu'on lui envoie une décharge dans le clavier ?

Ou qu'un lutin sorte de l'écran et le cogne avec un baton LOL.

Ta réponse est clair et tu l'avais déjà aborder quelque post avant, mais ce qui m'a mis un doute dans la compréhension de ma question est :

Citation:

Envoyé par Emmanuel Delahaye

...Il faut l'éduquer, c'est tout...

je chercher à protéger en écriture certaine variable pour éviter que certain codeur vienne tout saccager. ce n'est pas un problème d'éducation. :)
22/12/2006, 10h55
Thierry Chappuis

Citation:

Envoyé par fveysseire

je chercher à protéger en écriture certaine variable pour éviter que certain codeur vienne tout saccager. ce n'est pas un problème d'éducation. :)

C'est bien ce que j'avais compris, et la solution t'as été donnée plusieurs fois...

Thierry
22/12/2006, 10h56
Emmanuel Delahaye

Citation:

Envoyé par fveysseire

je chercher à protéger en écriture certaine variable pour éviter que certain codeur vienne tout saccager

On se tue à te le dire : ADT.

Si l'utilisateur ne sait pas où sont les variables, il ne pourra pas les modifier. L'accès est indirect via un pointeur 'anonyme' (une sorte de void *, mais typé).

Evidemment, on ne peut empêcher un utilisateur de lire les données à partir de cette adresse, et même de les écraser avec un memset() ou un pointeur typé. Mais au moins, on aura essayé de rendre l'accès plus difficile.

Il existe cependant une autre technique, plus compliquée à mettre en oeuvre et d'usage moins universel, c'est de retourner non pas une adresse, mais un numéro unique géré en interne dans la bibliothèque (mémoire interne statique indispensable, ce qui rend le code non réentrant).

Comme ce n'est pas une adresse, on ne peut plus l'utiliser pour accéder aux données.

C'est le principe des File Descriptors POSIX.1 (open(), socket() etc.)
22/12/2006, 11h16
Thierry Chappuis

Citation:

Envoyé par Emmanuel Delahaye

On se tue à te le dire : ADT.

Si l'utilisateur ne sait pas où sont les variables, il ne pourra pas les modifier. L'accès est indirect via un pointeur 'anonyme' (une sorte de void *, mais typé).

Evidemment, on ne peut empêcher un utilisateur de lire les données à partir de cette adresse, et même de les écraser avec un memset() ou un pointeur typé. Mais au moins, on aura essayé de rendre l'accès plus difficile.

Il existe cependant une autre technique, plus compliquée à mettre en oeuvre et d'usage moins universel, c'est de retourner non pas une adresse, mais un numéro unique géré en interne dans la bibliothèque (mémoire interne statique indispensable, ce qui rend le code non réentrant).

Comme ce n'est pas une adresse, on ne peut plus l'utiliser pour accéder aux données.

C'est le principe des File Descriptors POSIX.1 (open(), socket() etc.)

Tiens, ça m'intéresse ça...

Thierry
22/12/2006, 11h39
fveysseire

Citation:

Envoyé par Emmanuel Delahaye

Evidemment, on ne peut empêcher un utilisateur de lire les données à partir de cette adresse, et même de les écraser avec un memset() ou un pointeur typé. Mais au moins, on aura essayé de rendre l'accès plus difficile.

Il existe cependant une autre technique, plus compliquée à mettre en oeuvre et d'usage moins universel, c'est de retourner non pas une adresse, mais un numéro unique géré en interne dans la bibliothèque (mémoire interne statique indispensable, ce qui rend le code non réentrant).

Comme ce n'est pas une adresse, on ne peut plus l'utiliser pour accéder aux données.

C'est le principe des File Descriptors POSIX.1 (open(), socket() etc.)

Oki, merci pour ces informations

Voir 40 message(s) de cette discussion en une page