Parts of the stm32w108 doxygen comments have explicit links to symbols that do not exist anywhere in our source base, let alone be documented. This is likely to be caused by a partial import of manufacturer libraries in the Contiki source tree.
These links were previously not generating warnings in the doxygen log because we were not defining `DOXYGEN_SHOULD_SKIP_THIS` and they were thus being skipped altogether by the doxygen pre-processor. Defining `DOXYGEN_SHOULD_SKIP_THIS` causes those doxygen comments to get processed and to thus generate warnings.
This commit removes explicit links to non-existent symbols and updates `doxyerrors.cnt` accordingly.
- By end of Jan 2014 SuperTweet.net was shut down (http://supertweetnews.140plus.com/). So Breadbox64 has come to an end for sure :-(
- The email app - or rather email sending app as it is SMTP only - can't be used anymore since nowadays everybody uses some "strong" authentication for SMTP session logon (thanks NSA).
- The ftp client app isn't very useful as it supports only download - for which the WGET app is almost always more useful for. But more important it doesn't support PASV which is more or less the only supported mode nowadays (especially over NAT).
Both apps/dhcp/dhcp.c:dhcpc_configured() and cpu/6502/ipconfig/ipconfig.c:dhcpc_configured() presume the first parameter of uip_nameserver_update() to be const. As there's no reason for it to be not const just make it const.
Forms with multiple submit buttons are rather rare but nevertheless the most popular web page (www.google.com) contains one with the two submit buttons "Google Search" and "I'm Feeling Lucky". So we want to support that - incl. the usual feature to the interpret first button as default button used when the user presses the ENTER key.
Script code may contain a '<' as part of a equation. We erroneously interpreted that as start of a tag. Now we check for the very next char to be a '/' as the only tag allowed is the </SCRIPT> tag.
When using the 'down' button on a certain number of lines curently displayed at the bottom of the screen is redisplayed at the top of the screen. Given our usually small screen size and often large pages requiring many 'down' operations the number 'four' seems too generous so lets reduce it to 'two'.
- The wraparound handling when using the history with the 'back' button is actually depending on history_last being unsigned (which is the default for cc65) so define it explicitly as unsigned to make it work on other targets too.
- As there's no 'forward' button it doesn't make sense to keep history entries after using them with the 'back' button. Clearing them on use on the other hand avoids an "infinite history".
Although we for sure don't support HTTPS we need to recognize it. Nowadays it has become pretty usual to redirect HTTP URLs to HTTPS URLs in order to force privacy (thanks, NSA !). So far our redirection handler didn't recognize an HTTPS URL as abslute URLs and therefore appended it to the curent URL. This led to an endless redirection loop. Now we recognize the HTTPS redirection and generate a minimal document on the fly to inform the user of (for us unrachable) the redirection target.
HTML links with HTTPS URLs are treated just like fragment-only links meaning that they get simply completely ignored.
This patch restores the original behaviour of Cooja when
the transmitted packet is correct (which is true in a vast majority
of cases).
In case of a wrong outgoing packet (wrong length, wrong preamble)
the transmission will end when the radio changes its state (which
should always happen after transmitting a packet).
Benchmarks with RPL (33 runs, 50 nodes, 3 hours of simulated time each)
yield the same results (PDR, delay, number of transmitted packets)
as with the unmodified Cooja.
The code to trim spaces from the end of the URL behaved undefined if the URL was empty. That scenario is far from hypothetic as i.e. pressing the 'back' button with no (more) entry in the history yields an empty URL.
The way our HTML parser triggers newlines is a guess at best. On the other hand our screen estate is severely limited. Instead of trying to (further) improve the way we translate tags to newlines it seems more reasonable to simply never render more than two successive empty lines.
