Requiring & operator for one member of struct, but not for another.

[Markus]

Can you explain why line 31 does not require the address-of operator, while 33 does? I don't quite understand it.

#include <stdio.h>
 
struct computer {
    float cost;
    int   year;
    int   cpu_speed;
    char  cpu_type[16];
};
 
typedef struct computer SC;
 
void DataReceive(SC *ptr_s);
 
int main(int argc, char** argv)
{
    SC model;
 
    DataReceive(&model);
    printf("Here is what you entered: \n");
    //printf("Year: %d\n", model.year);
    //printf("Cost: %6.2f\n", model.cost);
    printf("CPU Type: %s\n", model.cpu_type);
    printf("CPU Speed: %d MHz\n", model.cpu_speed);
 
    return 0;
}
 
void DataReceive(SC *ptr_s) 
{
    printf("CPU Type: ");
        scanf("%s", ptr_s->cpu_type);
    printf("CPU Speed: ");
        scanf("%d", &ptr_s->cpu_speed);
}
 

Thanks,
Mark.

[donbock]

@Markus
From scanf documentation:

• Conversion specifier s: the corresponding argument shall be a pointer to the initial character of an array large enough to accept the sequence and a terminating null character, which will be added automatically.
• Conversion specifier d: the corresponding argument shall be a pointer to integer.

The argument for the %s conversion specifier is a char array. An array specifier is almost always equivalent to a pointer to the first element of the array; hence ptr_s->cpu_type is the same as &ptr_s->cpu_type[0] so it is a pointer to char as expected by scanf.

The argument for the %d conversion specifier is the address of an int; hence it is a pointer to int as expected by scanf.

By the way, you might prefer the following to preclude overflowing the cpu_type array:

    scanf("%15s", ptr_s->cpu_type);

[Markus]

Thank you very much, Donbock. That helps a whole bunch.

Quick q - what happens if the char array does overflow? I have experimented, but I didn't understand the output: stack smashing detected.

Thanks,
Mark.

[Banfa]

If you write outside the bounds of the array you get undefined behaviour.

Undefined behaviour is bad because anything can happen. The worst thing that can happen is that the program works as expected right up until the moment it is critical that it works and then it doesn't work in some catastrophic way.

If you are lucky undefined behaviour produces some result that you can immediately identify as wrong. However it is often hard to diagnose the exact cause of undefined behaviour when it happens.

stack smashing specifically refers to your compiler detecting that you have written to a portion of the stack that was not being used for the array. This is bad because the stack contains many critical pieces of information like the return address to jump to once the function has finished. Overwriting this would be a critical error (I hope you can see).

[donbock]

Suppose the operator responds to the 'CPU Type" prompt by entering 63 characters plus newline. The scanf function will write the 63 characters plus terminating null (64 characters in all) to the array. However, the size of the array is only 16 characters. This means that the next 48 bytes of memory are unintentionally corrupted.

Those 48 bytes might be other program variables; they might be cpu register values saved on the stack; they might be a function return address saved on the stack; they might be nonexistent memory; they might be memory-mapped I/O devices, or they might be executable code within your program.

The consequences of corrupting those 48 bytes are truly unpredictable. That's why the C Standard calls this "undefined behavior".

When I said earlier that these bytes are unintentionally corrupted; I meant from the programmer's point-of-view. It might indeed have been the operator's intention to overflow your buffer. This is one of the techniques used by black hats to take over a computer.

You may have heard that Standard C function gets is deprecated. That's because unlike scanf where you can specify the maximum field length, gets provides no way for the program to protect itself from an operator who deliberately or inadvertently overflows the input buffer.