pointer

pointer

Post by Chris Redfiel » Mon, 01 Mar 1999 04:00:00



Maybe a stupid question for you unix gurus but there's something I don't
understand.
Well, I've programmed many things under dos using this method:

#include<stdio.h>
main()
{
char *pstring;
printf("enter your string: ");
scanf("%s",pstring);
printf("you have written %s", pstring);

Quote:}

When I compile it with gcc, it doesn't work. I get something like that:

you have written (null)
Please help me !!!

thanks

 
 
 

pointer

Post by Eric Amic » Mon, 01 Mar 1999 04:00:00



> Maybe a stupid question for you unix gurus but there's something I don't
> understand.
> Well, I've programmed many things under dos using this method:
> #include<stdio.h>
> main()
> {
> char *pstring;
> printf("enter your string: ");
> scanf("%s",pstring);
> printf("you have written %s", pstring);
> }
> When I compile it with gcc, it doesn't work. I get something like that:
> you have written (null)
> Please help me !!!

Now that you're using a real operating system, you've discovered a bug in
your code that was there all along.  pstring is a pointer that doesn't
point to anything in particular, so it's no wonder trying to store data
through it isn't working.  Make pstring an array, and you'll find it works
much better.  You should also switch to using fscanf() or fgets() to read
the input, because scanf() has no protection about exceeding the size of
the destination array.

--
Eric Amick
Columbia, MD


 
 
 

pointer

Post by Klaus Schillin » Tue, 02 Mar 1999 04:00:00




> > Maybe a stupid question for you unix gurus but there's something I don't
> > understand.
> > Well, I've programmed many things under dos using this method:

> > #include<stdio.h>
> > main()
> > {
> > char *pstring;
> > printf("enter your string: ");
> > scanf("%s",pstring);
> > printf("you have written %s", pstring);
> > }

> > When I compile it with gcc, it doesn't work. I get something like that:

> > you have written (null)
> > Please help me !!!

> Now that you're using a real operating system, you've discovered a bug in
> your code that was there all along.  pstring is a pointer that doesn't
> point to anything in particular, so it's no wonder trying to store data
> through it isn't working.

How about mallocing a buffer first?

Quote:>  Make pstring an array, and you'll find it works
> much better.  You should also switch to using fscanf() or fgets() to read
> the input, because scanf() has no protection about exceeding the size of
> the destination array.

On GNU systems, getline and getdelim rock more than fgets, because of not
requiring to specify a buffer size in advance.
--
Klaus Schilling
 
 
 

pointer

Post by J. Ben » Tue, 02 Mar 1999 04:00:00



> On GNU systems, getline and getdelim rock more than fgets, because of not
> requiring to specify a buffer size in advance.
> --

But that's the very reason you should be using them.  Because you *can* specify
a size.  If getline() don't know how big the buffer is, what keeps them from
writing junk all over the memory?  What happens if the user falls asleep on the
keyboard?

And just what is a 'GNU system'?  I wasn't aware that GNU had started
manufacturing systems...

What you are referring to is a compiler extension to C - not recommended if you
ever want to write software that runs on more than one machine.

 
 
 

pointer

Post by Steven M. Gal » Tue, 02 Mar 1999 04:00:00




Quote:>Maybe a stupid question for you unix gurus but there's something I don't
>understand.
>Well, I've programmed many things under dos using this method:

>#include<stdio.h>
>main()
>{
>char *pstring;
>printf("enter your string: ");
>scanf("%s",pstring);
>printf("you have written %s", pstring);
>}

>When I compile it with gcc, it doesn't work. I get something like that:

>you have written (null)

You have declared a pointer to a character but have not allocated any memory
for the string.

If you use char pstring[512], it will work as long as you don't exceed
512 characters.  You might want to use the fgets() function instead since
you can tell it the maximum number of characters that you should read.

UNIX probably does much better memory access checking than DOS - I'm
surprised that your program didn't just crash.

Steve

 
 
 

pointer

Post by Barry Margoli » Tue, 02 Mar 1999 04:00:00




>> On GNU systems, getline and getdelim rock more than fgets, because of not
>> requiring to specify a buffer size in advance.
>> --

>But that's the very reason you should be using them.  Because you *can* specify
>a size.  If getline() don't know how big the buffer is, what keeps them from
>writing junk all over the memory?  What happens if the user falls asleep on the
>keyboard?

From the GNU libc documentation:

  Before calling getline, you should place in *lineptr the address of a
  buffer *n bytes long, allocated with malloc. If this buffer is long
  enough to hold the line, getline stores the line in this buffer.
  Otherwise, getline makes the buffer bigger using realloc, storing the new
  buffer address back in *lineptr and the increased size back in *n. See
  section Unconstrained Allocation.

  If you set *lineptr to a null pointer, and *n to zero, before the call,
  then getline allocates the initial buffer for you by calling malloc.

  In either case, when getline returns, *lineptr is a char * which points
  to the text of the line.

  When getline is successful, it returns the number of characters read
  (including the newline, but not including the terminating null). This
  value enables you to distinguish null characters that are part of the
  line from the null character inserted as a terminator.

This function is one reason why many GNU programs don't have hard-coded
limits on input line length.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

pointer

Post by Aaron Cra » Tue, 02 Mar 1999 04:00:00




