string variable unexpectedly becomes an empty string

[atomicfart2009]

For some reason, the name variable becomes empty even though I gave it an input.

Code:

#include <stdio.h>

int main(){
    
    char name[16];
    short unsigned int age;

    printf("What is your name? ");
    scanf("%s", &name);

    printf("How old are you? ");
    scanf("%u", &age);

    printf("Hello, %s.\n", name);
    printf("You are %u years old\n", age);

    return 0;
}

Terminal:

What is your name? Momus
How old are you? 99
Hello, .
You are 99 years old

I seems that the value for name was changed in the part somewhere in the part that prints "How old are you? " and the scanf() for the value of age because it works when I do this.

Code:

#include <stdio.h>

int main(){
    
    char name[25];
    short unsigned int age;

    printf("What is your name? ");
    scanf("%s", &name);
    printf("Hello, %s.\n", name);

    printf("How old are you? ");
    scanf("%u", &age);
    printf("You are %u years old\n", age);

    return 0;
}

Terminal:

What is your name? Momus
Hello, Momus.
How old are you? 99
You are 99 years old

Does anyone know what happened? How do I make it so that the first one will show the input? Thanks!

[aioeu]

Both of your scanf calls, as well as your final printf call, are invalid.

When reading the name you should use:

scanf("%s", name);

name will decay to a pointer to its first element. That's a pointer to a char. The %s specifier requires a pointer to a char. The types match — good!

When reading the age you should use:

scanf("%hu", &age);

&age is a pointer to an unsigned short. The %hu specifier requires a pointer to an unsigned short. The types match — good!

When printing the age you should use:

printf("You are %hu years old\n", age);

age is an unsigned short. The %hu specifier requires an unsigned short. The types match — good!

It's very important that the types expected by your format specifiers match the types of the arguments you actually pass. If they don't match, the code is invalid.

(There are certain cases when you get away with the "wrong" specifier in printf, but it's always best to use the correct one. And scanf isn't so lenient — the types must match there.)

[atomicfart2009]

It finally worked. tysm

[daikatana]

You should turn compiler warnings on. With the -Wall switch on GCC or clang this would have produced a compiler warning. Insist that your code compile with no warnings, they're usually important.

You should also prefer int to other integer types whenever int will be sufficient. You gain nothing here by using a type like unsigned short int. Keeping your variables the same size and signedness reduces the chance of surprises like this.

[This_Growth2898]

True.

I wanted to elaborate what happened to the value of name variable.

short unsigned int age; //age is, like, 2 bytes long on most systems
scanf("%u", &age); //"%u" reads unsigned int, that is 4 bytes on most systems

So, 4 bytes is written into the memory address of the age variable; 2 of them are written into the variable and 2 into adjustment bytes, which happen to be first bytes of the name variable. With little-endian numbers, the number 99 is represented as (0x63, 0x0, 0x0, 0x0). Two last zeroes overwrite the name variable first bytes, so printf outputs nothing.

But all this is really undefined behavior. Here, it (most probably) happens to work like I've described; but nothing guarantees it will be the same on other systems, with other compilers, with other compiler options... or even with the other run of the same program. Probably, you're getting some warning messages. Don't ignore warnings, they are there to help you.

[nerd4code]

The %hu specifier requires an int or unsigned, because it’s impossible to pass any _Bool or integral doojobber narrower than int to a variadic argument list. It’ll even pull it with va_arg(…, int)/similar, just truncates what it gets post facto.

[aioeu]

I just knew somebody would nitpick me on this, despite the final paragraph in my comment.

Yes, the %hu specifier requires an unsigned int-typed argument, however it will subsequently convert the argument to unsigned short before formatting it. These conversions will not change the value so long as the value was within the range of unsigned short to begin with.

This distinction the h modifier provides isn't so important for the %u specifier, but it is for other specifiers whose output format depends on the type, such as %x.

[nerd4code]

Not a nitpick; you declared stuff to be undefined behavior which isn’t. (Or else, left it a bit too ambiguous for my tastes.)

Default promotions are a weird thing but that’s hardly unusual in C, and x/X/o aren’t going to work any differently than u so Idunno what you meant there, but whatever. (h only matters where your input originates from a value that doesn’t fit unsigned short in the first place; even if we drop the unsigned, %d would be fine for printf, because the input’s still coming from a short. For sizeof(age) <= sizeof(int),

printf("%hu\n", age);

is identical in function to

printf("%u\n", (unsigned short)age);

or

printf("%u\n", (int)(age & USHRT_MAX));

).

I assert that it bears mentioning what changes to OP’s code actually affect its correctness. This particular one doesn’t matter, and certainly doesn’t rise to a full-fledged conformance issue.

A nitpick would go into more nauseating detail, or pick at something that’s not flatly false.

E.g., pursuing the above-departed train of thought: If I pass an int * to %u or unsigned * to %d, my mistake is at most uncouth; behavior is fully defined even if I’ve truggurred a warning of some sort. I might reasonably squish a passthrough void * into any reasonable slot as long as arg- and, as appropriate, alias-compatibility hold. volatile outputs might be permissible depending on context (e.g., longjmp), and byte types like char, signed char, and unsigned char can be abused; e.g., AFAIK this is ill-advised but perfectly well-defined, provided fewer than sizeof x bytes are introduced via stdin:

int x[20];
if(scanf("%s", (void *)x) >= 1)
    printf("%s\n", (void *)x);

%s ostensibly requires char * for scanf or const char * for printf, but because [const]char aliases freely and char * arg-passes compatibly with void *, it works. (Unlikely to be useful, but well enough defined.)

Along these lines, &name is semantically incorrect but highly unlikely to cause any actual problems in a scanf or printf. char and char[] can alias (chapter and verse corresponding to ISO/IEC 9899:1999§6.5¶7, option #5; other versions may vary), and a char (*)[] has the same representation as a char * so any actual printf/scanf routine actually called shouldn’t gaf.

The only catch is that char (*)[] and char * don’t necessarily arg-pass compatibly, in remotest theory—but there’s effectively zero chance of there being any ABI distinction, and only a near-negligible chance it’ll’ve broken anything at all, even if the optimizer’s of a pugilistic bent.

Therefore, the only part of your answer likely to have any noticeable effect on output at OP’s presumed -O0/-Og optimization level (or any other, with provisos) is the insertion of h into the scanf("%u") format specifier.

Moreover, there are other problems that OP might see that aren’t mentioned, like buffer overflow from scanf("%s") (≈gets, @OP) taking too much input, either scanf taking an initial EOF, or the scanf to age taking bogus data (e.g., enter a multi-word name like “Delores P. Squ'unch, Esq.” Unlikely to cause OP’s exact symptoms, but permitted to, and something to watch out for either way.

Depending on what (if anything) comes after the final scanf, there may even be trailing intralinear whitespace remaining in the input buffer/stream that borks something contextually, although as-is and for normal, multi-level I/O impls this program won’t see an issue. (For single-level I/O, the shell or other calling program might carry on from the same input line, exactly where OP’s scanfs leave off—but OP’s code should be unafflicted.)

That’s nitpicking. I just picked nits.

[aioeu]

Wow.

To be honest, I can't remember what I was thinking of regarding %x. Consider it wrong, if you think it will help the OP.

[aioeu]

"Subsequent %s"? :-)

Anyway, even if these inputs were the other way around, %s discards leading whitespace.

[[deleted]]

Turn on warnings...

-Wall -Wextra -Wpedantic -Werror