char *a = "aaa\0bbb";
char *b = "aaa";
char *c = "bbb";

if (a == b) printf ("b %c%c%c \n", b[4], b[5], b[6]);
if (a+4 == c) printf ("c %c%c%c \n", c[-4], c[-3], c[-2]);

If the conditions are true, the first should print "b bbb\n" and the second
should print "c aaa\n".

char const *a = "aaa\0bbb";
char const *b = "aaa";
char const *c = "bbb";

and personnaly, I would do ...

char const *const a = "aaa\0bbb";
char const *const b = "aaa";
char const *const c = "bbb";

... until further notice.

BC 3.1 with "duplicate strings merged" option activated:
D:\CLC\B\BIBER>bc proj.prj
b bbb
c aaa

Test code:
#include <stdio.h>
int main (void)
{
   char const *const a = "aaa\0bbb";
   char const *const b = "aaa";
   char const *const c = "bbb";

   if (a == b)
   {
      printf ("b %c%c%c \n", b[4], b[5], b[6]);
   }

   if (a + 4 == c)
   {
      printf ("c %c%c%c \n", c[-4], c[-3], c[-2]);
   }
   return 0;

Mind you from reviewing your postings in the past you seem to be
slightly paranoid about using const everywhere...

I would be somewhat surprised if a compiler managed to make b and
c *both* equal to a and a+4.  When I wrote up an algorithm to merge
strings -- not for a C compiler, but for the same kind of effect
that a C compiler might achieve by sharing "hello world" with plain
"world" -- I did it by working backwards from the terminating '\0'.
Since all string literals end in this 0, it is a simple matter of
matching the strings backwards until one of them ends.  The algorithm
is therefore linear in the number of string literals involved (or
better, if you make a tree or hash table from the reversed-strings).

In fact its fair to say I don't use const that much at all in C.
Generally if I have a need for a real constant I use a macro, and I'm
not big on writing functions whose arguments are not allowed to be
modified.

I understand what you mean tho, and since I rarely use readonly
objects I rarely use const..

The "usual" (although I have never observed it myself, which some
might say makes it rare at best :-) ) case where this might matter
is in pointers that point to array objects.  Consider:

    unsigned char chessboard[8][8];
    unsigned char (*boardp)[8] = &chessboard[0];

Each board position in boardp[i][j], where 0 <= (i,j) <= 8, denotes
a square on the board.  We "know" (from C arithmetic and object
properties) that chessboard[][] is exactly 64 contiguous bytes,
and something like memcpy() can copy the board to or from a 64-byte
buffer elsewhere.

This implies that boardp[0][k], where 0 <= k < 64, "ought" in some
sense to access the k'th byte in that flat region of memory.  The
C standard implies, however, that a compiler is allowed to "know"
-- via boardp's type -- that boardp[0] itself is only 8 bytes long,
and therefore assume that k is between 0 and 7 inclusive -- and in
turn, generate code that fails at runtime if k is outside this
range.

We might say, then, that &boardp[i][0], for any valid i, is allowed
to be viewed as having a "limitation" of pointing to (the first
of) exactly 8 "char"s.  This "limitation", as I call it, arises
not from the actual target object(s) involved, but from the type
of the variable "boardp".

In this case, however, we had something like this:

    char *a = "aaa\0bbb";
    char *b = "aaa";
    char *c = "bbb";

This produces one to three array objects (depending on how many
string literals are merged) and three pointers, each of type
"char *".  I think the only limitation, as it were, that a compiler
may attach to all three pointer objects is that they point to (the
first of zero or more) "char"(s).