[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: signal 6 caught by ldap_init



On Thursday 28 February 2008 12:03:58 Pierangelo Masarati wrote:
> Buchan Milne wrote:
> > On Tuesday 26 February 2008 21:07:16 Pierangelo Masarati wrote:
> >> Olivier Germain wrote:
> >>> Good moring List,
> >>>
> >>> I am using the following openldap release openldap/2.3.36_64.
> >>> I am experiencing a signal 6 in the ldap_init during coonection to my
> >>> LDAP server. I would like to know if someone of you has already got
> >>> this problem. If yes could it be possible to know how this has been
> >>> solved new release of openldap?
> >>
> >> See <http://www.openldap.org/its?findid=4168> (read the whole story).
> >
> > A compile-time warning or error would really help everyone ...
>
> It's already there: with gcc, without any special flag, you get a
> "assignment makes pointer from integer without a cast" if you use
> ldap_init(3) and assign the result to a LDAP*; with -Wall you also get
> "warning: implicit declaration of function `ldap_init'".  Of course,
> then, developers should take care of compile warnings...  I don't know
> what we could do more, other than removing those functions from libldap.
>

Use function attributes to deprecate the function, which I think would result 
in a compilation warning with a suitable warning? If it's portable.

http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Function-Attributes.html#Function-Attributes

I had found some more docs on how to use it (on a KDE site) to result in an 
error instead of a warning, but I can't find it now.

I was caught by this ... as I had very little time to upgrade from 2.2 to 2.3 
on Mandriva (before version freeze), and rebuild all packages, and test 
them ... and this didn't turn out well for some software with optional 
run-time LDAP support (e.g. samba) on x86_64 (where x86 worked fine ...) as I 
had limited access to x86_64 hardware (e.g. no root access). An error would 
have allowed me to workaround it trivially, instead of waiting for 
compile/upload/wait for mirror/test cycles.

If it's known that software using the deprecated functions can segfault, IMHO 
it would be much better if (with typical default compiler options) 
compilation failed, than succeeded.

Regards,
Buchan