CareerCup

I would say neither option is correct.
a. The program cannot crash OS. Memory either will be allocated or not.
b. Incorrect due virtual memory concept.
c. Memory will be allocated but WITHOUT any guarantee it will be a PHYSICAL memory. Actually, only single physical memory page is needed here.
d. It depends from many factors...
For instance on 32-bit platform 1 << 31 after conversion to size_t gives 2147483648 bytes and allocation likely will be satisfied.
On other hand on 64-bit platform 1 << 31 after conversion to size_t gives 0xffffffff80000000 bytes and allocation will fail.

@AndrewJD

Can you explain - "On other hand on 64-bit platform 1 << 31 after conversion to size_t gives 0xffffffff80000000 bytes and allocation will fail."

When malloc failes here, it will return null. and calling memset with null pointer will cause program to crash.

If this was an MCQ then I would go with option C. If asked interview then we can say it depends upon the processor and available memory (both Primary and Secondary.)

Probably option C in an interview, but since

p

isn't used after

memset

, your compiler may optimize this call out leaving you with a do-nothing program. (depending on your

malloc

implementation)

That's why we have SecureZeroMemory.

if it is linux OS then answer to it is: C
in linux the default VM does overcommit, so malloc 2GB will save some of it in the RAM and all the rest in the VM.

program won't compile
1<<;31

Program wont compile

#include<stdio.h>                                                                                                                                                                                    [0/0]
#include<stdlib.h>
#include<string.h>
#include<errno.h>
#define SIZE (1ULL << 63)


int main()
{
    char *p = malloc(SIZE);
    char *s;
    if (!p) {
       perror("ERROR:");
       printf("Memory allocation failed %p \n",p);
    }
    s = memset(p,0,SIZE);
//   printf("Value = %d \n", p[SIZE-1]);
    if (!s) {
         printf("Memory set failed %p \n",s);
         perror("ERROR");
    }
    return 0;



}

root@prompt:> gcc -g -O0 temp.c -o tout

root@prompt:> ./tout
ERROR:: Cannot allocate memory
Memory allocation failed (nil)
Memory set failed (nil)
ERROR: Cannot allocate memory
root@prompt:>


No ambiguity in behavior, it make sense to follow basic practices & check return values from system call or library calls.

#include<stdio.h>                                                                                                                                                                                    
#include<stdlib.h>
#include<string.h>
#include<errno.h>
#define SIZE (1ULL << 63)


int main()
{
    char *p = malloc(SIZE);
    char *s;
    if (!p) {
       perror("ERROR:");
       printf("Memory allocation failed %p \n",p);
    }
    s = memset(p,0,SIZE);
//   printf("Value = %d \n", p[SIZE-1]);
    if (!s) {
         printf("Memory set failed %p \n",s);
         perror("ERROR");
    }
    return 0;

}

raghuh@coraghuh01:~/scratchpad$ ./tout
ERROR:: Cannot allocate memory
Memory allocation failed (nil)
Memory set failed (nil)
ERROR: Cannot allocate memory
raghuh@coraghuh01:~/scratchpad$



The memory is not allocated & it returns errno set.

None of the answers is fully correct or fully wrong. A lot depends upon the OS and the compiler. Let's start from the pasted code

1) The code as pasted won't compile as SIZE is defined to be (1<<;31). In general #define doesn't have an issue with this but depending upon how it is used it would cause a compilation failure. That's the case with the code pasted here

2) Assuming that ";" is a typo and it is actually
#define SIZE(1<<31)
then the intention of the program is to allocate 2GB of memory and set it to 0. But there are multiple issue
i) malloc returns void pointer and under strict compilation it should be case to (char *) to avoid any error.
ii) If malloc succeeds, the program is fine. If it fails then memset will try to set the memory pointed to by null pointer and that will cause a crash (segmentation fault on Linux)
iii) Crashing the OS under the operating systems that provide virtual memory is very less likely as the process trying to allocate memory will get dumped without impacting the kernel.

so, in short, among all the options presented, every option has a possibility to be true except b. b can also be true with a system with no virtual memory, I guess.