Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: tlug: gcc question
- To: tlug@example.com
- Subject: Re: tlug: gcc question
- From: Fredric Fredricson <Fredric.Fredriksson@example.com>
- Date: Thu, 13 Jan 2000 12:15:31 +0100
- Content-Type: multipart/mixed;boundary="------------B2B42389C09F461C35420627"
- Organization: MYDATA automation
- References: <Pine.LNX.4.10.10001121547550.26141-100000@example.com>
- Reply-To: tlug@example.com
- Sender: owner-tlug@example.com
"Scott M. Stone" wrote: > > On Wed, 12 Jan 2000, Fredric Fredricson wrote: > > > I would say this question is more appropriate on a c mailing > > list or news group but I will try to answer it anyway: > > > > Your code is broken in a way that will show up differently on > > different OSes. > > > > "Drew C. Poulin" wrote: > > > > > > #include<stdio.h> > > > > > > main(){ > > > > > > char *fname, *lname; > > Defines two pointers to char arrays. Usually the pointers are > > initialized to 0x0000, but you can never be sure.... > > I don't think that gcc/egcs will make programs this way -- every time I've > debugged a program, I've never seen them initialized to NULL - doesn't > mean it doesn't happen sometimes, I've just never seen it... always > initialize your own pointers :) You are right that gcc/egcs, or any c compiler for that matter, does not initialize the pointers but Linux will clear all new pages so in this particular case both pointers will be "initialized" to 0. It is of course a bug to rely on this but I have seem dozens of programs that does (probably/hopefully unintentional). >From a developers point of view it is a good thing that Linux does not allow access to memory address 0. This way uninitialized pointer errors may generate a SIGSEGV and abort the program. > > > It is also important to remember that there is no > > built in bounds checking in c arrays. None. At all. > > C is difficult for a beginner since it is essentially > > a more or less portable assembler on steroids. > > therefore, never use gets() - if I do: > > char *foo; > foo=(char *)malloc(80); /* (or do char foo[80];) */ > memset(foo,0,80); /* zeroes out the string */ > gets(foo); > > and i type in 100 characters -- then what? SIGSEGV, that's right. called > a buffer overrun. I doubt this will happen because the malloc() call will request a full page from the kernel so you will get no SIGSEGV until you reach the end of that page. /Fredricbegin:vcard n:Fredricson;Fredric tel;fax:+46 8 475 55 01 tel;work:+46 8 475 55 21 x-mozilla-html:FALSE url:www.mydata.se org:MYDATA automation AB;Development adr:;;Adolfsbergsvägen 11;BROMMA;Stockholm;SE-168 66;Sweden version:2.1 email;internet:fredric@example.com title:Manager System Software R&D fn:Fredric Fredricson end:vcard
- Follow-Ups:
- Re: tlug: gcc question
- From: "Stephen J. Turnbull" <turnbull@example.com>
- Re: tlug: gcc question
- From: Selva Nair <selva@example.com>
- References:
- Re: tlug: gcc question
- From: "Scott M. Stone" <sstone@example.com>
Home | Main Index | Thread Index
- Prev by Date: Re: tlug: Any Takers?
- Next by Date: Re: tlug: gcc question
- Prev by thread: Re: tlug: gcc question
- Next by thread: Re: tlug: gcc question
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links