Does malloc failure imply ENOMEM?

On POSIX systems like Linux and macOS, yes: if malloc() returns NULL, you can assume errno == ENOMEM.

The C standard itself is intentionally vague — it only guarantees that malloc() returns NULL on failure and says nothing about errno. However, POSIX does specify that malloc() sets errno on error, and the only defined error for these functions is ENOMEM.

So on modern Linux/macOS:

• malloc() returns NULL

• errno is set to ENOMEM

• No other error codes are defined or used in practice

That said, relying on errno isn’t really necessary. The idiomatic and safest check is simply:

p = malloc(n);
if (!p) {
    // out of memory
}

If your goal is to return HTTP 507 whenever allocation fails, treating any NULL return from malloc() as “insufficient memory” is perfectly reasonable and portable. Checking errno doesn’t buy you anything extra here, and it can even be misleading if some code touched errno earlier.

So: yes, ENOMEM in practice on your target platforms — but just checking for NULL is the correct design.

Be careful, Linux defaults to overcommit allocations, basically never failing malloc. It's only when you actively try to use the memory that you will notice if the system don't have enough memory.

As a general rule, you should always assume that the list of error codes in a manpage's ERRORS section is not exhaustive, even if some standard says it is.

There are situations where it would be plausible for the malloc family to return EINVAL, EOVERFLOW, or ERANGE instead of ENOMEM. For example, a call to calloc(n, size) where the product of n and size is larger than can be represented by ptrdifft might be coded to return EOVERFLOW, or a call to malloc where the size value fits in sizet but not in ptrdiff_t might return EINVAL.

However, ask yourself this: besides feeding the errno code to strerror and passing whatever string it produces along to the user (in the body of the 507 Insufficient Memory HTTP response) does it make sense to handle the error any differently when malloc returns a code other than ENOMEM? I would say no, it does not. Either there wasn't enough RAM, or there was a mathematical issue that made your request to allocate that much RAM nonsense, or ... maybe there's a system out there that can spit up an EIO from malloc if the swap disk is throwing I/O errors, even, but the effect of the error on your program is the same: you asked the OS for more RAM and you didn't get it, so 507 Insufficient Memory is an appropriate error code at the HTTP level.

Just don't forget to feed the errno code to strerror, pass whatever string it produces along to the user, and write that same string to the server logs. Your future self will thank you.

If I run malloc and it fails and returns NULL, can I assume that errno is set to ENOMEM?

No.

Setting ENOMEM, or even the existence of ENOMEM is not required by the C spec.

... hundreds of embedded systems or otherwise slightly non-standard implementations of C

An embedded application can be fully C compliant without using ENOMEM.

my code will only be running on modern Linux and MacOS

Yes, but it is so easy for one to present code without that limitation - leading to others in assuming the code is C compliant.
Consider OP's post did not also tag [Linux] and [MacOS].

Note the problem with malloc(0):

If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned to indicate an error, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. C23dr § 7.24.3 1

Portable code does not rely on ENOMEM. When it exist, it is useful in reporting errors, yet better if program flow does not rely on it.

void mymalloc(sizet n) {
  if (n == 0) {
    // Different views on handling this case:
    // 1:  Sometimes n is derived from a sizeof so this case does not occur.
    // 2: Assign NULL, but not an error
    return NULL;
    // 3: Continue on and perform "as if" size was 1.
    n = 1;
    // 4. Continue on and hope for the best.  (weakest)
    // 5: Others: assign a special value, message and exit, or ...
  }
  void p = malloc(n);
  if (p == NULL) {
    // Unless n==0 fell through from above, this could be due to out-of-memory.
    // Also possible to have enough memory but out of memory allocation "handles".
    // (e.g. far too many small allocations.)
    // Report, exit, return NULL, ...
  }
  return p;
}

void mymalloc(sizet n) {
  void *p = malloc(n ? n : 1);
  assert(p);
  return p;
}

I checked the man page for malloc ...

You checked a man page for malloc. One particular implementation.

But in general malloc() is free to set errno to any value no matter what it returns.

The (draft) C11 standard documentation for malloc() does not document any setting of errno by malloc().

Furthermore, per C11, 7.5 Errors , paragraph 3 (bolding mine):

... The value of errno may be set to nonzero by a library function call whether or not there is an error, provided the use of errno is not documented in the description of the function in this International Standard.

C17 and C23 are similar.

In general, you can't even rely on errno remaining zero after any malloc() call.

and also, ChatGPT says so too...

And now you know what to think of ChatGPT.

how could i possibly sleep at night knowing i sent a 507 instead of a 500?

I have also just realized in my case, you shouldn't really use WebDAV specific codes when not making a WebDAV server so I'll just be using 500 for all errors instead of 507 for no memory. But I'll leave this up for anyone else who happens to have the same question.

just checking for NULL is the correct design.

// foo returns NULL and sets errno on failure.
Type foo( ... ) {
   Type p = malloc( ... );
   if ( !p ) {
      errno = ENOMEM;
      return NULL;
   }
   int fd = open( ... );
   if ( fd == -1 ) {
      free( p );
      return NULL;
   }
   p->fd = fd;
   return p; 
}

p = malloc(n); if (!p) { // out of memory and over-simplifies. p may be NULL when n == 0 also.

"On non-POSIX systems, this means you can't just check if malloc returns NULL;" --> Reasonable. Yet on such systems, ENOMEM may not exist or the implementation uses another error macro. Using an #ifdef is a step toward handling those platforms.

   if ( !p ) {
      #ifdef ENOMEM
        errno = ENOMEM;
      #endif
      return NULL;
   }