Assorted bug reports with a few fixes for busybox 1.19.0
Tito
farmatito at tiscali.it
Sun Aug 28 19:44:05 UTC 2011
On Sunday 28 August 2011 21:31:20 Tito wrote:
> On Sunday 28 August 2011 15:43:42 Matthias Andree wrote:
> > Am 28.08.2011 05:41, schrieb Denys Vlasenko:
> > > On Friday 26 August 2011 03:34, Matthias Andree wrote:
> > >> - in kconfig, note that #define _XOPEN_SOURCE 700 prevents the
> > >> definition of SIGWINCH on FreeBSD, as that's a BSD-specific signal.
> > >> I don't know what the best fix is, thus no patch.
> > >
> > > Neither do I.
> >
> > What parts of the same .c file need _XOPEN_SOURCE 700 to expose symbols,
> > or flip behaviour to be standards-compliant?
> >
> > Perhaps they should be split from the system-related parts by moving
> > them into two distinct .c files.
> >
> > >> - several files lack inclusion of libgen.h, causing complaints like
> > >> these for dirname. All files that call dirname must #include <libgen.h>.
> > >
> > >> coreutils/rmdir.c: In function 'rmdir_main':
> > >> coreutils/rmdir.c:72: warning: implicit declaration of function 'dirname'
> > >> coreutils/rmdir.c:72: warning: assignment makes pointer from integer
> > >> without a cast
> > >
> > > Well, "man dirname" says:
> > >
> > > With glibc, one gets the POSIX version of basename() when <libgen.h> is
> > > included, and the GNU version otherwise.
> > >
> > > which means that include <libgen.h> is not such a simple matter.
> >
> > It is very simple, #include <libgen.h>.
> >
> > The application must be prepared for basename()/dirname() modifying
> > their argument anyways because you need to support systems where
> > basename() trashes your data and you don't have the GNU version.
> Hi,
> " There are two different versions of basename() - the POSIX version described above, and the
> GNU version, which one gets after
>
> #define _GNU_SOURCE
> #include <string.h>
>
> The GNU version never modifies its argument, and returns the empty string when path has a
> trailing slash, and in particular also when it is "/". __There is no GNU version of dirname()__.
>
> With glibc, one gets the POSIX version of basename() when <libgen.h> is included, and the GNU
> version otherwise."
>
> So it seems to me that:
> 1) for basename() you can include <libgen.h> or __GNU_SOURCE and <string.h>
> but we do not define __GNU_SOURCE so it seems we prefer POSIX version.
> 2) in libbb get_last_path_component.c we have:
> const char* FAST_FUNC bb_basename(const char *name)
> char* FAST_FUNC bb_get_last_path_component_nostrip(const char *path)
> char* FAST_FUNC bb_get_last_path_component_strip(char *path)
> that are bb's own implementations of basename. It should be investigated
> if they could be used instead of plain basename to avoid the inclusion of <libgen.h>
> 3) for dirname() you can only include <libgen.h> as
> __There is no GNU version of dirname()__
>
> I see only 2 solutions:
> 1) the easy include libgen.h in libbb.h (if the relevant applets are turned on)
> 2) the other use bb_basename (eventually fixed to fit needs)
> and add bb_dirname
or see if char* FAST_FUNC bb_get_last_path_component_nostrip(const char *path)
char* FAST_FUNC bb_get_last_path_component_strip(char *path)
fit needs (and eventually extend)
> and dump libgen.h
> Ciao,
> Tito
>
> >
> > > libbb.h says:
> > >
> > > /* This is declared here rather than #including <libgen.h> in order to avoid
> > > * confusing the two versions of basename. See the dirname/basename man page
> > > * for details. */
> > > #if !defined __FreeBSD__
> > > char *dirname(char *path);
> > > #endif
> > >
> > > Should we simply remove "#if !defined __FreeBSD_"?
> >
> > No, because FreeBSD uses a different prototype and you do not want to
> > deprive the compiler of related optimization possibilities:
> >
> > FreeBSD's dirname() doesn't tamper with its argument string and declares
> > a const char * restricted argument.
> >
> > Bottom line: you should #include <libgen.h>.
> >
snip
Ciao,
Tito
More information about the busybox
mailing list