On Wed, 2017-11-08 at 09:49 +0200, Johan Hedberg wrote: > Hi Bastien, > > On Tue, Nov 07, 2017, Bastien Nocera wrote: > > In 6c467e9, get_pairing_type() was modified to return a structure > > that's > > allocated on the stack. While not a problem for the direct callers, > > as the function is defined as "inline", function that expected to > > return > > this structure themselves would fail, as the stack would be > > trampled > > upon on function exit. > > The devices array inside get_pairing() is declared as static, so I > don't > see how this can be on the stack? Looks like I chased down a wild goose, and that while it "fixed" my problem, the root cause was something completely different. There's a new patch coming up. > Are these the structures you're > referring to? That said, it seems weird to have an inline function > declare a static variable, since then every single caller of the > function would cause another static variable to be allocated, right? > It > seems to me that if the function is still desired to be inline then > the > cable_pairing array should at least be moved into some c-file, so > that > it only gets created once. Perhaps a better solution is however to > stop > having get_pairing() as inline to begin with? The reason to having this inline in a shared header was explained in the commit message I believe. We need this code both in the core/builtin input plugin and in the sixaxis plugin. We'd either need to make this function public in the core, meaning in the external plugin API, or copy/pasted between the 2 parts, both of which are inconvenient. If the function wasn't inline, we'd have 2 functions with the same name, and the external plugin, sixaxis in this case, would fail to load. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