> And just what is a 'GNU system'?  I wasn't aware that GNU had started
> manufacturing systems...

I'm writing this on a GNU system.  Specifically, it's a Debian-distributed
GNU system with a Linux kernel, or Debian GNU/Linux system for short.
Debian also do GNU/Hurd systems.  The Free Software Foundation have a beta
release of their own GNU/Hurd system.

--

 ** Please send on-topic followups by Usenet, not email **

 
 
 

pointer

Post by Nate Eldredg » Tue, 02 Mar 1999 04:00:00




> > On GNU systems, getline and getdelim rock more than fgets, because of not
> > requiring to specify a buffer size in advance.
> > --

> But that's the very reason you should be using them.  Because you *can* specify
> a size.  If getline() don't know how big the buffer is, what keeps them from
> writing junk all over the memory?  What happens if the user falls asleep on the
> keyboard?

No, you misunderstand.  `getline' works like this:

ssize_t getline (char **bufptr, size_t *bufsize, FILE *f);

You create a malloc'ed buffer (or use NULL) and pass the pointer and the
buffer's size by reference.  `getline' will read an entire line,
expanding the buffer by `realloc' if necessary, updating the pointer and
size, and returns the number of bytes actually read.

So you never have to deal with a fixed line length.  If the user falls
asleep on the keyboard, you'll run out of memory and `getline' will
fail, just like the user deserves :)

Quote:> And just what is a 'GNU system'?  I wasn't aware that GNU had started
> manufacturing systems...

Well... make that "any system using a GNU libc".

Quote:> What you are referring to is a compiler extension to C -

A library extension, actually.

Quote:> not recommended if you
> ever want to write software that runs on more than one machine.

Agreed--but very convenient for in-house use.  
--

Nate Eldredge

 
 
 

1. 2.4.5-ac9 console NULL pointer pointer dereference

Hi,

this happend with 2.4.5-ac9 with serial console on i386.

Full boot log and config can be found here:
http://www.penguinppc.org/~olaf/bugs/245-ac9/

ksymoops 2.4.1 on i686 2.4.6-pre1.  Options used
     -v /usr/src/OLAF/linux-2.4.5-ac9/vmlinux (specified)
     -K (specified)
     -L (specified)
     -O (specified)
     -m /usr/src/OLAF/linux-2.4.5-ac9/System.map (specified)

 WARNING: unexpectC, please mail
cpu: 0, clocks: 1001790, slice: 500895
ttyS1 at Unable to handle kernel NULL pointer dereference0x02f8 (irq = 3) at virtual address 00000004
Oops: 0000
CPU:    0
EIP:    0010:[<c01967c7>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000000   ebx: c1231fa4   ecx: 00000202   edx: 00000000
esi: c1231fa4   edi: c1230332   ebp: c1230000   esp: c1231f8c
ds: 0018   es: 0018   ss: 0018
Process keventd (pid: 2, stackpage=c1231000)
Stack: c0195a67 c1231fa4 c0119a5c 00000000 c1230650 c1231fe0 c025a5c4 c025a5c4
       c0120f97 c0252d20 00000700 c123ffc4 00000000 0008e000 c1230650 c1230640
       00000001 00000000 00000000 00010000 00000000 00000000 c1230000 c0252d2c
Call Trace: [<c0195a67>] [<c0119a5c>] [<c0120f97>] [<c01056cc>]
Code: 80 78 04 01 74 39 83 3d 00 43 2d c0 00 74 11 a1 88 52 2c c0

Trace; c0195a67 <console_callback+5f/b0>
Trace; c0119a5c <__run_task_queue+60/74>
Trace; c0120f97 <context_thread+127/1c4>
Trace; c01056cc <kernel_thread+28/38>
Code;  c01967c7 <poke_blanked_console+1b/5c>
00000000 <_EIP>:
Code;  c01967c7 <poke_blanked_console+1b/5c>   <=====
   0:   80 78 04 01               cmpb   $0x1,0x4(%eax)   <=====
Code;  c01967cb <poke_blanked_console+1f/5c>
   4:   74 39                     je     3f <_EIP+0x3f> c0196806 <poke_blanked_console+5a/5c>
Code;  c01967cd <poke_blanked_console+21/5c>
   6:   83 3d 00 43 2d c0 00      cmpl   $0x0,0xc02d4300
Code;  c01967d4 <poke_blanked_console+28/5c>
   d:   74 11                     je     20 <_EIP+0x20> c01967e7 <poke_blanked_console+3b/5c>
Code;  c01967d6 <poke_blanked_console+2a/5c>
   f:   a1 88 52 2c c0            mov    0xc02c5288,%eax

Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Network browsing across sub-nets

3. allocating memory for pointer to pointers

4. COMMERCIAL: Slackware Pro 2.1 corrections

5. Soln: Mouse pointer lacks white border (black pointer on black background)

6. changing name of net_device

7. pointers to pointers

8. MP3 compat. w/SBPRO?

9. Pointer to a pointer - Trying to understand...

10. casting pointer to derived class to pointer to base class problem in C++ using xlC_r 5.0.2.0

11. doubt about array of pointers

12. vnode pointer to inode number

13. EXT_fs panic ext2_find_entry: buffer head pointer is NULL