> It is not possible to fix it. At least without the knowledge that it is
> compiled with a c++ compiler.
Aren't there CPP symbols (__cplusplus comes to mind) defined only when a c++
compiler is running that could be used to detect that a c++ compiler is
indeed running?
wt
--
Warren Turkal, Re
On Wed, May 24, 2006 at 01:55:00PM -0600, Warren Turkal wrote:
> > It is not possible to fix it. At least without the knowledge that it is
> > compiled with a c++ compiler.
> Aren't there CPP symbols (__cplusplus comes to mind) defined only when a c++
> compiler is running that could be used to de
On Wed, May 24, 2006 at 08:49:36PM +0200, Bastian Blank wrote:
> severity 368720 grave
> thanks
>
> On Wed, May 24, 2006 at 01:23:52PM -0500, John Goerzen wrote:
> > Is your position that even with the correct __GNUC__ test, that there is
> > still a problem with foreach_alist?
>
> It is undefine
severity 368720 grave
thanks
On Wed, May 24, 2006 at 01:23:52PM -0500, John Goerzen wrote:
> Is your position that even with the correct __GNUC__ test, that there is
> still a problem with foreach_alist?
It is undefined behaviour but works[tm] with gcc.
> If
Processing commands for [EMAIL PROTECTED]:
> severity 368720 grave
Bug#368720: bacula - alist breaks with undefined behaviour
Severity set to `grave' from `grave'
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking syst
severity 368720 important
forwarded 368720 [EMAIL PROTECTED]
merge 367424 368720
thanks
As far as I can tell, this is a dup of 367424. As you can see there, we
already narrowed down to the faulty configure test and I already
suggested __GNUC__.
Is your position that even with the correct __GNUC_
Package: bacula-sd
Version: 1.38.9-9
Severity: grave
bacula-sd segfaults in several locations with null pointer access (for
example #367424) if built with -O2.
I just took a look into src/stored/reserve.c at line 550, where I found
another occurance. At this point it uses foreach_alist, a macro w
7 matches
Mail list logo
