Subject: Re: libssh2 master ed526a0 Add libssh2_sftp_statvfs() and libssh2_sftp_fstatvfs()

Re: libssh2 master ed526a0 Add libssh2_sftp_statvfs() and libssh2_sftp_fstatvfs()

From: Daniel Stenberg <>
Date: Mon, 24 May 2010 16:51:34 +0200 (CEST)

On Mon, 24 May 2010, Peter Stuge wrote:

>> and I'm working hard towards removing the extensive use of macros instead
>> of real functions in our API.
> Yes, the macros kinda suck, but would a function doing the same thing be
> much better?

Yes. But when it comes to just doing a strlen() I don't see why we need to
"hide" it at all.

>> New functions and new things we add do not have to make the pains worse. We
>> should add sensible functions without "_ex" and that we use directly
>> without macros. Please.
> Sure! Please suggest an improved API for these functions?

Cut off _ex, remove the macro. That's better in my eys.

And I would much rather support -1 as a magic length to tell libssh2 to run a
strlen() on the given data to figure out the length.

> Although not likely to be so common SSH does support character sets with 0
> bytes in them, and even though libssh2 is a C API I hope you agree that it's
> not sensible to not be 8-bit clean.

Yes and no.

The eight bit clean reason would be that the file names aren't necessarily
encoded in anything 8bit. (The use of a true binary zero in a file name is a
use case I could ignore if that was the only reason for a zero byte in the
file name). But we have no way in the current libssh2 to negotiate file name
encoding so there's no standard way to use anything exotic. SFTPv6 (we use v3
but this is the closest spec I know that says anything about encoding) says
file names are even supposed to be UTF-8 by default.

UTF-8 would make a lot of sense, and UTF-8 file names can be used zero-
terminated in C code and then we don't actually _need_ a strlen.

> (I found some other, perhaps even more important, issues throughout the SFTP
> code too, it basically doesn't handle short writes correctly in very many
> places.) Joey half-promised to look into it. :)

Yes, and even worse: it doesn't deal with short reads very good if the server
sends data that is shorter than what libssh2 expects it to send. This
particular flaw is prevailing in lots of spots in the code still.

Received on 2010-05-24