headers
Fábio Russo | 1 Nov 2004 20:03
Picon

Re: buggy_double_use_of _scanf


----- Original Message -----
From: "Glynn Clements" <glynn <at> gclements.plus.com>
To: "simon" <simon.guinot <at> laposte.net>
Cc: "linux-C-programming" <linux-c-programming <at> vger.kernel.org>
Sent: Tuesday, October 26, 2004 6:59 PM
Subject: Re: buggy_double_use_of _scanf

>
> simon wrote:
>
> > I have observe a strange scanf behaviour...
> > when using two successive scanf... the second receive a return character
> >
> > for example :
> >
> > int a;
> > char b;
> >
> > scanf ("%d", &a);
> > fflush (stdin);
> > scanf ("%c", &b);
> > fprintf (stdout, "a : %d\nb : %c\n", a, b);
> >
> > what's the problem ?
>
> What makes you think that there is a problem?
>
> What's the input? If it's a decimal number followed by newline, the
> first scanf() will return the parsed number, the second will return
(Continue reading)

Permalink | Reply | 1 comment |
headers
Glynn Clements | 2 Nov 2004 04:44

Re: buggy_double_use_of _scanf


Fábio Russo wrote:

> > > I have observe a strange scanf behaviour...
> > > when using two successive scanf... the second receive a return character
> > >
> > > for example :
> > >
> > > int a;
> > > char b;
> > >
> > > scanf ("%d", &a);
> > > fflush (stdin);
> > > scanf ("%c", &b);
> > > fprintf (stdout, "a : %d\nb : %c\n", a, b);
> > >
> > > what's the problem ?
> >
> > What makes you think that there is a problem?
> >
> > What's the input? If it's a decimal number followed by newline, the
> > first scanf() will return the parsed number, the second will return
> > the newline.
> 
> 
> The problem, I beleve is in the fflush function. I Have the same behaviour
> with this source code,
> but when I put a additional scanf in the line, all works fine -;)
> 
> Now I ask:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Huber, George K RDECOM CERDEC STCD SRI | 1 Nov 2004 23:25
Picon

RE: buggy_double_use_of _scanf

Hi,

Russo wrote:

[... snip ...]

>The problem, I beleve is in the fflush function. I Have the same behaviour
>with this source code, but when I put a additional scanf in the line, all 
>works fine -;)

>Now I ask:
>Why the fflush function did not remove the new line caracter when it
should?

quoteth the man page:

'The function fflush forces a write of all user-space buffered data for
 the given output or update stream via the stream's underlying write 
 function.'

Thus fflush only causes user-space buffered data to write their contents to 
the kernel-space buffers (which can be forced to update to the storage
medium
via a call to sync or fsync).  fflush has no effect when called on stdin - 
you are reading data not writing it.

George
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
rinku rathore | 2 Nov 2004 08:55
Picon
Favicon

simple printf

hello all,

what may be the out put of simple 

printf("%d");

a garbage value or something else
Regards
Rinku

		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 

-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Glynn Clements | 2 Nov 2004 09:57

Re: simple printf


rinku rathore wrote:

> what may be the out put of simple 
> 
> printf("%d");
> 
> a garbage value or something else

If you don't specify sufficient arguments, the result is "undefined".

On most common platforms, the function will just read whatever happens
to be at the relevant location on the stack. In this specific case,
printf() will just print some unspecified integer.

If the argument was a pointer, or an integer which was used in
computing a memory address (e.g. an array index), you would probably
get a segmentation fault (typically, less than half of the process'
address space is actually mapped to anything, so accessing a random
memory location would be more likely than not to access an unmapped
location).

--

-- 
Glynn Clements <glynn <at> gclements.plus.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
kaushal | 3 Nov 2004 11:14

Re:buggy_double_use_of_scanf

hi
  the following code should solve the scanf issue.

	char s;
	scanf("\n%c",&s);
cheers-
kaushal

-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
zhc | 2 Nov 2004 03:07
Picon
Favicon

How to open a large file

How to open and creat a big file over 2 GB in linux with c language. I 
have tried open() with O_LARGEFILE option in it, but the program 
couldn't be compiled successfully. Are there other ways to solve the 
problem?

