I recently encountered this problem: that you practically can't copy a sub-bitmap or create another sub-bitmap with the same properties of an existing one. For further information read this thread.
This might be an overlooked feature; Thus my suggestion to add one of those functions to get a sub-bitmap duplicate in case you can't just copy the pointer.

Just remember not to use system or video bitmaps with the duplicate function otherwise it won't work

btw, why isn't there a load_bmp set of functions to go directly to system or video bitmaps? I find I have to load up the bitmap into a temporary variable, create a new video/system bitmap, copy over the bitmap then destroy the original loaded one.

I know, but my second example has the same effect as that, except that the parent is technically not the parent of the original subbitmap but another subbitmap. The behavior is the same though for practical purposes.

What I might consider missing from the API is a way to get the parent BITMAP * of a child, but I'm not sure that it's something you would generally need to know or should care about.

So, with the current docs, I'd say it is a mistake deleting the parent of a sub-bitmap (even if the parent is a sub-bitmap). Of course, a simple addition to the docs might be enough to allow it

The sub-bitmap could theoretically (I think in practice never) be created by the gfx or system drivers, and who knows what they could get up to.

But why do you need to duplicate sub-bitmaps?

I didn't know that it would cause the same behaviour, else I wouldn't have spent several days searching for a way to copy my sub-bitmaps. I could not simply copy the pointer because I was using wrapper classes for the bitmap types. In the copy-constructor of my sub-bitmap class, I used to just copy the pointer until the first sub-bitmap got destroyed before I used the second one. And there was no mention in the documentation of any way to obtain a sub-bitmap except the create_sub_bitmap() function.

Meanwhile, the problem is gone. I fixed the copy-constructor to do what you did in your second example.

Also, in my opinion it is not right to assume this to work because obviously create_sub_bitmap() wasn't necessarily intended to produce such behaviour. Should the implementation of the function ever change, it might stop working. Thus, it is a hack. If there was a function dedicated to copying sub-bitmaps, I would know that it was always guaranteed to work; and anyone else who might one day encounter this problem wouldn't need to ask for the hack or use even uglier workarounds.

Is the following code be guaranteed to work?

BITMAP *duplicate_bitmap(BITMAP *bmp)
{
   BITMAP *bmpc = NULL;
   ASSERT(bmp);
   bmpc = create_sub_bitmap(bmp, 0, 0, bmp->w, bmp->h);
   return bmpc;
}

BITMAP* parent, *child1, *child2;
parent = create_bitmap(100, 100);
child1 = create_sub_bitmap(parent, 0, 0, 100, 100);
child2 = create_sub_bitmap(child1, 0, 0, child1->w, child1->h);
destroy_bitmap(child1);
blit(child2, screen, 0, 0, 0, 0, child2->w, child2->h);
destroy_bitmap(child2);
destroy_bitmap(parent);

If it isn't, his problem still stands.

Yes, but the original problem was that parent was not available, so he had to actually duplicate a sub-bitmap.

Well, think about it: the original subbitmap refers to an area of the parent bitmap (they share the same drawing surface). So any bitmap that shares a drawing surface with the subbitmap shares a drawing surface with the parent bitmap.
Hence, the behavior is the same.

Maube I'm dense, but I still don't understand what it is exactly that you're trying to do and why you cannot keep the old subbitmap around.
Could you explain again why this is so useful?
Personally, I think the ability to copy bitmaps in general is more useful and would make more sense to have than the ability to duplicate subbitmaps per se, and that is something which is easily done through blit (and not really a missing feature).

What are you doing that makes it nescessary to recreate a sub-bitmap regularly?
Note that you can duplicate much of the functionality of sub-bitmaps by using the source offset parameters of blit() and clipping rectangles. Doesn't mean that subbitmaps aren't useful (they certainly are), just that maybe what you're doing could be better done in another way.