it'd be better IMO,
as it would avoid relying on implementation-specific behaviors.
I'm aware they are not standard, but they seem to be pretty common,
and without them, one cannot even extract the gcc or clang source code.
--
willy
Willy Gfn wrote:
> Michael Forney wrote:
> > On 12/24/16, Cág wrote:
> > > Markus Wichmann wrote:
> > >
> > >> Well, that looks like it might be problematic, doesn't it? Especially
> > >> when you find out, that the size of h->name ther
Michael Forney wrote:
> On 12/24/16, Cág wrote:
> > Markus Wichmann wrote:
> >
> >> Well, that looks like it might be problematic, doesn't it? Especially
> >> when you find out, that the size of h->name there is 100 bytes. path
> >> contains, of course, the entire file path relative to the startin
Michael Forney wrote:
> On 2/2/17, willy wrote:
> > At this point, I'm not sure where to look at, or even if the bug
> > really lies in tar and not in bzip2.
> > I checked the size (both octal and converted) and the value is good. So
> > I'm not sure why the
but depending on the archives, it can occur on the second entry or in
the middle, there's no rule.
I hope my example are clear to define what the issue is. Would anyone
have an idea?
--
willy
diff --git a/tar.c b/tar.c
index 71719b0..49ecfae 100644
--- a/tar.c
+++ b/tar.c
@@ -351,8 +351,10
