scanf field width

For the %s conversion specifier, is the field width in bytes or characters? The C standard is suggesting that the field width is always measured in characters, but there's this small note that confuses me:
246) No special provisions are made for multibyte characters in the matching rules used by the c, s, and [ conversion specifiers — the extent of the input field is determined on a byte-by-byte basis. The resulting field is nevertheless a sequence of multibyte characters that begins in the initial shift state.
Also, the opengroup documentation seems to be suggesting (see the description given for the %c specifier as well) it's in bytes if no l length modifier is present. Otherwise, it's in characters.

plz help me lambda‼

DIS WEBSITE'S A PILE OF SHIT.

>>14
WELL, IT'S ONLY NORMAL DAT IT WUD USE DA NUMBER OF MULTIBYTE CHARACTERS RATHER THAN BYTES, CUZ IT ACCEPTS A 'wchar_t *' INSTED OF A 'char *'. IF UR COMPUTER USES UTF-8 AND U HAVE AN ARRAY OF 10 wchar_t ELEMENTS, U KNOW U SHUD USE DA "%9ls" FORMAT SPECIFIER. THIS WAY U CAN BE SURE UR READING AT MOST 10 CHARACTERS, REGARDLESS OF HOW MANY BYTES DAT ACTUALLY IS ON stdin.

U CUD TRY EXPERIMENTING WITH DIS CODE IF U WANT:

#include <locale.h>
#include <stdio.h>
#include <wchar.h>

int main(void)
{
    wchar_t buf[10];

    setlocale(LC_ALL, "");
    while (scanf("%9ls", buf) == 1)
        printf("%ls\n", buf);
}

The standard isn't clear about it, though (unless it's because I'm reading the draft).

DA STANDARD'S WRITTEN BY A BUNCH OF FUCKIN HYENAS WHO SUCKED DA LIFE OUT OF DEANIS RICKY. IT'LL MAKE SENSE ONCE U FAMILIARISE URSELF WITH DER LAWYERESE GIBBERISH.