Your message dated Sun, 7 Feb 2016 20:26:22 -0500 with message-id <[email protected]> and subject line Re: Bug#812318: libsvn-perl: SVN::Core::dirent_canonicalize segfaults on undef has caused the Debian Bug report #812318, regarding libsvn-perl: SVN::Core::dirent_canonicalize segfaults on undef to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 812318: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812318 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libsvn-perl Version: 1.9.3-2 Severity: important $ perl -MSVN::Core -e 'SVN::Core::dirent_canonicalize(undef)' zsh: segmentation fault (core dumped) perl -MSVN::Core -e 'SVN::Core::dirent_canonicalize(undef)' In case of undef, I suppose that the Perl module should pass the empty string to the library (for which there are no errors), or return some other kind of error. I have not tried other kinds of arguments, but in any case, the module should make sure that a valid string is passed to the library. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libsvn-perl depends on: ii libapr1 1.5.2-3 ii libc6 2.21-6 ii libsvn1 1.9.3-2 ii perl 5.22.1-4 ii perl-base [perlapi-5.22.1] 5.22.1-4 libsvn-perl recommends no packages. libsvn-perl suggests no packages. -- no debconf information
--- End Message ---
--- Begin Message ---On Sun, Jan 24, 2016 at 07:24:54AM +0100, Vincent Lefevre wrote: > Control: reopen -1 > > On 2016-01-23 21:57:29 -0500, James McCoy wrote: > > On Fri, Jan 22, 2016 at 11:04:04AM +0100, Vincent Lefevre wrote: > > > $ perl -MSVN::Core -e 'SVN::Core::dirent_canonicalize(undef)' > > > zsh: segmentation fault (core dumped) perl -MSVN::Core -e > > > 'SVN::Core::dirent_canonicalize(undef)' > > > > > > In case of undef, I suppose that the Perl module should pass the empty > > > string to the library (for which there are no errors), or return some > > > other kind of error. > > > > As stated previously, and described on the Subversion dev list, the SWIG > > bindings are very thin wrappers around the C library. Calling > > svn_dirent_canonicalize with a NULL dirent will result in the same > > behavior. > > There's no such thing as a NULL dirent. You're right. That was poor wording on my part. Calling svn_dirent_canonicalize with a NULL char* describing the path of the dirent will result in the same behavior. > In a string context, undef is the empty string. No, an empty string is an empty string. undef is the lack of an argument. The same thing happens if you call a function in Perl without any arguments. $ perl sub foo { my ($path) = @_; print '$path is: ', defined($path) ? $path : "undef", "\n"; } foo; foo(undef); foo(''); $path is: undef $path is: undef $path is: This is also why Perl warns when you use undef in string context. $ perl use warnings; print undef; Use of uninitialized value in print at - line 2. > > > I have not tried other kinds of arguments, but in any case, the > > > module should make sure that a valid string is passed to the > > > library. > > > > *You* are calling the library, so you need to ensure you give it a valid > > value. undef (or the NULL pointer SWIG treats it as for a string > > argument) isn't a valid string. > > No, undef must not be the null pointer. Yes, it should. The lack of an argument when a pointer argument is expected is exactly what NULL is on the C side and undef on the Perl side. > This makes no sense at all! > With a string argument, undef must be the empty string. No, it mustn't. That isn't even the case in Perl, so I don't see why it should convert to C. > > To get the behavior you want, the suggestion upstream was that > > higher-level libraries would need to be developed. That's not going to > > happen within Debian, so I'm closing the bug. > > No need for a high-level library. This is just basic type analysis. Yes, and type analysis shows that undef is not a string. If you want an empty string, then use it. You type it as '' not undef. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <[email protected]>
--- End Message ---
