Re: Issue with sscanf not parsing correctly

[Keith Packard <keithp@keithp.com>]

[-- Attachment #1.1: Type: text/plain, Size: 738 bytes --]

Alexandre Raymond <alexandre.j.raymond@gmail.com> writes:

> Greetings!
>
> I have been developing on a Teensy 4.1 platform, which I'm told uses
> newlib under the hood, and encountered a strange issue with sscanf,
> where different parameter orderings yield different results with
> stdint types.

Odd. I've just tested this using the qemu model for the
thumb_v7e_m_dp_hard gcc target for the picolibc build set to use the
legacy stdio bits from newlib and it seems to work just fine (it also
works fine with the new stdio bits from picolibc).

Could this libc be built to not support C99 formats? That would cause
all kinds of issues as sscanf would fail when it hit the '%hhu' format.

Here's the regular C test code I used for this:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: sscanf-order.c --]
[-- Type: text/x-csrc, Size: 1023 bytes --]

#include <stdio.h>
#include <stdint.h>
#include <assert.h>
#include <stdlib.h>

void __assert_func(const char *file, int line, const char *func, const char *expr)
{
    printf("%s:%d (%s) assertion failed: %s\n", file, line, func, expr);
    exit(1);
}

int main(void) {
    uint8_t i2c_addr = 1;
    uint16_t mem_addr = 1;
    uint8_t len = 1;
    int ret;

    printf("%d, %d, %d\n", i2c_addr, mem_addr, len);
    //prints: 1,1,1

    const char *cmd = "1 2 3\n";

    // This is the order I intended to scan the string in
    ret = sscanf(cmd, "%hhu %hu %hhu", &i2c_addr, &mem_addr, &len);

    printf("%d- %d, %d, %d\n", ret, i2c_addr, mem_addr, len);
    assert(i2c_addr ==1 && mem_addr == 2 && len == 3);
    // prints: 3- 1,0,3

    // I just swap the order of the target variables around
    ret = sscanf(cmd, "%hhu %hhu %hu", &i2c_addr, &len, &mem_addr);

    printf("%d- %d, %d, %d\n", ret, i2c_addr, len, mem_addr);
    assert(i2c_addr ==1 && len == 2 && mem_addr == 3);
    // prints: 3- 1,2,3

    return 0;
}

[-- Attachment #1.3: Type: text/plain, Size: 145 bytes --]


I've added this as a picolibc test so it will be regularly checked
against both newlib and picolibc stdio bits going forward.

-- 
-keith

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]