Thanks

Zhenghongchao

-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Glynn Clements | 4 Nov 2004 05:21

Re: How to open a large file


zhc wrote:

> How to open and creat a big file over 2 GB in linux with c language. I 
> have tried open() with O_LARGEFILE option in it, but the program 
> couldn't be compiled successfully. Are there other ways to solve the 
> problem?

You have to define _LARGEFILE_SOURCE in order for the O_LARGEFILE flag
to be defined, i.e. "gcc -D_LARGEFILE_SOURCE ...".

If you only need to perform sequential access, that macro is all that
you need.

However, if you wish to be able to perform random access (e.g. 
lseek()), you will need to use 64-bit file offsets, so you also need
to define _LARGEFILE64_SOURCE. That macro will enable the off64_t type
and 64-bit versions of various functions (open64, lseek64 etc).

One further macro, _FILE_OFFSET_BITS, determines whether off_t and the
common I/O functions (open, lseek etc) are the 64-bit versions (i.e. 
off64_t, open64, lseek64) or the normal versions.

Adding -D_FILE_OFFSET_BITS=64 to the compilation switches will result
in off_t, open, lseek etc all being the 64-bit versions. The code will
automatically handle large files.

One final note: if your code supports large files, you must take care
when passing file descriptors or file offsets to libraries. If they
weren't compiled with those options, they will be expecting file
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Souza | 5 Nov 2004 08:15
Picon
Gravatar

write arbitraty data to a running process memory

hi, im getting a bit confused about somethings... first, looks to me
that under >= 2.4 kernels, we cant mmap() a /proc/pid/mem file... (not
tested by me, just heard at linux-kernel mailing list) so, there's a
way to write to a running process memory (without use ptrace will be
better, because its disabled in some systems) ? for example, supposing
that there is a little program running as pid 1000, that has a little
buffer of 1024 bytes at address 0x80486ab... and I want to access the
content of that buffer via /proc/1000/mem. How can I calculate the
offset that I need start reading within the memory file that will be
exactly the start of the buffer ? how can I calculate the
correspondent areas of /proc/1000/maps into /proc/1000/mem (if that
maps are really in the mem file) ? like...

root <at> fooboo:~# cat /proc/1000/maps
08048000-08057000 r-xp 00000000 03:06 13385      /root/fooboo-bin
08057000-08059000 rw-p 0000f000 03:06 13385      /root/fooboo-bin
08059000-0805c000 rwxp 00000000 00:00 0
40000000-40014000 r-xp 00000000 03:06 12031      /lib/ld-2.3.2.so
40014000-40015000 rw-p 00013000 03:06 12031      /lib/ld-2.3.2.so
40015000-40016000 rw-p 00000000 00:00 0
4001f000-40147000 r-xp 00000000 03:06 12065      /lib/libc-2.3.2.so
40147000-4014b000 rw-p 00128000 03:06 12065      /lib/libc-2.3.2.so
4014b000-4014e000 rw-p 00000000 00:00 0
bffff000-c0000000 rwxp 00000000 00:00 0

I want to know that, for example, the range of each map in the mem file... like
08048000-08057000 r-xp 00000000 03:06 13385      /root/fooboo-bin
starts at offset 0xAAAAAAAA and ends at 0xBBBBBBBB in the /proc/1000/mem file

And other things, like... where the stack begins within /proc/1000/mem
(Continue reading)

Permalink | Reply | 1 comment |
headers
Glynn Clements | 5 Nov 2004 08:53

Re: write arbitraty data to a running process memory


Daniel Souza wrote:

> hi, im getting a bit confused about somethings... first, looks to me
> that under >= 2.4 kernels, we cant mmap() a /proc/pid/mem file... (not
> tested by me, just heard at linux-kernel mailing list) so, there's a
> way to write to a running process memory (without use ptrace will be
> better, because its disabled in some systems) ?

A process can only read/write a /proc/≤pid>/mem file if the process
to which <pid> refers is either:

a) the current process, or
b) a child of the current process which is being ptrace()d.

See the file fs/proc/base.c in the kernel source code.

--

-- 
Glynn Clements <glynn <at> gclements.plus.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane