http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From markus at openbsd.org 2002-05-27 17:09 ------- 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 00:58 -------> 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). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From mouring at eviladmin.org 2002-05-28 02:57 ------- 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 04:00 ------- 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? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From markus at openbsd.org 2002-05-28 05:08 ------- Created an attachment (id=105) i thought about something like this ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From mouring at eviladmin.org 2002-05-28 06:05 ------- 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 06:41 ------- Created an attachment (id=106) I also have to modify sftp-client.c for Watcom to compile or else it complains about invalid type. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From gert at greenie.muc.de 2002-05-28 07:28 ------- 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 at mama.indstate.edu: just typedef'ing something that the compiler cannot generate valid 64bit code for won't help. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 13:02 ------- 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? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=257 ------- Additional Comments From liug at mama.indstate.edu 2002-05-28 14:41 ------- 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 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.