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.
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.
We don't handle URLs with fragments exactly ;-) well - meaning we send the fragment part to the server and we don't display the document starting at the anchor tag. Instead of adding the missing capabilities and thus adding lots of code I instead opted to simply ignore fragment-only links. This approach is based on the practical knowledge that fragments are primarily used for intra-document navigation - and are as such fragment-only links. And as we ignore them anyway when displaying the document it's more ergonomic to not have those links in the first place.
Complex script code tends to contain other tags inside strings. As we generally don't parse strings we erroneously interpreted those tags. The easiest workaround is to not interpret tags at all until the </SCRIPT> tag is found.
parse_tag() is called both for attributes inside a tag and the end of the tag itself. For most tags parse_tag() doesn't distinguish both cases. This means that the "tag action" is additionally triggered for every tag attribute. When the tag "action" is setting some state this doesn't hurt. For many tags the "tag action" is to render a newline. Superfluous newlines are sort of acceptable to keep the code as small as possible. However the <li> "tag action" is to render a newline followed by an asterisk - and superfluous asterisks are ugly so we check for <li> if parse_tag() was called for the end of the tag itself.
At the time do_word() is called s.word[s.wordlen] is undefined. So it doesn't make sense to make decisions based on its value - and in fact I don't see why it was necessary/desirable in the first place.
Nowadays many HTTP server set cookies which may easily result in HTTP header fields longer than our 'httpheaderline' buffer. It doesn't hurt if we can't parse them but we need to be able to skip them and continue to parse the following header fields.
WWW_CONF_MAX_URLLEN is used as length for the 'editurl' textentry widget. The CTK code for handling that widget uses a single byte so the length can't be > 255. Thus WWW_CONF_MAX_URLLEN can't be > 255 as well.
Behave just like the CS8900A driver: Both the CS8900A and the LAN91C96 dynamically share a buffer for received packets and packets to be send. If the chip is exposed to a network with a lot of broadcasts the shared buffer might fill quicker with received packets than the 6502 reads them (via polling). So we might need to drop some received packets in order to be able to send anything at all.
ipv4/uip.c will not even be include in the list of sources in the first place if we are building with NETSTACK_CONF_WITH_IPV6 (CONTIKI_WITH_IPV6). Thus, there is no longer a need to wrap the entire source code in an #if guard.
Closes#935
OR-ing an offset to a base address instead of adding it is dangerous
because it can only work if the base address is aligned enough for the
offset.
Moreover, if the base address or the offset has a value unknown at
compile time, then the assembly instructions dedicated to 'base +
offset' addressing on most CPUs can't be emitted by the compiler because
this would require the alignment of the base address against the offset
to be known in order to optimize 'base | offset' into 'base + offset'.
In that case, the compiler has to emit more instructions in order to
compute 'base | offset' on most CPUs, e.g. on ARM, which means larger
binary size and slower execution.
Hence, replace all occurrences of 'base | offset' with 'base + offset'.
This must become a coding rule.
Here are the results for the cc2538-demo example:
- Compilation of uart_init():
* before:
REG(regs->base | UART_CC) = 0;
200b78: f446 637c orr.w r3, r6, #4032 ; 0xfc0
200b7c: f043 0308 orr.w r3, r3, #8
200b80: 2200 movs r2, #0
200b82: 601a str r2, [r3, #0]
* now:
REG(regs->base + UART_CC) = 0;
200b7a: 2300 movs r3, #0
200b7c: f8c4 3fc8 str.w r3, [r4, #4040] ; 0xfc8
- Size of the .text section:
* before: 0x4c7c
* now: 0x4c28
* saved: 84 bytes
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Several platforms defined compressions modes values:
SICSLOWPAN_CONF_COMPRESSION_IPV6
SICSLOWPAN_CONF_COMPRESSION_HC1
SICSLOWPAN_CONF_COMPRESSION_HC01
instead of using the global SICSLOWPAN_COMPRESSION_LEVEL definitions
