How to left pad a string with spaces?

[nospam]

If I have a string say:

myvar[128] = "This is a string";

How do I use sprintf to convert the string so it has 4 spaces padded on
the left like:

" This is a string";
Thanks!

[Richard Heathfield]

CBFalconer said:

<snip>

I guess I am getting sloppy.

It's been happening for some time.

Well, I did
mark it 'untested', and say 'something like this'. :-)

In future, please mark it "tested", and say "exactly like this", and try to
ensure that those claims will stand up to expert scrutiny.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ben Bacarisse]

Ben Bacarisse <be********@bsb .me.ukwrites:

Barry Schwarz <sc******@dqel. comwrites:

>On Tue, 10 Jun 2008 19:27:31 +0100, Ben Bacarisse
<be********@bs b.me.ukwrote:

>>>Barry Schwarz <sc******@dqel. comwrites:

<snip>

>>>As long as your array is at least twice as long as (your string plus
the number of spaces to insert):
sprintf(myvar+6 4, "%s", myvar);
sprintf(myvar, " %s", myvar+64);

I don't think that is permitted:

7.19.6.6 The sprintf function

... If copying takes place between objects that overlap, the
behavior is undefined.

It does not say "between /regions/ of objects that overlap". It seems
any overlap is enough to render it undefined.

It seems that the term "object" is not used with great precision
here.

I have to think that may be deliberate. See below...

>What would happen if myvar were defined as
char myvar[2][64] = {"This ..."};
and in the calls to sprintf each use of myvar was cast to char*?
myvar[0] and [1] are objects that do not overlap but both are part of
the object myvar. Is this overlap? Would it be overlap if the
arguments were changed to myvar[0] and myvar[1]?

<snip>

>I will assert that the intent of the word object in this section is
meant to refer to the source and destination strings and therefore
under the conditions I postulated there is no overlap.

And I now agree.

These are good points, but I think the wording is clear that the
behaviour is undefined. The intent may not be this wide, but the word
"object" must mean the whole object, surely?

The definition of "object" is very loose: "region of data storage in
the execution environment, the contents of which can represent
values". Thus within an object declared: 'char obj[128];' there
are many other objects. Each char is an object as well as the whole
thing, but the region from obj[3] too obj[30] (inclusive) is also an
object. In deciding if "objects overlap" there are therefore two ways
to go: define "the objects" as the smallest ones involved in the copy,
or define them as the largest. Anything else is rather arbitrary.

It seems obvious to me, now, that the intent is that the smallest
objects be the ones that need to be overlap-free. So, in short,
forget my objection!

--
Ben.