I've been struggling with accomplishing this probably simple issue for some time now and can't figure it out. I don't understand the math in connecting 4 lines with arcs due to my limited knowledge in math.
Given this arc routine below, I'm trying to make a rounded rectangle using it.
(note that this isn't in allegro and I'd prefer it not to be since I'm not using it for this):

I'd like to be able to have my round rect routine to be something like:

void doRoundRect(int x, int y, int width, int height, float radius)
{
        doLine(x+radius, y, x+width-radius, y);
  doLine(x+radius, y+height, x+width-radius,y+height);
  doLine(x, y+radius,x, y+height-radius);
  doLine(x+width, y+radius,x+width, y+height-radius);
        // Needs arcs
}

Perhaps my arc routine is bad? Any suggestions?

This is what I made a while ago and it looks just like vbovio's

Are you trying to get a working function, or to understand the math of an arc-drawing function?

For a working function, just use vbovio's code.

For the math of an arc-drawing function:

the first fix I proposed contained 2 errors that I've noticed:
1a: I didn't change the starting value of k to 0 (I don't know why it was 1, but that isn't right). Otherwise, the function skips the last segment.
1b: I forgot to multiply the distance from the center by the radius.
Thus:

    for(unsigned int k = 1; k < segments; k++)
    {
      angle += angleInc;
      cx = centerX + cos(angle);
      cy = centerY + sin(angle);
      doLine(oldcx,oldcy,cx,cy,color);
      oldcx = cx;
      oldcy = cy;
    }

should be:

    for(unsigned int k = 0; k < segments; k++)
    {
      angle += angleInc;
      cx = centerX + radius * cos(angle);
      cy = centerY + radius * sin(angle);
      doLine(oldcx,oldcy,cx,cy,color);
      oldcx = cx;
      oldcy = cy;
    }

The idea here is that we break up our arc of D degrees into N sub-arcs of D/N degrees, and we aproximate each subarc with a straight line connecting the endpoints. Each endpoint is calculated separately.

The second, alternative fix I proposed contains... flaws...
Just to be clear, the second fix, the one where the angle had PI/2 added to it to so that the angle was the angle along the edge rather than from the center, should NOT be combined with the first fix. They are alternatives to each other.
Anyway, the flaws:
2a. The names I used were misleading, chosen just to make the code changes as small as possible. Radius wasn't really conceptually divided by the number of segments, it's just that the scale of how far (cx,cy) was from the previous position for each segmented needed to be divided by the number of segments. New variables could be declared to hold the segment length to fix this... non-bug, but still an issue.
2b. even so, the segment length calculated was still wrong. Instead of radius/segments it should be something like... radius*angleInc, but, actually, even that only works if angleInc is small, otherwise the math is messier... maybe radius * sqrt(sqr(sin(angleInc)) + 1 + sqr(cos(angleInc)) - 2*cos(angleInc))... or maybe... equivalently?... radius * sin(angleInc) / sin((PI-angleInc)/2)... bleh, I'm getting confused
so... don't use method 2. it's too much work.
2c. the angle used was the angle at the point on the circle in question, ie the begining of each subarc, should have been the angle along the middle of the subarc... can fix by adding angleInc/2

The idea of the second method was generally similar...
we break up our arc of D degrees into N sub-arcs of D/N degrees, and we aproximate each subarc with a straight line connecting the endpoints.
The difference is that endpoints are not calculated seperately... instead the first endpoint is calculated, and we figure that the arc is a line curving at a fixed rate, so we can calculate further endpoints progressively from the previous one. But this introduces an extra problem, because for this method we need to know the straight-line distance between each pair of endpoints, and that's a little messy to calculate... my best guess is radius * sin(angleInc) / sin((PI-angleInc)/2) (which, if angleInc is small, is aproximately radius * angleInc)

You could just take the rounded rectangle rendering code from OpenLayer

Search for the part which begins: if( roundness > 0.0 )

look for SuperEllipse equation; and SuperQuadrics in general, you can find interesting shapes using their equations, rounded rects can be achieved with superellipses.