Remove the stracpy(ofile) call that could never be executed.
This removes the need to handle errors from that call,
and makes it clear that lun_hop->file need not be separately freed
if an error occurs in lookup_unique_name().
With GCC 4.3.1 on i686, this changes the sizes of sections as follows:
section before after change
.text 682428 682492 +64
.rodata 212668 216352 +3684
.data 58092 54444 -3648
.debug_info 1482388 1482472 +84
.debug_abbrev 153714 153723 +9
.debug_line 272299 272319 +20
.debug_loc 540394 540372 -22
.debug_ranges 113784 113792 +8
Total 3917695 3917894 +199
The surprising .text change comes from src/config/dialogs.o.
Some of that is in get_keybinding_text(), where GCC changes the
order of basic blocks and apparently misses some optimizations.
I added this bug last night. continue_download_do() passed the
file descriptor to transform_codw_to_cmdw(), which saved it, but
continue_download_do() then closed it.
In common_download(), move session.download_uri to the new member
cmdw_hop.download_uri, which common_download_do() then reads. This
shields the download request against possible session.download_uri
changes made for other downloads. And transform_codw_to_cmdw() no
longer needs to touch session.download_uri at all, solving a FIXME.
Commit ff136e5116 on 2006-07-16 made
lun_resume() check if cdf_hop->data points to struct codw_hop,
and transform that to struct cmdw_hop if so. Move the transform
into a separate function called from continue_download_do().
This way, the structures used with create_download_file() no longer
need to begin with int magic.
To reproduce:
- Configure with --enable-debug.
- Go to http://elinks.cz/
- Set the cursor on the "About" link and press d to download,
- ELinks asks where to save the file. Cancel that with Esc.
This leaves session.download_uri != NULL.
- Go to /etc/passwd
- ELinks asks what to do with the file. Choose to download.
- ELinks asks where to save the file. Type the name of a new file
and press Enter.
- Again go to /etc/passwd
- ELinks asks what to do with the file. Choose to download.
- ELinks asks where to save the file. Type the same name as before
and press Enter.
- ELinks asks whether to resume or overwrite. Choose to resume.
This changes session.download_uri and leaks the original URI.
- Quit ELinks. It reports memory leaks:
0x88936d8:28 @ alloc'd at /home/Kalle/src/elinks-0.12/src/util/hash.c:89
0x88dac00:95 @ alloc'd at /home/Kalle/src/elinks-0.12/src/protocol/uri.c:1551
0x88c33a8:4104 @ alloc'd at /home/Kalle/src/elinks-0.12/src/util/hash.c:41
This commit fixes the leak, but it's still a bug that lun_resume() can
replace the session.download_uri that will be used by another pending
download. In particular, this might happen if the user first presses
d to download, and then while ELinks is asking for the file name, a
web script changes window.location to a different URI and that causes
ELinks to ask what to do with the file. So I'm leaving the FIXME
comment in for now.
If init_file_download() succeeds (returning non-NULL), it saves the
file descriptor to file_download->handle, whence abort_download() will
close it. However, if init_file_download() fails, the caller is
responsible of closing the file, something common_download_do() and
continue_download_do() failed to do. There was no problem with
bittorrent_download() because that uses -1 as the fd.
If init_file_download() succeeds (returning non-NULL), it saves the
file-name pointer to file_download->file, whence abort_download() will
free it. However, if init_file_download() fails, the caller is
responsible of freeing the name. bittorrent_download() already did so
but common_download_do() and continue_download_do() didn't.
Remove enum main_action_offset, enum edit_action_offset, and enum
menu_action_offset. It seems the original plan (in commit
174eabf1a448d3f084a318aab77805828f35c42e on 2005-05-16) was to include
the action flags in the action IDs, perhaps with something like:
ACT_##map##_##action = ACT_##map##_OFFSET_##action | flags
However, this OR operation was never implemented; each ACT_*_*
constant had the same value as the corresponding ACT_*_OFFSET_*,
and the code that looked for flags in action IDs found only zeroes.
Then on 2005-06-10, a separate action.flags member was added, and
the flag checks were corrected to read that instead. So, it seems
safe to say that the original plan has been discarded and the offset
enumerations won't be needed.
Doxygen isn't too good at documenting the parameters of a callback
within the documentation of a parameter that points to the callback.
A typedef provides a better place to document the parameters.
If the user chose File -> Save formatted document and typed the name
of an existing file, ELinks offered to resume downloading the file.
There are a few problems with that:
* save_formatted_finish does not actually support resuming. It would
instead overwrite the beginning of the file and not truncate it.
* When save_formatted calls create_download_file, cdf_hop->data
ends up pointing to struct document. If the user then chooses to
resume, lun_resume would read *(int *)cdf_hop->data, hoping to
get cmdw_hop.magic or codw_hop.magic. struct document does not
begin with any such magic value.
* Because ELinks already has the formatted document in memory,
resuming saves neither time nor I/O.
So don't show the "Resume download of the original file" button in
this situation.
After the recent ecmascript_get_interpreter change, I got an assertion
failure in render_document, which calls ecmascript_reset_state and
then asserts that it has set vs->ecmascript != NULL.
ecmascript_reset_state cannot guarantee that because there might not
even be enough free memory for mem_calloc(1, sizeof(struct
ecmascript_interpreter). So, replace the assertion in render_document
with error handling, and likewise in call_onsubmit_and_submit.
This should fix a crash in:
at /home/Kalle/src/elinks-0.12/src/ecmascript/spidermonkey.c:251
at /home/Kalle/src/elinks-0.12/src/ecmascript/ecmascript.c:104
at /home/Kalle/src/elinks-0.12/src/viewer/text/vs.c:64
It seems that spidermonkey_get_interpreter failed and returned NULL to
ecmascript_get_interpreter, which did not check the return value and
behaved as if the ECMAScript interpreter had been properly initialized.
This caused destroy_vs to call ecmascript_put_interpreter, but
backend_data which should have been a JSContext * was NULL, causing
a crash in SpiderMonkey.
An alternative fix might be to make spidermonkey_put_interpreter skip
the JS_DestroyContext call if ctx is NULL. However, I think it is
better to make sure ecmascript_get_interpreter returns NULL if
spidermonkey_get_interpreter fails, so that vs->ecmascript is left
NULL and there's no chance that some other code might try to
dereference the (JSContext *) NULL.
Perhaps because of bug 981, if one opened hundreds of pages with
elinks --remote openURL(...), then ELinks 0.11.4 could crash with a
SIGSEGV in JS_InitClass called from spidermonkey_get_interpreter.
SpiderMonkey ran out of memory and began returning NULL and JS_FALSE
but ELinks didn't notice them and pressed on. Add some checks to
avoid the crash, although the underlying out-of-memory error remains.
The old code failed to write pending spaces before changing the
background color. That seems hard to fix without duplicating code,
and ELinks pads dumped lines to the requested width in these color
modes anyway, so this commit just makes ELinks write all spaces
immediately when colors are being used.
Try the following command before and after this commit:
elinks --no-home --eval "set document.colors.use_document_colors = 2" \
--dump-color-mode 1 --dump test/color.html
In DUMP_FUNCTION_SPECIALIZED, use isscreensafe_ucs (for UTF-8) or
isscreensafe (for unibyte) to detect control characters, and replace
them with spaces. add_document_to_string already did the same.
In DUMP_FUNCTION_SPECIALIZED (used by elinks --dump), detect the
second cell of double-cell (aka fullwidth) characters by comparing to
UCS_NO_CHAR, like add_document_to_string does. Don't use
unicode_to_cell for this any more.
Also, ignore the colors and attributes of the second cell; don't
output any escape sequences for them.
This is especially useful for showing that neither dump_truecolor_utf8
nor dump_truecolor_unibyte modifies its static color[] variable and it
therefore does not matter whether those functions use the same array
or not.
With all the comments and macros needed for this, the source files
don't become much shorter, but anyway I hope they'll be easier to
maintain this way.
This code was included in four variants of dump_to_file().
Move it to a new function dump_references() and make dump_to_file()
then call that. This makes the code size a little smaller.
The time cost will be negligible.
Instead of having four separate function definitions, have just one
sprinkled with #ifdefs, and #include that four times. The purpose
being to make it clearer which parts of these functions are identical
and which ones differ.
As a side effect, this change makes ELinks ignore --dump-color-mode
when dumping in UTF-8. Colourful UTF-8 dumping has not been
implemented and the fallback is now different from before.
Avoid compilation error with GNUTLS 1.2.9:
/home/Kalle/src/elinks-0.12/src/network/ssl/ssl.c:258: error: implicit declaration of function ‘gnutls_priority_set_direct’
If the function is not available, use gnutls_set_default_priority instead.
Perhaps it'll work with bugzilla.novell.com, perhaps not.
- gnutls_handshake_set_private_extensions: Do not enable private cipher
suites that might not be supported by anything other than GNUTLS.
The GNUTLS 2.8.0 documentation notes that enabling these extensions
can cause interoperability problems.
- gnutls_set_default_priority: Explicitly disable OpenPGP certificates.
- gnutls_certificate_type_set_priority: Do not enable OpenPGP certificates.
The GNUTLS 2.8.0 documentation notes that OpenPGP certificate support
requires libgnutls-extra. Because libgnutls-extra 2.2.0 and later are
under GPLv3-or-later and thus not GPLv2 compatible, ELinks doesn't use
libgnutls-extra, so OpenPGP certificates didn't work anyway.
- gnutls_server_name_set: Do not tell the server the hostname from the URL.
This was supposed to let the server choose the appropriate certificate
for each name-based virtual host, but ELinks actually always sent just
"localhost", so it didn't work anyway. This will have to be revisited
when ELinks is changed to actually verify the subject name from the
server's certificate (ELinks bug 1024).
These changes should help ELinks negotiate SSL with bugzilla.novell.com.
[NEWS and commit message by me. --KON]
Yet another valiant wack at the beast. This one violates abstractions
a little less deeply, so maybe it will work better.
The last attempt caused a crash when a tab was cloned after the tab's
loading had been aborted.
(cherry picked from commit 76377d9714)
Kalle reported that after commit 5c96d430c9,
ELinks would crash if the document in the old tab was still loading when a
new tab was opened. The problem was that the new session's download.data
pointer was not updated to point to the session as doc_loading_callback
expects.
Instead of just calling render_document_frames, set up the download and
call load_uri.
(cherry picked from commit d6116ca83a)
In setup_session, use copy_location, add_to_history, and
render_document_frames instead of goto_uri and copy_vs to copy the base
tab's view state. By avoiding goto_uri, setup_session now bypasses MIME
checks, form post confirmations, malicious URL checks, and so on when
copying the base tab's current location and view state to the new tab,
so the new tab should get exactly what was loaded in the base tab.
This fixes bug 765: Opening a new tab can ask about the document of the
previous tab.
(cherry picked from commit 5c96d430c9)
Conflicts:
src/session/session.c:
Both elinks-0.12 and master had the ses->doc_view->vs
= vs assignment, but only elinks-0.12 had vs->doc_view
= ses->doc_view as well. Also, struct connection_state
had been added after the original patch.
I am not hooking these to "make test", for two reasons:
1. utf8_step_forward is inside #ifdef CONFIG_UTF8 and I don't see
how to make tests conditional on such options.
2. test/libtest.sh was copied from Git, which is under GPLv2-only.
Adding more dependencies on it could make ELinks more difficult
to relicense under GPLv2-or-later.
