Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C Passage de structure en paramètre d'une fonction

Passage de structure en paramètre d'une fonction

55 réponses
Avatar
Rémi BERTHOLET
Bonjour,

J'ai un code qui ressemble =E0 cela :

struct MaStructure
{
int x;
int y;
};


void MaFonction(struct MaStructure)
{
...
}


Je peux appeler ma fonction en faisant :
struct MaStructure data =3D {0,0};
MaFonction(data);

Mais je voudrais faire quelque chose comme cela :
MaFonction({0,0});

Existe t'il une syntaxe en C pour le faire ?

Merci
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
espie
In article <4c4d6dab$0$2947$,
Richard wrote:
Le 26/07/2010 13:06, Marc Espie a écrit :
In article<4c4d6987$0$29846$,
Tonton Th wrote:
On 07/26/2010 12:39 PM, Marc Espie wrote:

si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop
l'implication des grosses boites comme microsoft sur certains aspects
de la norme (l'extreme grotesquitude des fonctions de gestion de chaine
introduites pour la prochaine revision du standard, par exemple)....



Tu est mauvaise langue :) Tu peux faire tourner quelques
référénces sur ce complôt et ces grotesquitudes ?




Cherche strcpy_s sur google, tu auras tout ce qu'il faut pour te faire
ta propre opinion.



D'un autre côté Microsoft n'a toujours pas implémenté grand chose de la
norme C99 dans visual C++. Donc c'est difficile de leur trouver une
implication dans les standards du C.



Ca peut tres bien etre une implication negative, ca serait pas la premiere
fois. Note que faire partie du comite n'implique pas qu'on va tout
implementer. Je n'y suis pas, mais ca ne me surprendrait pas outre mesure
que 'crosoft fasse capoter certaines des discussions parce que c'est des
trucs qu'ils n'ont pas (ou qu'ils font tres differemment), et qu'ils fassent
le forcing pour certaines features relativement inutiles qu'ils sont les
seuls a avoir.

Je ne pense meme pas que ca soit une seule entite indivisible. A mon avis,
ca fait longtemps que microsoft est trop gros pour avoir un avis unique sur
tout, et je suis meme certain qu'il y a des gens la-bas qui essaient
reellement de faire avancer les choses (et qui sont persuades que c'est
le meilleur OS du monde et que ce sont eux les gentils).

Je ne vois pas vraiment de raison pour qu'ils aient un comportement plus
"raisonnable" sur la norme C que sur tous les autres trucs par lesquels ils
interagissent avec le reste de l'industrie...
Avatar
Alexandre Bacquart
On 07/26/2010 01:06 PM, Marc Espie wrote:
In article<4c4d6987$0$29846$,
Tonton Th wrote:
On 07/26/2010 12:39 PM, Marc Espie wrote:

si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop
l'implication des grosses boites comme microsoft sur certains aspects
de la norme (l'extreme grotesquitude des fonctions de gestion de chaine
introduites pour la prochaine revision du standard, par exemple)....



Tu est mauvaise langue :) Tu peux faire tourner quelques
référénces sur ce complôt et ces grotesquitudes ?




Cherche strcpy_s sur google, tu auras tout ce qu'il faut pour te faire
ta propre opinion.



Tout ça pour compenser la masse ne sachant pas utiliser strncpy(). Ca en
dit long (ou pas) sur leur vision de la sécurité quand-même : rattraper
les erreurs plutôt que les prévenir. Allez hop, on le fait et on rajoute _s.

Le comité accepte ce genre de fausses solutions ?


--
Alex
Avatar
espie
In article <4c4d7835$0$22374$,
Alexandre Bacquart wrote:
Cherche strcpy_s sur google, tu auras tout ce qu'il faut pour te faire
ta propre opinion.



Tout ça pour compenser la masse ne sachant pas utiliser strncpy(). Ca en
dit long (ou pas) sur leur vision de la sécurité quand-même : rattraper
les erreurs plutôt que les prévenir. Allez hop, on le fait et on rajoute _s.



A cote, strncpy n'est pas une solution. strncpy et strncat sont des choses
bizarres qui ont un usage bien precis: faire marcher utmp.
Elles n'ont aucune utilite pour faire des copies de chaine de caracteres
"sures" et sont notablement inefficaces pour cela.

je rappelle en particulier que strncpy remplit TOUTE la taille de buffer
passee avec des zeros, donc c'est notablement mauvais pour des trucs tels
que strncpy(buffer, "bonjour", 1024).

