fsp_open_session() has a bug where it does not set errno if getaddrinfo fails.
Before the bug 1013 fix, this caused an assertion failure.
After the bug 1013 fix, this caused a "Success" error message.
Now it instead causes "FSP server not found".
Replace almost all uses of enum connection_state with struct
connection_status. This removes the assumption that errno values used
by the system are between 0 and 100000. The GNU Hurd uses values like
ENOENT = 0x40000002 and EMIG_SERVER_DIED = -308.
This commit is derived from my attachments 450 and 467 to bug 1013.
*fresult pointed to nowhere. On FreeBSD *fresult == NULL
and directories weren't displayed.
Check also if safe_write writes all data.
(cherry picked from commit 06bcc48487)
On AMD64 apparently, off_t is long but ELinks detected SIZEOF_OFF_T == 8
and defined OFF_T_FORMAT as "lld", which expects long long and so causes
GCC to warn about a mismatching format specifier. Because --enable-debug
adds -Werror to $CFLAGS, this warning breaks the build. When both
SIZEOF_LONG and SIZEOF_LONG_LONG are 8, ELinks cannot know which type
it should use.
To fix this, do not attempt to find a format specifier for off_t itself.
Instead cast all printed off_t values to a new typedef off_print_T that
is large enough, and replace OFF_T_FORMAT with OFF_PRINT_FORMAT which
is suitable for off_print_T altough not necessarily for off_t. ELinks
already had a similar scheme with time_print_T and TIME_PRINT_FORMAT.
FSP v2 uses 32-bit file offsets in its UDP packets and cannot get past
4 GiB. ELinks should however try not to wrap the numbers to negative
at 2 GiB, if it is built with large file support.
Cast the parameters of the function instead. The C standard does not
guarantee that a function can be properly called via a pointer of a
different type.
Empty files were causing 'read from socket' errors.
[ This is half of commit eef1c17dce
from the witekfl branch. The SMB half is in commit
916b5cf545. --KON ]
This ensures that the 'writer' process will remove itself when the
main ELinks process for some reason decides to shutdown the connection.
Before the 'writer' process would complete it's task taking up unnecessary
system resources.
This is mostly an issue when fetching big files. Therefore only file
fetching is fixed. FIXME added about also checking return codes for write
associated with directory listing.
Reported-by: zas