Commit graph

1905 commits

Author SHA1 Message Date
Nicolas Pitre
ffab197928 libc: fix memchr() prototype
The standard memchr() uses an int for its second argument.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-07-10 13:42:31 -07:00
Timo Teräs
55dc481a15 libc: add strnlen implementation
This is standard function and useful for application writers.

Signed-off-by: Timo Teräs <timo.teras@iki.fi>
2019-07-10 13:41:20 -07:00
Jukka Rissanen
b889120ca7 Revert "libc: types: Remove wrong definition"
This reverts commit 2a63e342f4.

This needs to be reverted as otherwise the type of ssize_t will be
"unsigned long" which is not correct.

    (gdb) ptype ssize_t
    type = unsigned long

For example this check would fail in that case

    ssize_t foo(void)
    {
        return -1;
    }
    ...
    if (foo() < 0) {
        printk("This is never called\n");
    }

Fixes #17378

Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2019-07-09 21:55:05 +03:00
Jan Van Winkel
18ef131c80 gui: Move lvgl into a zephyr module
Removed lvgl sources from CMakefile.txt and only keep zephyr glue
logic.

Further added lvgl module to west.yml.

Signed-off-by: Jan Van Winkel <jan.van_winkel@dxplore.eu>
2019-07-06 07:58:44 -04:00
Nicolas Pitre
1b359e6426 limits.h: streamline value definitions
Compilers (at least gcc and clang) already provide max value definitions
for basic types. It makes sense to rely on them to properly support
both 32-bit and 64-bit builds.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-07-05 10:05:37 -04:00
Nicolas Pitre
39cd2ebef7 malloc: make sure returned memory is properly aligned
The accounting data stored at the beginning of a memory block used by
malloc must push the returned memory address to a word boundary. This
is already the case on 32-bit systems, but not on 64-bit systems where
e.g. struct k_mem_block_id still has a size of 4.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-07-03 14:17:29 -07:00
Andy Ross
ee4c23cc1f CMSIS v2: Work around time unit confusion
The current CMSIS v2 implementation is clearly assuming that timeout
arguments being passed to e.g. osDelay() are in units of Zephyr ticks,
not milliseconds as specified by ARM or (inconsistently) assumed by
our test code.

Most tests work with the ~100 Hz default tick rate, but they tend to
fail on precision issues at higher tick rates.  Force the CMSIS v2
applications to be 1000 Hz for now as a workaround, and detect the
mismatch as a build failure.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-07-02 22:52:29 -04:00
Nicolas Pitre
fc4ca923bb mempool: fully use the inline free block bitmap on 64-bit targets
The "bits" field in struct sys_mem_pool_lvl is unioned with a pointer.
That leaves more space for inline free bits on 64-bit targets.
Let's declare it as an array and adjust its size based on the pointer
size. On 32-bit targets the generated code remains identical.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-07-02 19:41:20 -07:00
Nicolas Pitre
cf974371fb mempool: make alignment/rounding 64-bit compatible
Minimum alignment and rounding must be done on a word boundary. Let's
replace _ALIGN4() with WB_UP() which is equivalent on 32-bit targets,
and 64-bit aware.

Also enforce a minimal alignment on the memory pool. This is making
a difference mostly on64-bit targets where the widely used 4-byte
alignment is not sufficient.

