Have you set "Compile as C" in project properties?

Well, assigning an unsigned char * to a variable of type char * is invalid in both C and C++ anyway, as signed char, char, and unsigned char are all different types. Older versions of VC++ simply did a crappy job of telling you so.

As for the return from malloc needing to be cast - in C++ it does need to be cast, as C++ admits no implicit pointer type coercion. Since malloc returns a void *, and you're attempting to assign to some other type of pointer, you need to cast the return.

C automagicaly coerces void * to and from any other pointer type, so there is no need to cast the return from malloc. In fact, it is considered by many (including myself) to be poor style to cast the return from malloc, as it can hide implicit declaration of malloc (i.e. the failure to #include <stdlib.h>.

When you sent "compile as c", V++ is actually reasonably compliant with C90 ... just not C99.

I'd guess that it's for programmers who might not know the possible problems with signed vs. unsigned chars. That's why they have all those deprecated warnings using string functions warning about buffer overflows. The vast majority of their own programmers need this stuff.

C is known for its lack of type safety. C will gladly implicitly convert between any pointer types, though sane compilers will give out a warning for incompatible types. If MSVC is throwing out an error for that in C code, it's broken.

Just one minute with a C compiler will prove that incorrect.

#include <stdio.h>

int main() {

    unsigned char *uc;
    char c = 'f';

    uc = &c;
    printf("%c  %c", c, *uc);

    return 0;
    
}

Prints: f f

What a given C compiler does or doesn't flag is beside the point - the standard specifies what is and is not valid. Pointer conversion is a pretty simple issue, but, none the less, I'll take the time to look up and quote chapter and verse. I only have the C89 standard and draft C1x standards handy; I'll use the former, since C89 is still the most commonly used standard right now (sadly).

Section 3.3.16.1 specifies the semantics of simple assignment. With respect to pointer assignment, it says:

 * both operands are pointers to qualified or unqualified versions of
   compatible types, and the type pointed to by the left has all the
   qualifiers of the type pointed to by the right;

 * one operand is a pointer to an object or incomplete type and the
   other is a pointer to a qualified or unqualified version of void, and
   the type pointed to by the left has all the qualifiers of the type
   pointed to by the right; or

In section 3.5.4.1, which describes pointer declarators, it says:

   For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types.

Section 3.1.2.6 defines compatible types. It says, in part:

3.1.2.6 Compatible type and composite type

   Two types have compatible type if their types are the same.
Additional rules for determining whether two types are compatible are
described in $3.5.2 for type specifiers, in $3.5.3 for type
qualifiers, and in $3.5.4 for declarators.

Finally, section 3.5.2 describes type specifiers. It says:

 Each list of type specifiers shall be one of the following sets; the
type specifiers may occur in any order, possibly intermixed with the
other declaration specifiers.

 * void 

 * char 

 * signed char 

 * unsigned char 

 * short , signed short , short int , or signed short int 

 * unsigned short , or unsigned short int 

 * int , signed , signed int , or no type specifiers 

 * unsigned , or unsigned int 

 * long , signed long , long int , or signed long int 

 * unsigned long , or unsigned long int 

 * float 

 * double 

 * long double 

 * struct-or-union specifier 

 * enum-specifier 

 * typedef-name

Semantics

   Specifiers for structures, unions, and enumerations are discussed
in $3.5.2.1 through $3.5.2.3.  Declarations of typedef names are
discussed in $3.5.6.  The characteristics of the other types are
discussed in $3.1.2.5.

   Each of the above comma-separated lists designates the same type,
except that for bit-field declarations, signed int (or signed ) may
differ from int (or no type specifiers).

You'll note that the three char types are each in their own list. In other words, they are different types, and thus incompatible wrt type coercions. Note that type coercion in assignment is not the same as type promotion in expressions.