Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

printf("hello");

0 views
Skip to first unread message

BigZero

unread,
Sep 2, 2008, 1:27:47 AM9/2/08
to
hello ppl,

can any body help how printf(""); internal works, i had one
problem with printf, is printf ay thing to do with memory allocation
or something to do with malloc() function.

Thanks
VM

Bill Marcum

unread,
Sep 2, 2008, 7:05:50 AM9/2/08
to
You can read the source code of libc6, but perhaps you could say what
your problem with printf was. Maybe it had something to do with locale?

BigZero

unread,
Sep 2, 2008, 10:14:28 AM9/2/08
to
but perhaps you could say what
> your problem with printf was. Maybe it had something to do with locale?

ok here is the problem...ok i have the 32 bit grep-2.5 code and i m
porting that into 64 bit.her the small problem when allocate memory

[code]
/* Allocate N bytes of memory dynamically, with error checking. */

void *
xmalloc (size_t n)
{
void *p;
printf("Magic");
p = malloc (n);
if (p == 0)
xalloc_die ();
return p;
}
[/code]

will this code work fine allocates memory and grep works fine and you
get the result too, here the code that has the problem.

[code]
/* Allocate N bytes of memory dynamically, with error checking. */

void *
xmalloc (size_t n)
{
void *p;
p = malloc (n);
if (p == 0)
xalloc_die ();
return p;
}
[/code]

when you remove the printf() it allocates or gives array out of bound
exception as we known as a "segmentation fault".
so i wanted to known what actual the printf is doing here.

thanks
VM

Nathan Seese

unread,
Sep 4, 2008, 9:02:11 PM9/4/08
to
I think they show a /possible/ implementation of printf() in k&r, which
you really need anyway if you're writing C.

--
The preceding message is brought to you by Water(TM)

BigZero

unread,
Sep 5, 2008, 3:04:06 AM9/5/08
to
> you really need anyway if you're writing C.
well i told you that i m porting any 32 bit application to 64bit
application.....


Thanks
VM

Robert Riches

unread,
Sep 6, 2008, 1:09:12 AM9/6/08
to

The personality() system call may end up being your friend.
It was mine when I got the 32-bit-only-and-proud-of-it
Squeak Smalltalk implementation working on my 64-bit DEC
Alpha a few years ago.

--
Robert Riches
spamt...@verizon.net
(Yes, that is one of my email addresses.)

BigZero

unread,
Sep 6, 2008, 5:44:17 AM9/6/08
to

> The personality() system call may end up being your friend.
> It was mine when I got the 32-bit-only-and-proud-of-it

well thanks for that, but what is it?

Ray

unread,
Sep 6, 2008, 11:15:20 AM9/6/08
to

yes, printf will CAN internal malloc (i can't remember ever seeing
this specified in the manpages on any of the unices i have worked
on).. if you want to be sure that there is no allocations you should
use sprintf

struct iov iv;
char buf[1000];
iv.iov_base = buf;
iv.iov_len = snprintf(buf, 1000, "....");
writev(STDIO_FILENO, &iv, 1);

this is very simplified code (no err check etc) but with the local
stack buffer being used you can ensure that your write to stdout wont
alloc any memory -- i may be wrong about the sys call write(2) but i
belive it do NOT guarantee that there is no copy of the buf passed to
it and i believe that the scatter writev will use ensure that there is
no buffer copy at the system level.

however, if you are experiencing problem with printf() i would suggest
that it might be an application problem rather than a printf() problem

Ray

unread,
Sep 6, 2008, 11:17:13 AM9/6/08
to
On 2 Sep, 12:05, Bill Marcum <marcumb...@bellsouth.net> wrote:

oh yes, and if you care enough about checking the printf()'s
potentially allocation you should use strace to see what system calls
are being hit at the time your printf happens -- watch out for brk()
system calls which will be the system providing memory back to the
processes (more specifically extending the virt address space of the
process)

Robert Riches

unread,
Sep 6, 2008, 12:40:45 PM9/6/08
to

Do you not have access to man pages or a search engine?
Unless you're paying me to spoon feed you, you need to be
doing a little bit of the work yourself. Please try the
following two commands:

man man
man personality

Putting the following into Google's search term field should
find useful hits:

linux personality "system call"

The personality() system call changes some things about how
the kernel interacts with the application. In my case, when
I worked on getting 32-bit-only Squeak (free Smalltalk)
working on a DEC Alpha, I added a call to personality() at
the very beginning of main() to tell the kernel to act like
a 32-bit Linux environment, so malloc() would return memory
in the lower 2-4GB of the address space. Then, when Squeak
stuffed a pointer into an 'int' variable and then later took
it back out and put it back into a pointer variable and then
used the pointer, everything worked as the program had
intended. (In the case of the DEC Alpha, I had to also use
the -taso or '-w taso' compilation option. I also had to
hack Squeak's configuration script to recognize Alpha as
little endian rather than big endian.)

HTH

BigZero

unread,
Sep 8, 2008, 3:17:55 AM9/8/08
to
Thanks, now i belive it time to learn, more then what i think.....


Thanks
VM

0 new messages