The _ALIGN4() macro has no users left so it is removed.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-07-02 19:41:20 -07:00
Andrew Boie
d045bd7673 lib: os: exclude z_arch_printk_char_out()
This function doesn't do anything, and only exists so that
it can be overridden later, exclude from coverage reports.

Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-06-28 20:04:29 -07:00
Andrew Boie
05212e823f lib: os: fix vsnprintk coverage
vsnprintk() was uncovered. Simply adjust snprintk() to use
it, instead of duplicating logic.

Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-06-28 20:04:29 -07:00
Anas Nashif
5b0aa794b2 cleanup: include/: move misc/reboot.h to power/reboot.h
move misc/reboot.h to power/reboot.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
efb8df5366 cleanup: include/: move misc/stack.h to debug/stack.h
move misc/stack.h to debug/stack.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
a2fd7d70ec cleanup: include/: move misc/util.h to sys/util.h
move misc/util.h to sys/util.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
d222553931 cleanup: include/: move misc/speculation.h to sys/speculation.h
move misc/speculation.h to sys/speculation.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
536dd5a71f cleanup: include/: move misc/slist.h to sys/slist.h
move misc/slist.h to sys/slist.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
1859244b64 cleanup: include/: move misc/rb.h to sys/rb.h
move misc/rb.h to sys/rb.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
9ab2a56751 cleanup: include/: move misc/printk.h to sys/printk.h
move misc/printk.h to sys/printk.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
0c9e280547 cleanup: include/: move misc/mutex.h to sys/mutex.h
move misc/mutex.h to sys/mutex.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
08ee8b09ba cleanup: include/: move misc/mempool.h to sys/mempool.h
move misc/mempool.h to sys/mempool.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
1ed300b318 cleanup: include/: move misc/mempool_base.h to sys/mempool_base.h
move misc/mempool_base.h to sys/mempool_base.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
6ecadb03ab cleanup: include/: move misc/math_extras.h to sys/math_extras.h
move misc/math_extras.h to sys/math_extras.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
447311ec3e cleanup: include/: move misc/libc-hooks.h to sys/libc-hooks.h
move misc/libc-hooks.h to sys/libc-hooks.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
8be9f5de03 cleanup: include/: move misc/fdtable.h to sys/fdtable.h
move misc/fdtable.h to sys/fdtable.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
896b8d3c50 cleanup: include/: move misc/errno_private.h to sys/errno_private.h
move misc/errno_private.h to sys/errno_private.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
5eb90ec169 cleanup: include/: move misc/__assert.h to sys/__assert.h
move misc/__assert.h to sys/__assert.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
7435e5e089 cleanup: include/: move ring_buffer.h to sys/ring_buffer.h
move ring_buffer.h to sys/ring_buffer.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
9e35d53d1f cleanup: include/: move display.h to drivers/display.h
move display.h to drivers/display.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
f901e26de9 cleanup: include/: move hwinfo.h to drivers/hwinfo.h
move hwinfo.h to drivers/hwinfo.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
fe051a9055 cleanup: include/: move flash.h to drivers/flash.h
move flash.h to drivers/flash.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
0abdacf3a4 cleanup: include/: move json.h to data/json.h
move json.h to data/json.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
4e48e87fd2 cleanup: include/: move crc.h to sys/crc.h
move crc.h to sys/crc.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
bd977d06f8 cleanup: include/: move base64.h to sys/base64.h
move base64.h to sys/base64.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
e1e05a2eac cleanup: include/: move atomic.h to sys/atomic.h
move atomic.h to sys/atomic.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Anas Nashif
656f4dfdac cleanup: include/: move fs.h to fs/fs.h
move fs.h to fs/fs.h and
create a shim for backward-compatibility.

No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.

Related to #16539

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-27 22:55:49 -04:00
Daniel Leung
1c5fa6a128 cmake: use sdk-ng built toolchain for x86_64
This adds the necessary bits to utilize the x86_64 toolchain
built by sdk-ng for x86_64 when toolchain variant is either
zephyr or xtools. This allows decoupling the builds from
the host toolchain.

Newlib is also available with this toolchain so remove
the Kconfig restriction on CONFIG_NEWLIB_LIBC.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-06-27 16:08:32 -04:00
Flavio Ceolin
2a63e342f4 libc: types: Remove wrong definition
types.h was wrongly defining unsigned as signed and following
undefining it. This definition was not being used anywhere though.

Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2019-06-27 07:17:04 -04:00
Ioannis Glaropoulos
ff07fc7f0a lib: libc: fix alignment of HEAP base address for ARM
In ARM builds with support for user mode, i.e. with
CONFIG_USERSPACE=y, we need to align the beginning
of the heap space, to respect the ARM MPU region
alignment requirements.

Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2019-06-26 09:11:45 -04:00
Ioannis Glaropoulos
53ec19c3cc lib: libc: newlib: define USED_RAM_END_ADDR only where it is needed
USED_RAM_END_ADDR is not used when Kconfig option
CONFIG_NEWLIB_LIBC_ALIGNED_HEAP_SIZE is defined,
therefore, we do not need to define the macro in
that specific case.

Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2019-06-26 09:11:45 -04:00
Nicolas Pitre
f32330b22c stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.

Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.