La encore, ca n'est que mon avis, mais strncpy/strncat n'auraient jamais
du trouver leur chemin dans la norme du C... ca a sa place dans POSIX.
Et ca fait aussi partie des trucs qui devraient etre proprement documentes
dans le rationale, ce qui n'est pas le cas.



Le comité accepte ce genre de fausses solutions ?


Je crains que oui. C'est d'autant plus dommage qu'il y a d'autre vraies
solutions dans la nature (strlcpy). Mais il n'y a pas consensus dans
la communaute des Unix, en grande partie a cause d'Ulrich Drepper, qui
pense que les fonctions avec de taille de buffer sont inutiles au vrai
programmeur...
Avatar
JKB
Le Mon, 26 Jul 2010 12:16:54 +0000 (UTC),
Marc Espie écrivait :
Le comité accepte ce genre de fausses solutions ?


Je crains que oui. C'est d'autant plus dommage qu'il y a d'autre vraies
solutions dans la nature (strlcpy). Mais il n'y a pas consensus dans
la communaute des Unix, en grande partie a cause d'Ulrich Drepper, qui
pense que les fonctions avec de taille de buffer sont inutiles au vrai
programmeur...



Aïe, aïe, aïe... Je croyais que ce triste sire ne sévissait que dans
la glibc :-(

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Avatar
espie
In article , JKB <invalid> wrote:
Le Mon, 26 Jul 2010 12:16:54 +0000 (UTC),
Marc Espie écrivait :
Le comité accepte ce genre de fausses solutions ?


Je crains que oui. C'est d'autant plus dommage qu'il y a d'autre vraies
solutions dans la nature (strlcpy). Mais il n'y a pas consensus dans
la communaute des Unix, en grande partie a cause d'Ulrich Drepper, qui
pense que les fonctions avec de taille de buffer sont inutiles au vrai
programmeur...



Aïe, aïe, aïe... Je croyais que ce triste sire ne sévissait que dans
la glibc :-(

JKB



Pas forcement directement, mais il faut se rendre a l'evidence: ces temps-ci,
lorsque les gens pensent "POSIX", ils pensent "linux". L'enorme majorite
des choses rajoutees ces derniers temps (ou considerees) viennent de Linux
ou du projet GNU (confere la description de make dans POSIX.2008, qui reserve
% pour un usage qui n'est autre que celui fait par gnu-make). Si tu proposes
des innovations venant d'ailleurs, ca va etre soumis au syndrome "non
invente ici"... et de toutes facons, si c'est pas adopte par Linux, ca ne
va pas etre mis dans Posix.

Au niveau ISO et C, c'est vaguement plus nuance. Entre autres parce qu'il y
a d'autres communautes en dehors de la communaute Unix (microsoft,
l'embarque...), mais il n'empeche: je ne pense pas que tu arriveras a faire
passer quoi que ce soit qui vienne d'Unix si:
- ce n'est pas dans la glibc;
- ca n'a pas ete implemente dans gcc.

Ca va peut-etre un peu changer si Apple continue a s'investir dans llvm...
Avatar
JKB
Le Mon, 26 Jul 2010 12:44:57 +0000 (UTC),
Marc Espie écrivait :
In article , JKB <invalid> wrote:
Le Mon, 26 Jul 2010 12:16:54 +0000 (UTC),
Marc Espie écrivait :
Le comité accepte ce genre de fausses solutions ?


Je crains que oui. C'est d'autant plus dommage qu'il y a d'autre vraies
solutions dans la nature (strlcpy). Mais il n'y a pas consensus dans
la communaute des Unix, en grande partie a cause d'Ulrich Drepper, qui
pense que les fonctions avec de taille de buffer sont inutiles au vrai
programmeur...



Aïe, aïe, aïe... Je croyais que ce triste sire ne sévissait que dans
la glibc :-(

JKB



Pas forcement directement, mais il faut se rendre a l'evidence: ces temps-ci,
lorsque les gens pensent "POSIX", ils pensent "linux". L'enorme majorite
des choses rajoutees ces derniers temps (ou considerees) viennent de Linux
ou du projet GNU (confere la description de make dans POSIX.2008, qui reserve
% pour un usage qui n'est autre que celui fait par gnu-make). Si tu proposes
des innovations venant d'ailleurs, ca va etre soumis au syndrome "non
invente ici"... et de toutes facons, si c'est pas adopte par Linux, ca ne
va pas etre mis dans Posix.



Je réagissais surtout en raison des joutes verbales que j'ai pu
avoir avec ce type (et en particulier l'implantation du
pthread_kill() dans la glibc). C'est épidermique, je n'arrive plus à
le sentir. Le pthread_kill() de Linux n'est pas vraiment POSIX (ou
sur le fil...) et ça pose des tas de problèmes en particulier le
pthread_kill sur un thread avec un signal nul qui se termine par un
segfault sous Linux si le thread n'existe plus alors que la page man
stipule :

DESCRIPTION
The pthread_kill() function sends the signal sig to thread,
another thread in the same process as the caller. The signal is
asynchronously directed to thread.

If sig is 0, then no signal is sent, but error checking is still per‐
formed; this can be used to check for the existence of a thread ID.

Tu parles d'une vérification d'erreur !...

Si tout le reste est du même tonneau, je souhaite bien du plaisir
aux membres des commités ;-)

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Avatar
Alexandre Bacquart
On 07/26/2010 02:16 PM, Marc Espie wrote:
In article<4c4d7835$0$22374$,
Alexandre Bacquart wrote:
Cherche strcpy_s sur google, tu auras tout ce qu'il faut pour te faire
ta propre opinion.



Tout ça pour compenser la masse ne sachant pas utiliser strncpy(). Ca en
dit long (ou pas) sur leur vision de la sécurité quand-même : rattraper
les erreurs plutôt que les prévenir. Allez hop, on le fait et on rajoute _s.



A cote, strncpy n'est pas une solution.



Jamais dis ça. C'est juste le premier truc qui me venait à l'esprit en
voyant strcpy_s(). Mais tout réfléchi, c'est plus proche d'un strcpy()
avec une taille max.

strncpy et strncat sont des choses
bizarres qui ont un usage bien precis: faire marcher utmp.
Elles n'ont aucune utilite pour faire des copies de chaine de caracteres
"sures" et sont notablement inefficaces pour cela.

je rappelle en particulier que strncpy remplit TOUTE la taille de buffer
passee avec des zeros



Ce comportement est clairement défini. Mais tu as raison, ce n'est pas
la manière la plus efficace de copier des chaînes. Quant à la sécurité,
je préfère en général procéder autrement.

, donc c'est notablement mauvais pour des trucs tels
que strncpy(buffer, "bonjour", 1024).



Ton exemple suppose qu'on connaît la taille de la source et de la
destination, donc un strcpy(buffer, "bonjour") serait optimal et sans
risque.

C'est ce que j'entends par prévention : connaître les tailles (donc au
pire strlen(), au mieux, l'info est déjà quelque-part). Ensuite, si je
veux être efficace, c'est à coups de strcpy() ou de memcpy() + ''.

Bref, je n'aime pas ces histoires de vérification d'erreurs pour les
copies de chaînes. Je préfère la prévention et C m'offre tout ce dont
j'ai besoin.

La encore, ca n'est que mon avis, mais strncpy/strncat n'auraient jamais
du trouver leur chemin dans la norme du C... ca a sa place dans POSIX.
Et ca fait aussi partie des trucs qui devraient etre proprement documentes
dans le rationale, ce qui n'est pas le cas.



Ha bon ? Que manque-t-il plus précisément ?

Le comité accepte ce genre de fausses solutions ?


Je crains que oui. C'est d'autant plus dommage qu'il y a d'autre vraies
solutions dans la nature (strlcpy).



Je ne trouve pas ça beaucoup mieux à part la sémantique plus proche de
ce qu'on a l'habitude de voir en C. C'est encore et toujours de la
sécurité à posteriori et ça ne m'inspire pas des masses.


--
Alex
Avatar
espie
In article <4c4d9a0e$0$13073$,
Alexandre Bacquart wrote:
Ce comportement est clairement défini. Mais tu as raison, ce n'est pas
la manière la plus efficace de copier des chaînes. Quant à la sécurité,
je préfère en général procéder autrement.



C'est-a-dire, supposer que tout le code est lu en long, en large, et
en travers, et que personne ne fait d'erreur.

, donc c'est notablement mauvais pour des trucs tels
que strncpy(buffer, "bonjour", 1024).



Ton exemple suppose qu'on connaît la taille de la source et de la
destination, donc un strcpy(buffer, "bonjour") serait optimal et sans
risque.



Courage, plus que 10000 lignes de code a verifier, et il n'y aura aucun
risque... enfin aujourd'hui, parce qu'apres les gens modifient,
copient-collent, et que ca finit toujours par merdoyer sur des choses
simples.

Je ne trouve pas ça beaucoup mieux à part la sémantique plus proche de
ce qu'on a l'habitude de voir en C. C'est encore et toujours de la
sécurité à posteriori et ça ne m'inspire pas des masses.



Tiens, on va voir si je peux un peu plus t'inspirer.

Par exemple, dans mes messages, je ne met souvent pas d'accents, vieille
habitude de clavier qwerty et flemme d'aller chercher les raccourcis.

Par contre, tu en mets et tu fais attention a ton orthographe...
Mais bon, la par exemple, tu t'es vautre: a posteriori est une locution latine
et ne prend aucun accent (en particulier, pas sur le a).

Apportes-tu autant de soin a la verification de ton code de gestion de chaines
de caracteres ? Verifies-tu le code que tu utilises de facon plus precise ?
Si ca n'est pas le cas, strlcpy n'est peut-etre pas une aussi mauvaise
idee que ca...

C'est dur d'etre infaillible dans 100% des cas. Personnellement, je n'ai
pas cette pretention. Un mecanisme qui me permet de concentrer mon attention
sur des cas utiles, qui n'est pas inutilement verbeux, ET qui reste
raisonnablement efficace, ca me parle. ;-)
Avatar
Antoine Leca
Alexandre Bacquart écrivit :
On 07/26/2010 02:16 PM, Marc Espie wrote:
je rappelle en particulier que strncpy remplit TOUTE la taille de buffer
passee avec des zeros




<couic>
La encore, ca n'est que mon avis, mais strncpy/strncat n'auraient jamais
du trouver leur chemin dans la norme du C... ca a sa place dans POSIX.
Et ca fait aussi partie des trucs qui devraient etre proprement
documentes dans le rationale, ce qui n'est pas le cas.



Ha bon ? Que manque-t-il plus précisément ?



La mention explicite que strncpy() peut se transformer en gouffre au
niveau des performances ?


Mais bon, on peut quand même dire que le Rationale explique bien que
strncpy() N'est PAS conçu pour être utilisé avec des chaînes de
caractères ; si on croise avec la quantité de code où on voit strncpy()
utilisé à cet effet, on se dit que le problème se situe à un autre niveau...


Antoine
Avatar
Alexandre Bacquart
On 07/26/2010 04:59 PM, Marc Espie wrote:
In article<4c4d9a0e$0$13073$,
Alexandre Bacquart wrote:
Je ne trouve pas ça beaucoup mieux à part la sémantique plus proche de
ce qu'on a l'habitude de voir en C. C'est encore et toujours de la
sécurité à posteriori et ça ne m'inspire pas des masses.



Tiens, on va voir si je peux un peu plus t'inspirer.

Par exemple, dans mes messages, je ne met souvent pas d'accents, vieille
habitude de clavier qwerty et flemme d'aller chercher les raccourcis.



Je comprends ça, j'ai aussi une large préférence pour le qwerty en
général, sauf pour écrire dans la langue de Molière...

Par contre, tu en mets et tu fais attention a ton orthographe...
Mais bon, la par exemple, tu t'es vautre: a posteriori est une locution latine
et ne prend aucun accent (en particulier, pas sur le a).



Très juste, j'aurai au moins appris un truc.

Apportes-tu autant de soin a la verification de ton code de gestion de chaines
de caracteres ?



Même pas peur. Oui, j'apporte beaucoup de soin à la gestion des chaînes
de caractères *justement* parce-qu'en C, c'est faire de l'escalade sans
équipement. Et si jamais il m'arrive de copier-coller du code, je
vérifie tout particulièrement les sections contenant des strcpy() et
autres plaisanteries (et ça ne m'arrive jamais de copier-coller une
quantité de code telle qu'une vérification soit trop de boulot). Et pour
aller jusqu'au bout, même un strlcpy() ou autres strcpy_s() sera l'objet
de mon attention (si je ne le remplace pas par quelque-chose que je
connais bien).

Alors tu vas peut-être penser que je perds du temps, mais je n'ai pas la
prétention d'être rapide. Je passe beaucoup plus de temps à réfléchir
qu'à pondre du code. Maintenant, mes programmes sont loin de se borner à
ne faire que de la gestion de chaînes. Si un jour je dois me concentrer
là-dessus sur quelque-chose d'énorme et robuste mais pas forcément le
plus efficace, j'irai volontiers vadrouiller en dehors de C (une
bibliothèque tierce, ou un autre langage, au hasard C++) pour éviter de
fabriquer une bombe.

Verifies-tu le code que tu utilises de facon plus precise ?



Oui, surtout le code que je n'ai pas pondu moi-même.


--
Alex
1 2 3 4 5