gcc 3.5 fixes
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Bartlomiej Zolnierkiewicz <[email protected]> wrote in message news:<[email protected]>...
Quoted 1 line
Can't we just remove these variables?
...
Quoted 3 lines
Review
Quoted 3 lines
(quoted diff) +1
-1-static const char inflate_copyright[] = +static const char inflate_copyright[] __attribute_used__ = " inflate 1.1.3 Copyright 1995-1998 Mark Adler ";
It's there for a reason -- to have a copyright notice in the executable. I would prefer it if it were not removed. Thanks.
mark
I'm not a lawyer, but I don't see why you'd want the copyright notice in the executable:
* It's probably the source text that you're intending to copyright, not the binary executable bits.
* If you look, I believe you will find that there are almost no other copyright strings in the vmlinux executable.
* By what right can I copy or distribute a kernel built with this string in it? The comments in zlib.h let us use the source, but I don't see any authorization to use the resulting executable bits on which this static copyright string seems to assert copyright.
Signature · 3 lines
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373Quoted 2 lines · Paul Jackson
I'm not a lawyer, but I don't see why you'd want the copyright notice in the executable:
It's not about the copyright. I like the string kept in the object code so that I and others can find out where the code is used and what version is in use. This in fact turned out to be useful when a security vulnerability was found in versions 1.1.3 and earlier and a script could search for executables with the offending code.
mark
Quoted 1 line · Mark
It's not about the copyright.
So in theory, then, one could change the string:
inflate 1.1.3 Copyright 1995-1998 Mark Adler
to have instead the form:
inflate 1.1.3 1995-1998 Mark Adler
Or ... one could just ignore my considerations, since I really am not a lawyer ;).
Signature · 3 lines
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373Quoted 7 lines · Mark Adler
It's not about the copyright. I like the string kept in the object code so that I and others can find out where the code is used and what version is in use. This in fact turned out to be useful when a security vulnerability was found in versions 1.1.3 and earlier and a script could search for executables with the offending code.
<-- snip -->
Quoted 1 line
" inflate 1.1.3 Copyright 1995-1998 Mark Adler "
Did I miss something or are you saying that the version in the kernel has a security vulnerability?
Jesse
Signature · 1 line
Jesse Stockall <[email protected]>
Quoted 2 lines · Jesse Stockall
Did I miss something or are you saying that the version in the kernel has a security vulnerability?
If the kernel has 1.1.3, then yes. You can get 1.1.4 here, which remedies that vulnerability:
http://www.gzip.org/zlib/zlib-1.1.4.tar.gz
mark
Quoted 6 lines · Mark Adler
Quoted 2 lines · Jesse Stockall
Did I miss something or are you saying that the version in the kernel has a security vulnerability?
If the kernel has 1.1.3, then yes. You can get 1.1.4 here, which remedies that vulnerability:
I seem to recall that vulnerability was fixed in place, without upgrading to 1.1.4.
Signature · 2 lines
http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
Quoted 10 lines · bert hubert
Quoted 6 lines · Mark Adler
Quoted 2 lines · Jesse Stockall
Did I miss something or are you saying that the version in the kernel has a security vulnerability?
If the kernel has 1.1.3, then yes. You can get 1.1.4 here, which remedies that vulnerability:
I seem to recall that vulnerability was fixed in place, without upgrading to 1.1.4.
Indeed, but it's probably time we upgraded to 1.2.
Signature · 1 line
dwmw2
Quoted 1 line · David Woodhouse
Indeed, but it's probably time we upgraded to 1.2.
If you are using 1.1.4 or a properly patched 1.1.3, then that's good enough for now. I recommend waiting a little while for 1.2.x to mature.
mark