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.
The previous check (integer > (off_t) integer * 10) did not detect all
overflows. Examples with 32-bit off_t:
integer = 0x1C71C71D (0x100000000/9 rounded up);
integer * 10 = 0x11C71C722, wraps to 0x1C71C722 which is > integer.
integer = 0x73333333;
integer * 10 = 0x47FFFFFFE, wraps to 0x7FFFFFFE which is > integer.
Examples with 64-bit off_t:
integer = 0x1C71C71C71C71C72 (0x10000000000000000/9 rounded up);
integer * 10 = 0x11C71C71C71C71C74, wraps to 0x1C71C71C71C71C74
which is > integer.
integer = 0x7333333333333333;
integer * 10 = 0x47FFFFFFFFFFFFFFE, wraps to 0x7FFFFFFFFFFFFFFE
which is > integer.
It is unclear to me what effect an undetected overflow would actually
have from the user's viewpoint, so I'm not adding a NEWS entry.
(cherry picked from commit a25fd18e56)
This change avoids linker warnings when building with Debian tcc
0.9.23-4 + patch from Debian bug 418360:
[LD] src/protocol/bittorrent/lib.o
bittorrent.o: 'BITTORRENT_NULL_ID' defined twice
common.o: 'BITTORRENT_NULL_ID' defined twice
connection.o: 'BITTORRENT_NULL_ID' defined twice
dialogs.o: 'BITTORRENT_NULL_ID' defined twice
peerconnect.o: 'BITTORRENT_NULL_ID' defined twice
peerwire.o: 'BITTORRENT_NULL_ID' defined twice
piececache.o: 'BITTORRENT_NULL_ID' defined twice
tracker.o: 'BITTORRENT_NULL_ID' defined twice
Add a boolean protocol flag which says whether "//" in the path
part of an URI can be safely substituted with "/". Be conservative
and enable it only for file://, ftp:// and nntp[s]://. Other
can be turned on later, if needed.
Generalizes the fix from 58b3b1e752.
This reverts commit 4f0aaa166e
and insert check for the "//" -> "/" change only to occur for
file:// URIs. This fixes the recent reports on broken handling
of relative file URIs starting with "..".
<http://www.wikipedia.org/w/wiki.phtml?search=sue%20lawley>
incorrectly redirects to
<http://en.wikipedia.org/w/wiki.phtml?search=sue%2520lawley>
which searches for "sue%20lawley" rather than "sue lawley".
By using en.wikipedia.org directly, we avoid the server bug.
Prompted by an elinks-users post on 2007-07-27.
I asked on #wikimedia-tech, and www.wikipedia.org does always
redirect to en.wikipedia.org; it does not guess any other
language based on headers or IP addresses or such. Also, the
redirection exists only for compatibility, and skipping it
avoids a few roundtrips to the server. So this change is good
even if the server is eventually fixed.
This patch changes normalize_uri() to no replace "//" with "/" in URIs. This
fixed this bug but will also lead to possibility that duplicate entries can
exist in ELinks' cache. ELinks might be able to detect in another way by
hashing the content or something.
[ From attachment 310 of bug 744. --KON ]
And reorder the characters in the string given to strcspn(), to match
their expected order in the URI. This is also how strcspn() is called
elsewhere in uri.c.
Use it for the actual I/O only. Previously, defining CONFIG_UTF8 and
enabling UTF-8 used to force many strings to the UTF-8 charset
regardless of the terminal charset option. Now, those strings always
follow the terminal charset. This fixes bug 914 which was caused
because _() returned strings in the terminal charset and functions
then assumed they were in UTF-8. This reduction in the effects of
UTF-8 I/O may also simplify future testing.
