[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] [[!toc]] # IRC, unknown channel, unknown date youpi: Did you ever review the Savannah hurd branch master-fix_extern_inline? why static inlines instead of extern lines ? +in static inlines can lead to space waste where it isn't inlined Are you sure about that -- I don't think so. At least with 99 inlining. what can the compiler do where it isn't inlined ? include a copy thus space waste 00000000004004b1 t f 00000000004004d5 t f I've juste checked two copies of my inline function one per .o Yes, but isn't it expected tobe that way? ARen't these functions those that are never included in a libarary, as opposed to those which I switched to __extern_inline in the next patch? It's been a long time that I had a look at this... The problem with the patch from the Debian package is that the functions didn't end up in the libraries anymore. ah you mean these are private functions and thus shouldn't be exposed (unexpected_reply for instance) but the duplication issue still holds the functions not ending up in the library is a concern indeed That's what my second patch fixes, I think. grah, callisto rebooted for no reason ah, indeed the second patch fixes things correctly uh, indeed it's --dbg-package=hurd in there how odd tschwinge: for the libftpconn case, yes unexpected_reply should probably be a static inline Is this true: static inline -- either inline or emit a local symbol vs. extern inline -- either inline or emit a reference to an external symbol. so as to not expose it for other cases we can keep an extern inline as they are just programs Then everything that's not expected to end up in a libarary must be static inline, as otherwise, when the compiler can't inline, there wouldn't be a reference to it available. and that avoids duplicate code yes but as long as you provide the extern inlines by compiling an xinl.c there's no problem Sure, that'd be the alternative. for libraries you need to take care of the symbols you want to export (which can thus be in xinl.c), and those you don't want to export (and thus keep static inlines) So you say it'd be better to do that (xinl.c) instead of static inline? for programs, you can just keep them all extern inlines yes, it shares code it's only in the case of symbols that shouldn't be exported by the library that we need to use static inlines ANd in .c files that are part of programs I'd also use extern inline or static inline? for programs just always use extern lines +in as you don't care about symbol exposure unless the inline is defined in a .c file of course, in that case it's useless to make it extern But then I also always need xinl.c files for those, which we apparently don't have in a few places. yes But probably didn't notice so far, as the functions could always be inlined. probably because we used to have luck yes Yes, I was thinking about the term/munge.c thing. OK, I think I get it now. Then I'll try to fix this accordingly. But not now. Thanks for the help! ok, thanks It was quite a bit confusing to me. Due to the mostly reversed definition of extern inline in glibc (I think). inline definitely is confusing especially since the semantic has changed over time and according to standards :) And then GCC changing that according to C99. Yes. # IRC, freenode, #hurd, 2012-03-14 http://anonscm.debian.org/gitweb/?p=pkg-hurd/hurd.git;a=blob;f=debian/patches/extern_inline_fix.patch;h=b9eacbff97dc56e99a69ddb601a5fc948f6e44a7;hb=HEAD maybe review it, and then we apply it http://patch-tracker.debian.org/patch/series/view/hurd/20120222-1/extern_inline_fix.patch ;) youpi: the #ifdef __USE_EXTERN_INLINES in there and the extra "extern" decls look wrong to me iirc USE_EXTERN_INLINES is needed otherwise it's not compliant or maybe it's for -O0 anyway IIRC it's needed when !defined __USE_EXTERN_INLINES, you end up with extern decls with no corresponding definition yes they are defined in the code where? there's a special .c file in each lib libdiskfs/extern-inline.c etc oooh, right extern inline means that anyway the compiler is allowed to not always inline yes that looks good to me, then youpi: can you apply it, with proper authorship & co.? (no rush, though) sure