Path: ...!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!cleanfeed3-a.proxad.net!nnrp1-1.free.fr!not-for-mail
Newsgroups: fr.comp.lang.c
From: JKB <JKB@hilbert.invalid>
Subject: Re: Fonction inline
References: <slrnsvg0vb.1acos.JKB@hilbert.systella.fr>
 <eef897d1dd621e63a3809aff819faf097130371e.camel@free.fr>
Reply-To: <jkb@invalid>
User-Agent: slrn/1.0.3 (Linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit
Message-ID: <slrnt09e6q.9sg.JKB@hilbert.systella.fr>
Date: 10 Feb 2022 07:03:54 GMT
Lines: 30
Organization: Guest of ProXad - France
NNTP-Posting-Date: 10 Feb 2022 08:03:54 CET
NNTP-Posting-Host: 62.212.98.88
X-Trace: 1644476634 news-2.free.fr 5002 62.212.98.88:34537
X-Complaints-To: abuse@proxad.net
Bytes: 1860

Le 09-02-2022, Arnaud DUMERAT <adumerat@free.fr> a écrit :
> Bonjour,

	Bonjour,

> la definition de uart0_BytesToSend est elle exposee dans libusart.a ? a
> en croire ld, non.

	Nous sommes bien d'accord. Mais il me semblait qu'une fonction
	inline était traitée par le compilateur et non par l'éditeur de lien
	(puisqu'elle était justement inline).

> deux solutions (ou plus): passer en always inline (attribute) ou forcer
> l'export par exemple avec un -whole-archive dans la creation du .a ou
> verifier pourquoi la reference a cette definition est effacee de
> l'archive

	Effectivement, je vois dans la doc de gcc un 
	__attribute__((always_inline))
	que je ne connaissais pas. Mais quelle serait la raison pour
	laquelle gcc refuserait silencieusement d'honorer le inline de la
	fonction en question ?

	Bien cordialement,

	JKB

-- 
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.