Watcom c/c++ compiler on qnx4 doesn't support 64 bit int, and openssh ./configure refuses to compile sftp and sftp-server for me. I see 32 bit int support in the TODO list and am wondering when it will be supported. BTW, when I use the ssh from ssh.com, sftp works fine in qnx4. Isn't openssh derived from ssh.com, how come their ssh supports sftp but openssh doesn't for 32bit int? Thanks!
openssh is not derived from ssh.com-2.x or 3.x. but adding support for 32bit int is not hard. you can attach patches to this bug.
> but adding support for 32bit int is not hard. "adding"? somehow I got the impression that 32 bit int was in the openssh at some point in the history, but then got dropped. Anyway, it would be greatly appreciated if someone can provide a 32bit int patch so that I can test it. It seems SCO also suffers from the same problem (per TODO file).
At one point it was a high/low 32bit integer structure, but after the code was looked at it was realized that 64bit integers would make it cleaner. I looked at supporting platforms without 64bit using the old way, but I realized how ugly it would be. It would have been a nightmare to audit and a nightmare to merge changes to. Below is the event that removed 32bit integers and combined them into a 64bit. If you can show me a clean way of implementing 32bit without destorying the reability of the code I'd be extremely happy. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sftp-server.c.diff? r1=1.9&r2=1.10 Granted sftp client I believe never did have 32bit support.
I am not an expert in programming, but is it possible to create our own data types, and typedef them as our Int32, Int64 rather than using the OS one? That should solve both sftp and sftp-server problem?
Created attachment 105 [details] i thought about something like this
That would work, but the question is how much auditing would have to be done to ensure that one does not wrap the 32bit int since the code by default assumes 64bit.
Created attachment 106 [details] I also have to modify sftp-client.c for Watcom to compile or else it complains about invalid type.
As a side note: on SCO, 64bit is not a problem if you use gcc as a compiler, which has "long long" as a valid 64bit type on i386. To liug@mama.indstate.edu: just typedef'ing something that the compiler cannot generate valid 64bit code for won't help.
Hi Markus, I tried your patch. sftp (client) seems to work fine. sftp-server seems to have problems: I can sftp connect into the box, but I can get/put files. "ls -l" gives the error "Couldn't stat remote file: No such file or directory" and "ls" or "dir" will disconnect me immediately. Any ideas?
here is the sftp -vvv output: sftp> dir debug3: Sending SSH2_FXP_READDIR I:3 debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0 debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: close_write debug1: channel 0: output drain -> closed debug1: channel 0: rcvd close debug1: channel 0: close_read debug1: channel 0: input open -> closed debug3: channel 0: will not send data after close debug1: channel 0: almost dead debug1: channel 0: gc: notify user debug1: channel 0: gc: user detached debug1: channel 0: send close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: client-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1) debug3: channel_close_fds: channel 0: r -1 w -1 e 6 debug1: fd 0 clearing O_NONBLOCK debug2: fd 1 is not O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 20.9 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status -1 Connection closed
Should this bug be closed now that platforms without a 64 bit int are not supported? 20030320 - (bal) The days of lack of int64_t support are over. Sorry kids.
Mass change of RESOLVED bugs to CLOSED