However there are two cases for which we should override those
definitions:

* The __INT32_TYPE__ definition on 32-bit targets vary between an int
  and a long int depending on the architecture and configuration.
  Notably, all compilers shipped with the Zephyr SDK, except for the
  i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
  Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
  always define __INT32_TYPE__ as an int. Having variability here is
  not welcome as pointers to a long int and to an int are not deemed
  compatible by the compiler, and printing an int32_t defined with a
  long using %d makes the compiler to complain, even if they're the
  same size on 32-bit targets. Given that an int is always 32 bits
  on all targets we might care about, and given that Zephyr hardcoded
  int32_t to an int before, then we just redefine __INT32_TYPE__ and
  derrivatives to an int to keep the peace in the code.

* The confusion also exists with __INTPTR_TYPE__. Looking again at the
  Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
  initially a long int. One notable exception is i586-zephyr-elf where
  __INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
  this is always a long int. So let's redefine __INTPTR_TYPE__ to always
  be a long int on Zephyr which simplifies the code, works for both
  32-bit and 64-bit targets, and mimics what the Linux kernel does.
  Only a few print format strings needed adjustment.

In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-25 23:29:22 -04:00
Nicolas Pitre
d4b60d691c malloc: no longer need to round mempool's max_sz
Since commit 465b2cf31b this value is rounded at compile time instead.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-25 23:24:53 -04:00
Nicolas Pitre
1140bd090c mempool: properly use the inline free block bitmap
The free block bitmap uses either extra memory specified by a pointer
in struct sys_mem_pool_lvl or the space occupied by that pointer
directly if the bitmap length is small enough to fit it.

But the test is wrong. the inline bitmap should be used if the number
of required bits is smaller or _equal_ to the pointer size. Not doing so
would wrongly bounce the free block bitmap to extra memory when the
number of blocks is exactly 32, which is in disagreement with
Z_MPOOL_LBIT_WORDS() that correctly returns 0 in that case.

In theory that mean that this bug would causes an overflow of the free
block bitmap whenever one level has exactly 32 blocks. But right now
there is a separate bug fixed separately that over-sizes the extra block
bitmap mitigating this bug.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-25 23:24:05 -04:00
Andy Ross
d0490fe9f9 lib/os/mempool: Fix corruption case with block splitting
The block_fits() predicate was borked.  It would check that a block
fits within the bounds of the whole heap.  But that's not enough:
because of alignment changes between levels the sub-blocks may be
adjusted forward.  It needs to fit inside the PARENT block that it was
split from.

What could happen at runtime is that the last subblocks of a
misaligned parent block would overlap memory from subsequent blocks,
or even run off the end of the heap.  That's bad.

Change the API of block_fits() a little so it can extract the parent
region and do this properly.

Fixes #15279.  Passes test introduced in #16728 to demonstrate what
seems like the same issue.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-06-25 18:51:08 -07:00
Nicolas Pitre
465b2cf31b mempool: fix corruption of the free block bitmap and beyond
In z_sys_mem_pool_block_alloc() the size of the first level block
allocation is rounded up to the next 4-bite boundary. This means one
or more of the trailing blocks could overlap the free block bitmap.

Let's consider this code from kernel.h:

  #define K_MEM_POOL_DEFINE(name, minsz, maxsz, nmax, align) \
       char __aligned(align) _mpool_buf_##name[_ALIGN4(maxsz * nmax) \
                              + _MPOOL_BITS_SIZE(maxsz, minsz, nmax)]; \

The static pool allocation rounds up the product of maxsz and nmax not
size of individual blocks. If we have, say maxsz = 10 and nmax = 20,
the result of _ALIGN4(10 * 20) is 200. That's the offset at which the
free block bitmap will be located.

However, because z_sys_mem_pool_block_alloc() does this:

        lsizes[0] = _ALIGN4(p->max_sz);

Individual level 0 blocks will have a size of 12 not 10. That means
the 17th block will extend up to offset 204, 18th block up to 216, 19th
block to 228, and 20th block to 240. So 4 out of the 20 blocks are
overflowing the static pool area and 3 of them are even located
completely outside of it.

