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.
The GNU linker ld searches and processes libraries and object files in
the order they are specified. Library files are archive files whose
members are object files. The linker handles an archive file by scanning
through it for members that define symbols that have so far been
referenced but not defined. But an ordinary object file is linked in the
usual fashion.
The C library is implicitly linked after all object files and libraries
specified on the command line.
Because of that, if the C library depends on the Contiki target library,
e.g. for the implementation of system calls, then these dependencies are
not linked, which results in undefined references. Actually, the Contiki
target library also needs the C library, hence a circular dependency
between these libraries, which means that explicitly adding -lc anywhere
on the command line can not help. The only solution in that case is to
pass these libraries to ld between --start-group and --end-group.
Archives grouped in this way are searched repeatedly by the linker until
no new undefined references are created.
This archive grouping option has a significant performance cost for the
linking stage. Moreover, having to use it and to pass -lc explicitly on
the command line is unusual, which is disturbing and more complicated
for users needing the C library to depend on the Contiki target library.
The same would be true for circular dependencies between the Contiki
target library and any other library.
Another issue with the Contiki target library is that it may alter the
apparent behavior of the weak vs. strong symbols, because of the way ld
handles archives, which may make it discard archive object files
containing strong versions of referenced symbols:
- If a symbol has a weak and a strong version in this library, both
inside the same object file, then the linker uses the strong
definition.
- If a weak symbol in this library has a strong counterpart in an
object file outside, then the linker uses the strong definition.
- If a strong symbol in this library is inside an object file
containing other referenced symbols, and has a weak counterpart
anywhere, then the linker uses the strong definition.
- If a strong symbol in this library is the only symbol referenced in
its object file, and has a weak counterpart in an object file
outside, then the linker uses the strong definition if this library
is linked first, and the weak one otherwise.
- If a strong symbol in this library is the only symbol referenced in
its object file, and has a weak counterpart in another object file in
this library, then the linker uses the definition from the first of
these objects added when creating this archive.
- If a symbol has a weak and a strong version, one in this library, and
the other in another library, then the rules are the same as if both
were in the Contiki target library.
The existence of cases where the linker uses a weak symbol despite the
presence of its strong counterpart in the sources compiled then passed
to the linker is very error-prone, all the more this behavior depends on
the order the object and archive files are passed on the command lines,
which may just result from the order of source files in lists where it
apparently does not matter. Such cases would be needed in the future,
e.g. to define weak default implementations of some system calls that
can be overridden by platform-specific implementations, both ending up
in the Contiki target library. There was already such a case used to
define the UART and USB ISRs as weak aliases of default_handler(),
relying on this implicit unusual behavior to keep default_handler() if
the UART or USB driver was unused, which was dangerous.
Since the Contiki target library was only used as an intermediate file
during the build, the current commit fixes these issues by simply
directly using the object files instead of building an intermediate
archive from them.
The CONTIKI_OBJECTFILES make variable would be incomplete if it were
used as a simple prerequisite in the %.elf rule in Makefile.cc2538,
because other object files are added to it after this rule. That's why
.SECONDEXPANSION is used to defer its expansion. Another solution would
have been to split Makefile.cc2538, with the variable assignments kept
in it, and the rule definitions moved to Makefile.customrules-cc2538,
but this would have required to add Makefile.customrules-<target> files
to all CC2538 platforms, only to include Makefile.customrules-cc2538.
The solution used here is much simpler.
Because the UART and USB ISRs were weak aliases of default_handler(),
this change would imply that these ISRs would always be used by the
linker instead of default_handler(), even if their drivers were
configured as unused with UART_CONF_ENABLE and USB_SERIAL_CONF_ENABLE,
which would be wrong. This commit fixes this issue by removing these
weak aliases and putting either these ISRs or default_handler() in the
vector table, depending on the configuration. Weak aliases are elegant,
but Contiki's build system does not currently allow to automatically
build or not source files depending on the configuration, so keeping
these weak aliases would have required to add #if constructs somewhere
in the source code, which would have broken their elegance and made them
pointless.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
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.
Several keys can be kept at the same time in the key store, and several
keys can be loaded at once. Give access to these features.
The ccm-test example is also improved to better demonstrate the use of
the key store.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Using the AES interrupt allows the user process not to waste time
polling for the completion of the operation. This time can be used by
the user process to do something else, or to let the system enter PM0.
Since the system is now free to perform various operations during a
crypto operation, a protection of the crypto resource is added, and PM1+
is prohibited in order not to stall crypto operations.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The commit bddd96d5c8 "Removed all module
makefiles. Instead, all .c files in a module directory are compiled."
made the MODULESSUBST variable useless, but it did not remove it, so do
it now.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The CC2538 the WDT cannot be stopped once it has been started.
The CC2530/1 WDT can be stopped if it is running in timer mode,
but it cannot be stopped once it has been started in watchdog mode.
Both platforms currently provide "dummy" implementations of `watchdog_stop()`,
one does nothing and the other one basically re-maps `_stop()` to
`_periodic()`.
This was originally done in order to provide implementations for all prototypes
declared in `core/dev/watchdog.h`. In hindsight and as per the discussion
in #1088, this is bad practice since, if the build succeeds, the caller will
expect that the WDT has in fact been stopped, when in reality it has not.
Since the feature (stopping the WDT) is unsupported by the hardware, this pull
removes those dummy implementations. Thus, we will now be able to reliably
detect - at build time - attempts at using this unsupported feature.
The packet converter used to generate packets of length zero
when it encountered errors during conversion. This caused
exceptions in packet analyzers.
Now the converter returns null in case of error. Appropriate
checks have been added to the code that uses the return value.
* The current version of the README points to a wrong URL
for the LUFA Virtual Serial driver.
* A driver is nowadays provided by TI with CC2538
Foundation Firmware
Thus, this pull updates the LUFA driver URL and also provides a
link to CC2538 Foundation Firmware
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.
