Why return a string that the caller doesn't care about and means nothing as opposed to returning a more simple undef value?

Excuse me? this string is what the caller requests by calling the function create_snapshot_name() which was written for this very purpose. The calling line is

  my $snap_name = create_snapshot_name();
[download]

in function take_new_snapshot() and the name of the variable in which this return value is stored also indicates that a string is expected as return value from that function.

I am simply saying that I prefer having explicit return values.

I had those discussions before, and I stick to the perl way: a subroutine returns, absent early returns, the result of the last computed expression, with or without explicit return statement. Were I to work with you having a coding policy in place which requires always stating explicit returns, I would do likewise, otherwise not.

Edit:

Well, depends. If I was to concoct a function dependent on context for its return value, I'd use explicit returns, sometimes setting $@ if something failed. But it really boils down to two possibilities for return values as a subroutine:

1. I know what I have, and this is what you get, and might honour your context.
2. take that bastard, you get what you asked for

But then, for case 1, I would have to raise an exception if I have a list and am called in scalar context. Or should I? maybe they want just the number of elements? and vice versa.

wrong

I've never checked the return value of sprintf.

then stop talking and read sprintf

I disagree about printf() errors.
With normal file operations, what I said is true. It is almost impossible for a print or printf to "fail" once a local Hard Disk file handle is open. One way would be "File system full", but in that case, a fatal exception is thrown - the calling program won't see that.

I did make a mistake in interpreting the exact situation. I would have written: return sprintf "..." because I favor explicit return statements.

In Perl, if printf() fails, a fatal error will be thrown long before it returns to the caller.

I disagree about printf() errors. With normal file operations, what I said is true. It is almost impossible for a print or printf to "fail" once a local Hard Disk file handle is open. One way would be "File system full", but in that case, a fatal exception is thrown - the calling program won't see that.

Test before posting. Confidently making incorrect statements doesn't help anyone.

#!/usr/bin/env perl
use warnings;
use strict;

my $file = $^O eq 'MSWin32' ? "P:\\foo" : '/tmp/foo/bar';
open my $fh, '>', $file or die "$file: $!";
my $data = "\0" x 2_000_000;
print "Writing ", length $data, " bytes to $file\n";
printf $fh "%s", $data or warn "printf: $!";
close $fh or warn "close: $!";
print "Still not fatal\n";

__END__

Windows:

Install https://www.ltr-data.se/opencode.html/#ImDisk
As Administrator:
> imdisk -a -t vm -m P: -s 1M -p "/fs:fat /q /y"
> perl write.pl
Writing 2000000 bytes to P:\foo
printf: No space left on device at write.pl line 9.
close: No space left on device at write.pl line 10.
Still not fatal
> imdisk -D -m P:

Linux:

$ mkdir -vp /tmp/foo
$ sudo mount -t tmpfs -o size=1M,uid=`id -u` tmpfs /tmp/foo
$ perl write.pl
Writing 2000000 bytes to /tmp/foo/bar
printf: No space left on device at write.pl line 9.
close: No space left on device at write.pl line 10.
Still not fatal
$ sudo umount /tmp/foo
[download]

I disagree about printf() errors.

It was all about sprintf, not printf. Different cases and conditions (memory exhausted vs. disk full etc, NFS conditions and such).

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'