#include hallo.h
* Bastian Blank [Fri, Jul 18 2008, 03:37:39PM]:
But if you don't check it and rely on the function to do what it has
to do (i.e. write the result into the buffer in the argument) then you
silently get a buffer with undefined data back (most likely
unchanged).
No. You
Please explain. In C++ there is no implicit conversion between int and
char *.
Exactly. So if you check the return value then the compiler will fail (like in
the test case above) and you are lucky to notice the problem.
But if you don't check it and rely on the function to do what it has to
#include hallo.h
* Albert Cahalan [Sun, Aug 13 2006, 01:22:44AM]:
I forgot to point out:
Once this is fixed, all powerpc packages need
to be rebuilt ASAP.
Would you also care to explain why? What exactly does not having this
options working make the compilation products unreleaseable?
Package: g++-3.4
Version: 3.4.3-4
Severity: normal
Hello,
have trouble compiling a software package (MCA, mca2.sf.net with local
extensions) using Debian's g++. There was no such problem compiling
on Gentoo (g++ 3.3.3), so I report it here as Debian specific issue.
The problem appears with the
Forgotten copy; the file is stored on
http://people.debian.org/~blade/misc/sshfs-breaks-with-g++-3.3.tgz
- Forwarded message from Eduard Bloch [EMAIL PROTECTED] -
Date: Wed, 22 Oct 2003 11:28:47 +0200
From: Eduard Bloch [EMAIL PROTECTED]
Subject: Re: Bug#194345: FTB the lufs package
severity 194345 grave
tag 194345 + sid
thanks
It became worse. The last version cannot build my lufs package because
of the astronomical memory usage. Even 2GB of virtual memory isn't
enough.
MfG,
Eduard.
--
Letzte Worte eines Turmspringers:
Heute ist das Wasser aber klar!
#include hallo.h
* Allan Sandfeld Jensen [Mon, Aug 19 2002, 02:58:06PM]:
libraries are placed under /usr/lib/g++2.95 and the new ones under
/usr/lib/g++3.1. The defaults are symbolic linked from /usr/lib. We can
either hack ld.so to search the correct path (using some g++ calling cards)
or
#include hallo.h
* Matthew Wilcox [Fri, Aug 16 2002, 02:51:34PM]:
Because upstream chooses the soname to match their API. If we change
Do we know this?
the soname then we render ourselves binary-incompatible with other
distros and vendor-supplied binaries. This is important because
Moin Matthias!
Matthias Klose schrieb am Thursday, den 30. May 2002:
allegro now is at version 4.0. Please could you try to reproduce the
behaviour with this version? Please could you try to recompile with
gcc-3.1 (unstable)?
Works with gcc-3.1. I am impressed, all bugs I have found in
Package: gcc-3.0
Version: 1:3.0-4
Severity: normal
S.s. You can take allegro3937 from incoming.d.o. or from ftp-mirrors
when it is installed. gcc-3.0 can compile binaries and link to the
existing liballegro*.so without any problems, but when compiling the
library itself, the result is broken. Any
10 matches
Mail list logo
