How to portably convert a string into an uncommon integer type?

前端 未结 3 864
臣服心动
臣服心动 2020-12-30 07:46

Some background: If I wanted to use for, for instance, scanf() to convert a string into a standard integer type, like uint16_t, I’d use SCNu1

相关标签:
3条回答
  • 2020-12-30 08:16

    It depends on exactly how portable you want to be. POSIX says that pid_t is a signed integer type used to store process IDs and process group IDs. In practice, you could assume with safety that long is big enough. Failing that, your intmax_t must be big enough (so it will accept any valid pid_t); the trouble is, that type could accept values that are not legitimate in pid_t. You're stuck between a rock and a hard place.

    I would use long and not worry very much about it except for an obscure comment somewhere that a software archaeologist of 100 years hence will find and observe gives a reason why the 256-bit CPU is creaking to a halt when handed a 512-bit value as a pid_t.

    POSIX 1003.1-2008 is now available on the web (all 3872 pages of it, in PDF and HTML). You have to register (free). I got to it from the Open Group Bookstore.

    All that I see there is that it must be a signed integer type. Clearly, all valid signed integer values fit into intmax_t. I cannot find any information in <inttypes.h> or <unistd.h> that indicates PID_T_MAX or PID_T_MIN or other such values (but I've only just this evening got access to it, so it could be hidden where I haven't looked for it). OTOH, I stand by my original comment - I believe that 32-bit values are pragmatically adequate, and I would use long anyway, which would be 64-bit on 8-bit machines. I suppose that roughly the worst thing that could happen is that an 'appropriately privileged' process read a value that was too large, and sent a signal to the wrong process because of a mismatch of types. I'm not convinced I'd be worried about that.

    ...oooh!...p400 under <sys/types.h>

    The implementation shall support one or more programming environments in which the widths of blksize_t, pid_t, size_t, ssize_t, and suseconds_t are no greater than the width of type long.

    0 讨论(0)
  • 2020-12-30 08:23

    There is one robust and portable solution, which is to use strtoimax() and check for overflows.

    That is, I parse an intmax_t, check for an error from strtoimax(), and then also see if it "fits" in a pid_t by casting it and comparing it to the original intmax_t value.

    #include <inttypes.h>
    #include <stdio.h>
    #include <iso646.h>
    #include <sys/types.h>
    char *xs = "17";            /* The string to convert */
    intmax_t xmax;
    char *tmp;
    pid_t x;                    /* Target variable */
    
    errno = 0;
    xmax = strtoimax(xs, &tmp, 10);
    if(errno != 0 or tmp == xs or *tmp != '\0'
       or xmax != (pid_t)xmax){
      fprintf(stderr, "Bad PID!\n");
    } else {
      x = (pid_t)xmax;
      ...
    }
    

    It is not possible to use scanf(), because, (as I said in a comment) scanf() will not detect overflows. But I was wrong in saying that none of the strtoll()-related functions takes an intmax_t; strtoimax() does!

    It also will not work to use anything else than strtoimax() unless you know the size of your integer type (pid_t, in this case).

    0 讨论(0)
  • 2020-12-30 08:34

    If you are really concerned you can _assert(sizeof(pid_t) <= long) or whatever type you choose for your '%' stuff.

    As explained in this answer, the spec says signed int. If 'int' changes, your '%u' by definition changes with it.

    0 讨论(0)
提交回复
热议问题