Re: Issue with sscanf not parsing correctly

Keith Packard <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
Alexandre Raymond <[email protected]> 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:


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

-- 
-keith
sscanf-order.c (text/x-csrc, 1023 B)
#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;
}
signature.asc (application/pgp-signature, 832 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAmEalXoACgkQ2yIaaQAA
ABEdCw/5Acbujr4vfL4Qj07mSKDllDKLG1XiA/oxo59JOh0/3WDABm2+DOLEdHtD
UPNCPO7vmJfljrrbhzmJuTZatGFCd+pXIfnc6Mg7wTIB+HSTVsLBW48NanB+pvU+
FNRJRBVWE3Y/96/TAtw9AcarqaE7cOx+3nLqEfwh7hXgh4a6UZo68RzPActZquPN
yCThJzTucCMQ22/voVE91MEgucXP59RGbHATUDU3s8vVPHWicOtzkaCzRIqhcTCL
SEqsFGkYAZpXmDrv4jWYszMYoxmZWlFvyASqljI1fnbhl6NmGMTo9adLfTZZqa5y
sq5mLogi9n22CctrFdxw//meTwGV+i3OwjhbfeOW5iUKM58ZA4fa73S4vYLFpdOd
Wm1kENshL+ThpFWSY3J1wJIRs66oqhGuB5orlFnAvG6ogLyPsocCRUbFnmgi892L
xkI8oh7ngdfJtiyK3V9XUPcNZfGZUh4KceLJSrAF+Q6PQvWVcEFNAa+rwTuw8XMp
tALRr1lsBEOLHpNUDW/7rGdNUxXkbPOWJVVmnM49J1k7AhmHzvKvBsW35EJv8dzK
KnQJQGSVBitk4H+NV4WHF3baenlnzCjmj7cKpgKKL4FVW+ZevPvR3MRIRpWtodhJ
C0Q0VH6onHmYxgMs5I9OdCOtrf28bksFLH5oeKknsSOiWiOh0o8=
=WhZI
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.