This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello, > The functions have never been public. They were not exported from > libc.so and not used outside malloc.c. Ok, I see. > Now as for providing the interface to users, this is exactly what the > libc should not do. Once exported, always exported. It would mean the > interface would have to be maintained even if the malloc implementation > changes dramatically. True, it is a matter of seeing such a change before glibc-3.x, whenever that might be. Personally, I don't see it but it's your call. Also, we have a (bad?!) precedent already, malloc_stats(). That, too, would have to be maintained. I think it would in fact be easier to maintain _int_* with a future implementation than malloc_stats(). > I hope we all agree that this isn't going to happen. I see that such an > interface is useful. But then it should be in a library on its own. Ok. Can it be arranged that the _int_* functions are marked __libc_hidden within libc.so but are exported in a separate library, say libmalloc.so? libmalloc.so would also ideally have access to other __libc_hidden symbols in malloc.os from libc.so; I guess this is impossible to achieve? Otherwise we would need code duplication in libmalloc.so. Not ideal, but if it keeps libc.so "clean"... Regards, Wolfram.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |