Array manipulation.

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
I want to manipulate some array type variables.

char first[6] = {"01234"};
char second[6] = {"56789"};
char *third;

char third = malloc(11);
strcpy(third,first);
strcat(third,second);

It's simple. Right after strcpy, on variable "third" i've got "01234". And after strcat, on variable "third" i've got "0123456789".
but i want to do something like this:

strinsert(third,second,3);

So the result on variable "third" will be "0125678934". is there any default function to do this?

KISS - Keep It Simple Stupid!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AFAIK, there is no such standard function. You'll have to write those (few) lines yourself.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

:shock:
Oh my..
Ok then I'll wrote it..

KISS - Keep It Simple Stupid!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just sketching, not sure about missing +1's and such on indexes, but something like this maybe? :

char * strinsert(char * s1, char * s2, int insertpos)
{
   char * result = malloc(strlen(s1) + strlen(s2) + 1);
   strncpy(result, s1, insertpos);
   strcat(result + strlen(result), s2);
   strcat(result + strlen(result), s1 + insertpos);

}

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan gave you a good outline sketch. However, not that I'm cautious or anything...

but I wouldn't use malloc() inside a function that doesn't also free() the memory. Use malloc in the calling function and pass the value to strinsert. Or, better still, don't use malloc() at all!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess the "unseen" bit of John's solution is where he strcpy()'s 'result' back to 's1' then free()s 'result'?

(the worrying thing here is that 's1' must have been allocated before the call large enough to accomodate both strings - I think I'd insist on the sizeof(s1) also being passed in and used for the malloc of the working copy and wrok being done to truncate stuff if the combined solution won't fit)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, I know. While walking the dog this evening I suddenly realised that I didn't return the result. Dog-walking can have strange spin-offs...

As the OP seketched a malloc without a free, so did I. From OPs sketch it looked as though he didn't want any of the two original strings destroyed, so my intention was to return a pointer to the malloced string. I have no major problem with making a malloc in the function without a free as long as this is clearly documented.

For maybe faster, and smaller, code one could do it all with a few for loops instead of calling strcpy/strcat (of course).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pretty dangerous coding style.

Better safe than sorry. Malloc of small hunks is bad form on a small-RAM micro. Causes a cluttered mess of non-contatenated free()'d blocks after some time.

if these strings are to be UART'd or LCD'd, better to use printf() formats to do this stuff. Or sprintf() for destination = ram.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Steve,

I know Joerg has stronger views on this but if this were the only malloc/free being used then fragmentation would not occur. It's when things remain malloc'd then other malloc's occur before the first is freed that the heap might begin to fragment.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, all right then...

char * strinsert(char * s1, char * s2, int insertpos, char * result)
{
   strncpy(result, s1, insertpos);
   strcat(result + strlen(result), s2);
   strcat(result + strlen(result), s1 + insertpos);
   return result;
}

:wink: : Now let's argue over if the result value should go as the last parameter or if it rather should be

char * strinsert(char * result, char * s1, char * s2, int insertpos)

to follow the scheme of the standard strwhatever functions.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The buffer overrun is arguably a much more dangerous condition than heap frag. Consider including the buffer length as a parameter.

C: i = "told you so";

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gee thanks for all your input. I didn't expect many replies like these since i've written my own function that looks similar to Johan's, but then i changed my own code to for-loop style for a better size. Yes it is smaller. Don't know why, but it works.
Thanks.

KISS - Keep It Simple Stupid!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Yes it is smaller. Don't know why

The answer could be found by studying the generated assembler, but I suspect part of it will be because you got rid of a bunch of function calls.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]