Query on pointers

[ajinkya.coep]

What's wrong with this program? If you were to fix it, what would the
intended output be?

void swap(char *str, int index1, int index2) {
char tmp = str[index1];
str[index1] = str[index2];
str[index2] = tmp;
}

int main(int argc, char *argv[]) {
char *planet1;
char *planet2;

planet1 = (char *) malloc(7 * sizeof(char));
if (!planet1)
return 0;

snprintf(planet 1, 7, "Jupiter");
planet2 = "Saturn";

swap(planet1, 0, 3);
swap(planet2, 3, 4);

printf("results : %s and %s\n", planet1, planet2);
return 0;
}

My interpretation : In turboc3 compiler(though it is a dead compiler
now) this problem is perfectly fine and we
get the o/p :

results: iupJter and Satrun

But in Bloodshed Dev C++ the code compiles fine but on
execution there is an error report generated.

swap(planet1,0, 3) works fine but there is some problem
with swap(planet2,3, 4)

Only when i allocate space for planet2 and perform
snprintf on planet2 i get the expected result.

Why do we need snprintf in this case....why does
planet2="Saturn " not work?

PS:Pls send your comments and correct me if i am wrong...i am working
on this problem for 2 long days.

[CBFalconer]

ma**********@po box.com wrote:

On 4 May, 15:23, Kenneth Brody <kenbr...@spamc op.netwrote:

>Also, your 7-byte buffer for the 8-byte string "Jupiter" (with the
'\0' terminator) "works" only by luck. The runtime library is
probably allocating more than 7 bytes, in order to handle proper
alignment, so you happen to have additional memory after your 7
bytes, and the 8th byte happens to be zero. Otherwise, the final
printf() wouldn't have stopped after the 7 characters "iupJter".
It would have kept going until it hit a '\0' or crashed.

I think, indeed I'm fairly sure, you are mistaken.

The snprintf() call will move "Jupite" into the buffer allocated,
and then add the null character to make it a legal C string.

Either the original poster is mistaken about the output from turboc,
or it's broken.

It probably worked because malloc allocated a multiple of 8 (or 4)
bytes. No guarantees.

And no, the snprintf doesn't know the size of the buffer. All it
has is what you tell it, and pointers to the buffer beginning. It
wasn't designed to handle strings.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Bart van Ingen Schenau]

Ajinkya wrote:

On May 4, 10:13 am, Bart van Ingen Schenau <[e-mail] s.info>
wrote:

>ak wrote:

Check it on any "decent" compiler snprintf() moves "Jupiter" and
not "Jupite" ....i think you are mistaken.

Then you have a strange notion of 'decent compiler'.
Any *conforming* implementation, will truncate the string to
"Jupite", as that is what the standard requires for snprintf().

Bart v Ingen Schenau

wont you call Bloodshed Dev C++ a "decent" compiler....... i know
ideally any compiler should not do it but all the compilers i have do
it("Jupiter")

I call it a non-conforming (C99) implementation.
Which does not surprise me, because to my knowledge, it does not claim
conformance to C99.

Whether it is a "decent" implementation, depends on how it copes with
things like this:

* * char planet1[7];
* * snprintf(planet 1, 7, "Jupiter (The big red planet in our solar
system)");

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[Richard Heathfield]

Bart van Ingen Schenau said:

<snip>

Whether it is a "decent" implementation, depends on how it copes with
things like this:

char planet1[7];
snprintf(planet 1, 7, "Jupiter (The big red planet in our solar
system)");

This is rather like judging whether a Formula One car is "decent" by
smacking it into the wall at 200mph to see if the air-bag goes off.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Kenneth Brody]

ma**********@po box.com wrote:

>
On 4 May, 15:23, Kenneth Brody <kenbr...@spamc op.netwrote:

Also, your 7-byte buffer for the 8-byte string "Jupiter" (with the
'\0' terminator) "works" only by luck. The runtime library is
probably allocating more than 7 bytes, in order to handle proper
alignment, so you happen to have additional memory after your 7
bytes, and the 8th byte happens to be zero. Otherwise, the final
printf() wouldn't have stopped after the 7 characters "iupJter".
It would have kept going until it hit a '\0' or crashed.

I think, indeed I'm fairly sure, you are mistaken.

The snprintf() call will move "Jupite" into the buffer allocated, and
then add the null character to make it a legal C string.

Either the original poster is mistaken about the output from turboc,
or it's broken.

Well, some further investigation shows that the FreeBSD man pages say:

The snprintf() and vsnprintf() functions will write at most size-1
of the characters printed into the output string (the size'th
character then gets the terminating `\0'); [...] The output is
always null-terminated.

It also says that snprintf() is C99.

My C90 implementation doesn't even have snprintf(). However, it does
have an _snprintf(), which says:

The _snprintf function formats and stores count or fewer characters
and values (including a terminating null character that is always
appended unless count is zero or the formatted string length is
greater than or equal to count characters) in buffer.

So, it appears that a C99 implementation would put "Jupite". However,
a pre-C99 implementation is not required to do so. Given the fact
that the OP said the output included the 'r' in "iupJter", my guess is
that it is not a C99 implementation, and is not nul-terminating the
string.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Old Wolf]

On May 5, 1:28 am, ajinkya.c...@gm ail.com wrote:

What's wrong with this program? If you were to fix it, what would the
intended output be?

Slightly strange question, as who can know the intended output
except for the person who wrote it?

planet1 = (char *) malloc(7 * sizeof(char));
snprintf(planet 1, 7, "Jupiter");

Something nobody has mentioned yet: you failed to write:
#include <stdlib.h>
#include <stdio.h>

so the above lines cause undefined behaviour.

(Sometimes it can be assumed that these includes were omitted
for brevity, but I don't feel confident the OP knows that these lines
are required).

[Old Wolf]

On May 5, 1:58 am, mark_blue...@po box.com wrote:

On 4 May, 14:28, ajinkya.c...@gm ail.com wrote:

If you were to fix it, what would the intended output be?

I don't know. It's not my program.

planet1 = (char *) malloc(7 * sizeof(char));
if (!planet1)
return 0;

snprintf(planet 1, 7, "Jupiter");

Why you felt the need to use snprintf() rather than strcpy(), or
strncpy(), I can't imagine.

I'm surprised that multiple people made this comment. strcpy
and strncpy would both cause the program to have undefined
behaviour (assuming appropriate headers are included in
all cases, that is).

As it is, snprintf will not cause UB. Conceivably the result is
not the inteded one -- but as you pointed out, we can't know
what the intended result even was.

[Richard Heathfield]

Old Wolf said:

On May 5, 1:58 am, mark_blue...@po box.com wrote:

>On 4 May, 14:28, ajinkya.c...@gm ail.com wrote:

planet1 = (char *) malloc(7 * sizeof(char));
if (!planet1)
return 0;

snprintf(planet 1, 7, "Jupiter");

Why you felt the need to use snprintf() rather than strcpy(), or
strncpy(), I can't imagine.

I'm surprised that multiple people made this comment. strcpy
and strncpy would both cause the program to have undefined
behaviour (assuming appropriate headers are included in
all cases, that is).

Never mind strcpy, strncpy, and snprintf - why he felt the need to use
malloc is beyond me. Simple arrays of char would have done the trick.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.