In this example, we have only 20 blocks that can't be split so there is
no extra free block bitmap allocation beyond the bitmap embedded in the
sys_mem_pool_lvl structure. This means that memory corruption will
happen in whatever data is located alongside the _mpool_buf_##name
array. But even with, say, 40 blocks, or larger blocks, the extra bitmap
size would be small compared to the extent of the overflow, and it would
get corrupted too of course.

And the data corruption will happen even without allocating any memory
since z_sys_mem_pool_base_init() stores free_list pointer nodes into
those blocks, which in turn may get corrupted if that other data is
later modified instead.

Fixing this issue is simple: rounding on the static pool allocation is
"misparenthesized". Let's turn

	_ALIGN4(maxsz * nmax)

into

	_ALIGN4(maxsz) * nmax

But that's not sufficient.

In z_sys_mem_pool_base_init() we have:

        size_t buflen = p->n_max * p->max_sz, sz = p->max_sz;
        u32_t *bits = (u32_t *)((u8_t *)p->buf + buflen);

Considering the same parameters as above, here we're locating the extra
free block bitmap at offset `buflen` which is 20 * 10 = 200, again below
the reach of the last 4 memory blocks. If the number of blocks gets past
the size of the embedded bitmap, it will overlap memory blocks.

Also, the block_ptr() call used here to initialize the free block linked
list uses unrounded p->max_sz, meaning that it is initially not locating
dlist nodes within the same block boundaries as what is expected from
z_sys_mem_pool_block_alloc(). This opens the possibility for allocated
adjacent blocks to overwrite dlist nodes, leading to random crashes in
the future.

So a complete fix must round up p->max_sz here too.

Given that runtime usage of max_sz should always be rounded up, it is
then preferable to round it up once at compile time instead and avoid
further mistakes of that sort. The existing _ALIGN4() usage on p->max_sz
at run time are then redundant.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-24 12:10:09 -07:00
Anas Nashif
f2cb20c772 docs: fix misspelling across the tree
Found a few annoying typos and figured I better run script and
fix anything it can find, here are the results...

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-19 15:34:13 -05:00
David B. Kinder
2aebc980e2 doc: fix Kconfig misspellings
Fix misspellings in Kconfig files missed during regular reviews.

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2019-06-18 15:07:52 -04:00
Andrew Boie
db84a76379 lib: os: remove dead code
If multithreading is disabled, thread_entry() never runs
since we cannot create threads; the non-multithreading case
was simply dead code.

Indicate to code coverage that CODE_UNREACHABLE should be
skipped.

Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-06-18 09:08:01 -04:00
Nicolas Pitre
c47bf1fa5e prf.c: implement the ll length modifiers
This allows for printing long long values. Because the code size
increase may be significant, this is made optional on 32-bit targets.
On 64-bit targets this doesn't change the code much as longs and
long longs are the same size so it is always enabled in that case.

The test on MAXFLD has to be adjusted accordingly. Yet, its minimum
value wasn't large enough to store a full-scale octal value, so this
is fixed as well.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-17 10:58:09 -07:00
Nicolas Pitre
2b32059a61 printk: make it 64-bit compatible
On 64-bit systems the most notable difference is due to longs and
pointers being 64-bit wide. Therefore there must be a distinction
between ints and longs. Similar to the prf.c case, this patch properly
implements the h, hh, l, ll and z length modifiers as well as some small
cleanups.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-17 10:28:44 -07:00
Nicolas Pitre
a6891e0313 prf.c: make it 64-bit compatible
On 64-bit systems the most notable difference is due to longs and
pointers being 64-bit wide. Therefore there must be a distinction
between ints and longs.

This patch:

- Make support functions take a long rather than an int as this can
  carry both longs and ints just fine.

- Use unsigned values in _to_x() to cover the full unsigned range
  and avoid sign-extending big values. Negative values are already
  converted to unsigned after printing the minus sign. This also makes
  division and modulus operations slightly faster.

- Remove excessive casts around va_arg() and use proper types with it.

- Implement the l and z length modifiers as they're significant on
  64-bit targets. While at it, throw in the z modifier as well.
  Since they all come down to 32-bit values on 32-bit targets, the
  added code should get optimized away as duplicate by the compiler
  in that case.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-13 12:55:17 -07:00