From james at colannino.org  Fri May 20 22:07:52 2005
From: james at colannino.org (James Colannino)
Date: Fri, 20 May 2005 22:07:52 -0700
Subject: [OCLUG-devel] exit vs. return
Message-ID: <428EC228.8010809@colannino.org>

I have one simple question (hope it's not a stupid one): why is it that
some people use exit() at the end of main() and others use return()?  I
know that return() simply returns from a function, and exit(), according
to the man page, exits from the shell (although I admit I don't quite
know what to make of this in the context of programming), but I'm not
clear as to why I've seen exit() used in some examples and return() in
others.  Thanks :)

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From james at colannino.org  Fri May 20 23:13:10 2005
From: james at colannino.org (James Colannino)
Date: Fri, 20 May 2005 23:13:10 -0700
Subject: [OCLUG-devel] write()
Message-ID: <428ED176.50206@colannino.org>

Sorry guys, just one more question.  This has me confused.  Consider the
following examples:

Example1:

char c;
int in, out;

in = open ("file.in", O_RDONLY);
out = open("file.out", O_WRONLY | O_CREAT, S_IRUSR | S_IWUSR);

while (read(in, &c, 1) == 1)
    write(out, &c, 1);

Example 2:

char block[1024];
int in, out;
int nread;

in = open ("file.in", O_RDONLY);
out = open("file.out", O_WRONLY | O_CREAT, S_IRUSR | S_IWUSR);

while ((nread = read(in, block, sizeof(block))) > 0)
    write(out, block, nread);

In the first example, you need to pass the pointer to variable c with
both the write() and read() functions, but in the second example, the
block variable, being equivalent to c in the first example, is passed
directly to write() and read() rather than having a pointer to it passed
instead.  Am I missing something?  Thanks again.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From michael.elkins at gmail.com  Fri May 20 23:30:19 2005
From: michael.elkins at gmail.com (Michael Elkins)
Date: Fri, 20 May 2005 23:30:19 -0700
Subject: [OCLUG-devel] write()
In-Reply-To: <428ED176.50206@colannino.org>
References: <428ED176.50206@colannino.org>
Message-ID: <404f0322050520233075ac79be@mail.gmail.com>

When you declare an array, the name of the variable is actually the
same as a pointer to the beginning of the array.  So in the 'read'
syscall, you are actually passing a pointer when you specify an array.

Michael

On 5/20/05, James Colannino <james at colannino.org> wrote:
> Example 2:
> 
> char block[1024];

From michael.elkins at gmail.com  Fri May 20 23:33:05 2005
From: michael.elkins at gmail.com (Michael Elkins)
Date: Fri, 20 May 2005 23:33:05 -0700
Subject: [OCLUG-devel] exit vs. return
In-Reply-To: <428EC228.8010809@colannino.org>
References: <428EC228.8010809@colannino.org>
Message-ID: <404f032205052023332a7d565f@mail.gmail.com>

They can be used interchangably.  Some people just use return from
main to be consistent with other function call exits.

Michael

From james at colannino.org  Fri May 20 23:50:24 2005
From: james at colannino.org (James Colannino)
Date: Fri, 20 May 2005 23:50:24 -0700
Subject: [OCLUG-devel] write()
In-Reply-To: <404f0322050520233075ac79be@mail.gmail.com>
References: <428ED176.50206@colannino.org>
	<404f0322050520233075ac79be@mail.gmail.com>
Message-ID: <428EDA30.2020209@colannino.org>

Michael Elkins wrote:

>When you declare an array, the name of the variable is actually the
>same as a pointer to the beginning of the array.  So in the 'read'
>syscall, you are actually passing a pointer when you specify an array.
>  
>

Awesome, thanks.  That makes a lot more sense.

James
-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From panfisher at earthlink.net  Sun May 22 15:02:51 2005
From: panfisher at earthlink.net (Tony Dycks)
Date: Sun, 22 May 2005 15:02:51 -0700
Subject: [OCLUG-devel] 
 Error Testing Tomcat Fedora Core2 RPM Install Default Port Used by
 Tomcat
Message-ID: <4291018B.4060304@earthlink.net>

Recently installed the suite of RPMs files to install Tomcat V4 in 
preparation for Java Web Dev on a standalone server.  I also started the 
Tomcat Network Service successfully.

When I try to test for the initial Tomcat Web page using the URL, 
http://localhost:8080, I get the message ...

The connection was refused while trying to contact localhost:8080.
I've successfully  installed a standalone Apache 2.0 Web Server.

Any suggestions on what port Tomcat may be using in an RPM or a utility 
that may help me diagnose the condition.

Thanks,

panfisher

From cbsmith at gmail.com  Mon May 23 10:06:05 2005
From: cbsmith at gmail.com (Chris Smith)
Date: Mon, 23 May 2005 10:06:05 -0700
Subject: [OCLUG-devel] Re: [OCLUG] C - Pointer assignment
In-Reply-To: <b31d342a05052309562a33409e@mail.gmail.com>
References: <b31d342a05052309562a33409e@mail.gmail.com>
Message-ID: <9ae343f505052310061a3b6047@mail.gmail.com>

Following up to oclug-devel as that's probably the more appropriate forum.

On 5/23/05, Doug Jolley <ddjolley at gmail.com> wrote:
> myPtr=(array+1);
> 
> However, I'm not sure how I can go the other way and perform an
> assignment.  Conceptually, I'd like to do something like:
> 
> (array+1)=myPtr;
> 
> IOW, I'd like to assign myPtr to the second element in the array (the
> first element being element 0).  Of course, the compiler gives some
> complaint about a bad lvalue which I totally understand and expect.
> It's just that I don't know what to do about it.  Can someone tell me
> how I can get this task done?  Thanks.

I'm guessing you want to assing the value *pointed to* by myPtr to the
second element of the array. In that case, you can just use the
standard array syntax and reference the pointer:

array[1] = *myPtr;

-- 
Chris

From strombrg at dcs.nac.uci.edu  Mon May 23 11:16:26 2005
From: strombrg at dcs.nac.uci.edu (Dan Stromberg)
Date: Mon, 23 May 2005 11:16:26 -0700
Subject: [OCLUG-devel] write()
In-Reply-To: <404f0322050520233075ac79be@mail.gmail.com>
References: <428ED176.50206@colannino.org>
	 <404f0322050520233075ac79be@mail.gmail.com>
Message-ID: <1116872187.5552.125.camel@seki.nac.uci.edu>

On Fri, 2005-05-20 at 23:30 -0700, Michael Elkins wrote:
> When you declare an array, the name of the variable is actually the
> same as a pointer to the beginning of the array.  So in the 'read'
> syscall, you are actually passing a pointer when you specify an array.
> 
> Michael

...and it's a rather unnecessary exception to the general rule.

Sure, it might keep a newbie from passing an entire array by value,
but...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://localhost.localdomain/pipermail/oclug-devel/attachments/20050523/4458af87/attachment.bin 

From cbsmith at gmail.com  Mon May 23 12:05:41 2005
From: cbsmith at gmail.com (Chris Smith)
Date: Mon, 23 May 2005 12:05:41 -0700
Subject: [OCLUG-devel] Re: [OCLUG] C - Pointer assignment
In-Reply-To: <42921144.7040607@paulsson.com>
References: <b31d342a05052309562a33409e@mail.gmail.com>
	 <42921144.7040607@paulsson.com>
Message-ID: <9ae343f505052312056f3608f3@mail.gmail.com>

Again, replying to devel.

On 5/23/05, Joshua Robinson <joshua.robinson at paulsson.com> wrote:
> myPtr = *(array+1);
> 
> OR in a loop
> 
> while ( !array ) {
>     myPtr = *(array++)
> }

I'm going to go out on a limb here, but I'm guessing the myPtr is a
pointer to whatever type the array is made of. As such doing:

myPtr = *(array+1);

is possibly syntactically incorrect and almost certainly not what you
want to have happen. For example:

int array[3];
int* myPtr;

array[1] = 42; /* for clarity */
myPtr = *(array + 1);
do_something(*myPtr); /*almost certainly cause something bad to happen */

So, "array" evaluates as a pointer to the address of array Let's say
that the address is 5000000 (in decimal). "array + 1" evaluates to a
pointer to the first element of that array, so that's a pointer to
5000004 (assuming int's are 32-bit). Now "*(array + 1)" means to take
the value at the address pointed to by "array + 1". That's going to be
42 because of the line I tagged with "for clarity". Now, the problem
is, you're assigning it to myPtr, not the value pointed to by myPtr.
So, myPtr becomes a pointer pointing to address 42. That's probably
not what you intended, and more importantly is probably an invalid
address anyway.

-- 
Chris

From cbsmith at gmail.com  Mon May 23 12:11:56 2005
From: cbsmith at gmail.com (Chris Smith)
Date: Mon, 23 May 2005 12:11:56 -0700
Subject: [OCLUG-devel] Re: [OCLUG] C - Pointer assignment
In-Reply-To: <4292179A.3000201@paulsson.com>
References: <b31d342a05052309562a33409e@mail.gmail.com>
	 <42921144.7040607@paulsson.com> <4292179A.3000201@paulsson.com>
Message-ID: <9ae343f505052312117c90b3e4@mail.gmail.com>

On 5/23/05, Joshua Robinson <joshua.robinson at paulsson.com> wrote:
> myPtr = *(array+1);
> while ( !array ) {
>    *(array++)  = myPtr;
> }

Again, myPtr would normally be a pointer, so for clarity I'd call it
myValue. Still, regardless of it's type, if you can get this to
compile, it'll work.... except for the loop:

while (!array)

That test effectively evaluates to "while the array is null".
Hopefully that loop will always fail. If it does succeed, they you'll
be doing an assignment to address 0, which will cause a segfault. I'm
not sure what you intended with this code (doesn't seem like a bubble
sort to me), but my best guess would suggest something like:

myValue = array[1];
arrayEnd = array + array_length;
while(array != arrayEnd) {
    *(array++) = myValue;
}

-- 
Chris

From cbsmith at gmail.com  Mon May 23 12:18:01 2005
From: cbsmith at gmail.com (Chris Smith)
Date: Mon, 23 May 2005 12:18:01 -0700
Subject: [OCLUG-devel] Re: [OCLUG] C - Pointer assignment
In-Reply-To: <1116875075.8970.14.camel@gules>
References: <b31d342a05052309562a33409e@mail.gmail.com>
	 <42921144.7040607@paulsson.com> <4292179A.3000201@paulsson.com>
	 <1116875075.8970.14.camel@gules>
Message-ID: <9ae343f5050523121876098248@mail.gmail.com>

Following up to -devel where it's more appropriate.

On 5/23/05, Jack Denman <cashmere at adelphia.net> wrote:
> You must use
> pointer = pointer
> or
> lvalue = lvalue

Well, technically "pointer = value" might work if the compiler is
sufficiently lax, but it undoubtedly represents a case where something
unintended is happening.

lvalue = lvalue

is non-sensical. An lvalue is the left hand side of an assignment
operation. It shouldn't be on the right side. What you normally have
is:

lvalue = rvalue

For details: http://www.embedded.com/story/OEG20010518S0071

-- 
Chris

From cbsmith at gmail.com  Mon May 23 13:53:40 2005
From: cbsmith at gmail.com (Chris Smith)
Date: Mon, 23 May 2005 13:53:40 -0700
Subject: [OCLUG-devel] Re: [OCLUG] C - Pointer assignment
In-Reply-To: <b31d342a05052309562a33409e@mail.gmail.com>
References: <b31d342a05052309562a33409e@mail.gmail.com>
Message-ID: <9ae343f50505231353215dea09@mail.gmail.com>

On 5/23/05, Doug Jolley <ddjolley at gmail.com> wrote:
> In my latest project I want to perform a buble sort on an array of
> pointers.

I missed this from the original post. So that explains the myPtr part
of it. So you want to sort the pointers based on their address value?
The code isn't going to very different from the same code for
integers:

void bubbleSort(void** array, size_t length)
{
    size_t i, j;
    for (i = length - 1; i > 0; --i) {
        for (j = 0, j < i, ++j) {
            if (array[j] > array[j+1]) {
                void* temp = array[j];
                array[j] = array [j+1];
                array[j+1] = temp;
            }
        }
    }
}

Really, if you replace all occurences of "void*" with "int", it's
exactly like sorting integers.

-- 
Chris

From cbsmith at gmail.com  Mon May 23 22:55:01 2005
From: cbsmith at gmail.com (Chris Smith)
Date: Mon, 23 May 2005 22:55:01 -0700
Subject: [OCLUG-devel] Re: [OCLUG] C - Pointer assignment
In-Reply-To: <4292B191.6090709@cox.net>
References: <b31d342a05052309562a33409e@mail.gmail.com>
	 <42921144.7040607@paulsson.com> <4292B191.6090709@cox.net>
Message-ID: <9ae343f5050523225576f2b667@mail.gmail.com>

Yet another desperate attempt to put this on oclug-devel...

On 5/23/05, Ted Gladieux <sshortsword at cox.net> wrote:
> Joshua's code might be what you really want.

Well, the while() test is definitely not what you really want. The
only circumstances under which the while's block will get executed
would be if the array started at address 0, which means the first
deref of array will cause a segfault.

-- 
Chris

From james at colannino.org  Mon May 23 23:54:55 2005
From: james at colannino.org (James Colannino)
Date: Mon, 23 May 2005 23:54:55 -0700
Subject: [OCLUG-devel] Another simple question
Message-ID: <4292CFBF.7050303@colannino.org>

Hey everyone.  Check out the following line of code:

ebuf->size *= 2;  /* copied from one of my C books */

This must seem a stupid question, but I for the life of me can't figure
out what the "->" and "*=" symbols mean.  I'd google if I could, but I
wouldn't know what to look for.  Thanks in advance :)

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From cbsmith at gmail.com  Tue May 24 00:26:27 2005
From: cbsmith at gmail.com (Chris Smith)
Date: Tue, 24 May 2005 00:26:27 -0700
Subject: [OCLUG-devel] Another simple question
In-Reply-To: <4292CFBF.7050303@colannino.org>
References: <4292CFBF.7050303@colannino.org>
Message-ID: <9ae343f50505240026108a2c2@mail.gmail.com>

On 5/23/05, James Colannino <james at colannino.org> wrote:
> Hey everyone.  Check out the following line of code:
> 
> ebuf->size *= 2;  /* copied from one of my C books */
> 
> This must seem a stupid question, but I for the life of me can't figure
> out what the "->" and "*=" symbols mean.  I'd google if I could, but I
> wouldn't know what to look for.  Thanks in advance :)

If you're going to code in C, get the appropriate bible:

http://www.bookpool.com/sm/0131103628

That'll provide you with a great reference on C.

-> means you dereference and then access a member. So "ebuf->size" is
the same as (*ebuf).size.

"a *= b" is semantically equivalent to "a = a * b". There are issues
about order of execution since it's an operator with side effects,
which you will find clarified if you look for "codepoints" in the
index.

-- 
Chris

From chris_berry-list-oclug-devel at jm-associates.com  Wed May 25 17:47:33 2005
From: chris_berry-list-oclug-devel at jm-associates.com (Chris Berry)
Date: Wed, 25 May 2005 17:47:33 -0700
Subject: [OCLUG-devel] Lexicographically Sorted
Message-ID: <42951CA5.5020708@jm-associates.com>

I'm supposed to write a C program that works similiar to strcmp, book 
definition follows:

*********
Compares two strings s1 and s2 lexicographically.  The elements of the 
strings are treated as unsigned characters.  The function returns a 
value that is less than, equal to, or greater than zero, depending on 
whether s1 is lexicographically less than, equal to, or greater than s2.
*********

No problem, except I haven't been able to figure out what lexicographic 
ordering is.  I know how to sort alphabetically and ASCIIbetically, but 
lexicographically is a new one.  When I looked on google, it seemed like 
everyone thought it was so obvious it didn't need to be explained.  Can 
someone clue me in here?

-- 
Chris Berry
chris_berry at jm-associates.com
Information Advisory Manager
JM Associates

"There is nothing so useless as doing efficiently that which should not 
be done at all." --Peter Drucker

From x at xman.org  Wed May 25 17:55:48 2005
From: x at xman.org (Christopher Smith)
Date: Wed, 25 May 2005 17:55:48 -0700
Subject: [OCLUG-devel] Lexicographically Sorted
In-Reply-To: <42951CA5.5020708@jm-associates.com>
References: <42951CA5.5020708@jm-associates.com>
Message-ID: <42951E94.3050308@xman.org>

Chris Berry wrote:
> No problem, except I haven't been able to figure out what lexicographic 
> ordering is.  I know how to sort alphabetically and ASCIIbetically, but 
> lexicographically is a new one.  When I looked on google, it seemed like 
> everyone thought it was so obvious it didn't need to be explained.  Can 
> someone clue me in here?

man strcoll
man wcscoll (wide character version)

--Chris

From x at xman.org  Wed May 25 17:59:17 2005
From: x at xman.org (Christopher Smith)
Date: Wed, 25 May 2005 17:59:17 -0700
Subject: [OCLUG-devel] Lexicographically Sorted
In-Reply-To: <42951E94.3050308@xman.org>
References: <42951CA5.5020708@jm-associates.com> <42951E94.3050308@xman.org>
Message-ID: <42951F65.1040001@xman.org>

Christopher Smith wrote:
> Chris Berry wrote:
>> No problem, except I haven't been able to figure out what 
>> lexicographic ordering is.  I know how to sort alphabetically and 
>> ASCIIbetically, but lexicographically is a new one.  When I looked on 
>> google, it seemed like everyone thought it was so obvious it didn't 
>> need to be explained.  Can someone clue me in here?
> 
> man strcoll
> man wcscoll (wide character version)

For more details on the joys of POSIX locale's, I highly recommend The 
Open Group's web site:

http://www.opengroup.org/onlinepubs/007908799/xbd/locale.html

--Chris

From chris_berry-list-oclug-devel at jm-associates.com  Wed May 25 18:09:30 2005
From: chris_berry-list-oclug-devel at jm-associates.com (Chris Berry)
Date: Wed, 25 May 2005 18:09:30 -0700
Subject: [OCLUG-devel] Lexicographically Sorted
In-Reply-To: <42951F65.1040001@xman.org>
References: <42951CA5.5020708@jm-associates.com> <42951E94.3050308@xman.org>
	<42951F65.1040001@xman.org>
Message-ID: <429521CA.2060500@jm-associates.com>

That's interesting, and kind of scary, seems like every time I learn 
something new about computers it just reveals a whole new layer of 
ignorance on my part.  Unfortuneately, the man pages you pointed to 
don't define lexicographic ordering.  I'm not looking for a strcmp 
replacement, I'm doing an excercise as part of my C programming 
training.  I don't want someone to do the work for me, I just need to 
know what lexicographical order is so I can figure out how to write the 
algorithm.

Chris Berry
chris_berry at jm-associates.com
Information Advisory Manager
JM Associates

"There is nothing so useless as doing efficiently that which should not 
be done at all." --Peter Drucker


Christopher Smith wrote:
> Christopher Smith wrote:
> 
>> Chris Berry wrote:
>>
>>> No problem, except I haven't been able to figure out what 
>>> lexicographic ordering is.  I know how to sort alphabetically and 
>>> ASCIIbetically, but lexicographically is a new one.  When I looked on 
>>> google, it seemed like everyone thought it was so obvious it didn't 
>>> need to be explained.  Can someone clue me in here?
>>
>>
>> man strcoll
>> man wcscoll (wide character version)
> 
> 
> For more details on the joys of POSIX locale's, I highly recommend The 
> Open Group's web site:
> 
> http://www.opengroup.org/onlinepubs/007908799/xbd/locale.html
> 
> --Chris

From james at colannino.org  Wed May 25 18:22:30 2005
From: james at colannino.org (James Colannino)
Date: Wed, 25 May 2005 18:22:30 -0700
Subject: [OCLUG-devel] Lexicographically Sorted
In-Reply-To: <42951CA5.5020708@jm-associates.com>
References: <42951CA5.5020708@jm-associates.com>
Message-ID: <429524D6.7000008@colannino.org>

Chris Berry wrote: 

> No problem, except I haven't been able to figure out what
> lexicographic ordering is.


http://en.wikipedia.org/wiki/Lexicographical :)

I found that on google using the terms 'what is lexicographical.' 
Helped me to learn something new too ;)

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From x at xman.org  Wed May 25 22:28:30 2005
From: x at xman.org (Christopher Smith)
Date: Wed, 25 May 2005 22:28:30 -0700
Subject: [OCLUG-devel] Lexicographically Sorted
In-Reply-To: <429521CA.2060500@jm-associates.com>
References: <42951CA5.5020708@jm-associates.com> <42951E94.3050308@xman.org>
	<42951F65.1040001@xman.org> <429521CA.2060500@jm-associates.com>
Message-ID: <42955E7E.5000901@xman.org>

Chris Berry wrote:

> That's interesting, and kind of scary, seems like every time I learn 
> something new about computers it just reveals a whole new layer of 
> ignorance on my part. Unfortuneately, the man pages you pointed to 
> don't define lexicographic ordering. I'm not looking for a strcmp 
> replacement, I'm doing an excercise as part of my C programming 
> training. I don't want someone to do the work for me, I just need to 
> know what lexicographical order is so I can figure out how to write 
> the algorithm.
>
Apologies. I thought the man pages would make it clear. Alphabetical 
ordering is a subset of lexical ordering. The difference is that lexical 
ordering allows for sorting of non-alphabetical characters. All this 
stuff is dealt with in detail in the locale support in POSIX (see the 
link I provided). strcoll is not a strcmp replacement. They are similar 
functions. strcmp compares strings based on ASCIIbetical order, strcoll 
compares strings based on lexical ordering for the current POSIX locale.

POSIX is a standard seperate from the C language, so strcoll is 
technically not part of C and perhaps using POSIX functions is 
inappropriate for your situation, in which case you need to match 
strcoll's functionality. Basically, the main thing you need is a lexical 
alphabet to define what comes before what and what characters are 
equivalent. If you can't use POSIX, you are going to need some other 
source for determining that. Since you didn't mention having one, I 
figured using POSIX was the way the instructor wanted you to go.

--Chris

From james at colannino.org  Wed May 25 22:53:59 2005
From: james at colannino.org (James Colannino)
Date: Wed, 25 May 2005 22:53:59 -0700
Subject: [OCLUG-devel] Memory Leaks
Message-ID: <42956477.20402@colannino.org>

Hey everyone.  I have a more abstract question about what happens during
a memory leak.  I know that a program "leaks memory" when it
continuously allocates more RAM without freeing it.  My question is,
what happens when the process terminates?  Does the leak only effect the
system while the process is running, or is the memory permanently lost
until the next reboot?  The thing that brought this up was that I was
reading a couple days ago in my C book about memory leaks.  I guess this
would probably be a good time for me to learn about how Linux manages
memory.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From x at xman.org  Wed May 25 23:04:20 2005
From: x at xman.org (Christopher Smith)
Date: Wed, 25 May 2005 23:04:20 -0700
Subject: [OCLUG-devel] Memory Leaks
In-Reply-To: <42956477.20402@colannino.org>
References: <42956477.20402@colannino.org>
Message-ID: <429566E4.4060009@xman.org>

James Colannino wrote:

>Hey everyone.  I have a more abstract question about what happens during
>a memory leak.  I know that a program "leaks memory" when it
>continuously allocates more RAM without freeing it.  My question is,
>what happens when the process terminates?  Does the leak only effect the
>system while the process is running, or is the memory permanently lost
>until the next reboot?  The thing that brought this up was that I was
>reading a couple days ago in my C book about memory leaks.  I guess this
>would probably be a good time for me to learn about how Linux manages
>memory.
>  
>
In a POSIX system (and actually it's true in Windows and basically 
anything that has "real" processes), a process gets it's own set of 
memory along with other resources. When that process dies, those 
resources are all released and reclaimed by the kernel. That's basically 
one of the key jobs of the kernel. So a memory leak in your program 
won't last past the life of said program.

There are, as always, exceptions. ;-) First, if there is a bug in the 
kernel, you could have a memory leak that won't get fixed until you 
reboot. Secondly, things like Sys V shared memory aren't owned by any 
one process, so the kernel can't know whether to free them if a 
particular process dies.

Modern Operating Systems (now Distributed Operating Systems I think) by 
Tanenbaum (yes, *that* Tanenbaum) did a good job of explaining how 
operating systems do this.

--Chris

From james at colannino.org  Wed May 25 23:43:19 2005
From: james at colannino.org (James Colannino)
Date: Wed, 25 May 2005 23:43:19 -0700
Subject: [OCLUG-devel] Memory Leaks
In-Reply-To: <429566E4.4060009@xman.org>
References: <42956477.20402@colannino.org> <429566E4.4060009@xman.org>
Message-ID: <42957007.4060508@colannino.org>

Christopher Smith wrote:

> [...]
>
> There are, as always, exceptions. ;-) First, if there is a bug in the
> kernel, you could have a memory leak that won't get fixed until you
> reboot. Secondly, things like Sys V shared memory aren't owned by any
> one process, so the kernel can't know whether to free them if a
> particular process dies.
>
> Modern Operating Systems (now Distributed Operating Systems I think)
> by Tanenbaum (yes, *that* Tanenbaum) did a good job of explaining how
> operating systems do this.


That's interesting.  I sure have a lot to learn... :-P

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From cbsmith at gmail.com  Thu May 26 13:13:18 2005
From: cbsmith at gmail.com (Chris Smith)
Date: Thu, 26 May 2005 13:13:18 -0700
Subject: [OCLUG] Re: [OCLUG-devel] Lexicographically Sorted
In-Reply-To: <42962904.4090001@jm-associates.com>
References: <42951CA5.5020708@jm-associates.com> <42951E94.3050308@xman.org>
	 <42951F65.1040001@xman.org> <429521CA.2060500@jm-associates.com>
	 <42955E7E.5000901@xman.org> <42962904.4090001@jm-associates.com>
Message-ID: <9ae343f505052613132a38315@mail.gmail.com>

Hmm... somehow this ended up back on oclug, but I'll reply on oclug-devel.

On 5/26/05, Chris Berry <chris_berry-list-oclug at jm-associates.com> wrote:
> Ok, let me see if I've got this straight.  Lexicographic ordering is
> locale dependant as it would vary with the alphabet and conventions of
> the language.  In the specific case of US English Lexicographic ordering
> is the same as ASCIIbetical ordering, in other locales it's not.

Sounds like you got it about right. The specific aspect of the locale
that defines how things are ordered is called the "lexicon". Some
would argue that the US English lexicon would actually sort things
differently from the ASCIIbetical order, with things like case
insensitivity and some of the non-alphanumeric characters, but those
people tend to get ignored more than anything. ;-)

-- 
Chris

From chris_berry-list-oclug-devel at jm-associates.com  Thu May 26 14:28:04 2005
From: chris_berry-list-oclug-devel at jm-associates.com (Chris Berry)
Date: Thu, 26 May 2005 14:28:04 -0700
Subject: [OCLUG] Re: [OCLUG-devel] Lexicographically Sorted
In-Reply-To: <9ae343f505052613132a38315@mail.gmail.com>
References: <42951CA5.5020708@jm-associates.com> <42951E94.3050308@xman.org>	
	<42951F65.1040001@xman.org> <429521CA.2060500@jm-associates.com>	
	<42955E7E.5000901@xman.org> <42962904.4090001@jm-associates.com>
	<9ae343f505052613132a38315@mail.gmail.com>
Message-ID: <42963F64.5010109@jm-associates.com>

Ok, thanks alot, that makes of some the other stuff I read online about 
unicode and such as well.  Sorry about the cross-post, had a little 
address book snafu, but I've reconfigured and it shouldn't happen now.

Chris Berry
chris_berry at jm-associates.com
Information Advisory Manager
JM Associates

"There is nothing so useless as doing efficiently that which should not 
be done at all." --Peter Drucker


Chris Smith wrote:
> Hmm... somehow this ended up back on oclug, but I'll reply on oclug-devel.
> 
> On 5/26/05, Chris Berry <chris_berry-list-oclug at jm-associates.com> wrote:
> 
>>Ok, let me see if I've got this straight.  Lexicographic ordering is
>>locale dependant as it would vary with the alphabet and conventions of
>>the language.  In the specific case of US English Lexicographic ordering
>>is the same as ASCIIbetical ordering, in other locales it's not.
> 
> 
> Sounds like you got it about right. The specific aspect of the locale
> that defines how things are ordered is called the "lexicon". Some
> would argue that the US English lexicon would actually sort things
> differently from the ASCIIbetical order, with things like case
> insensitivity and some of the non-alphanumeric characters, but those
> people tend to get ignored more than anything. ;-)
> 

From james at colannino.org  Sun May 29 04:31:13 2005
From: james at colannino.org (James Colannino)
Date: Sun, 29 May 2005 04:31:13 -0700
Subject: [OCLUG-devel] arrays
Message-ID: <4299A801.4050406@colannino.org>

Hey everyone.  I have another C question, this time regarding arrays. 
I'm wondering what would happen if you did the following:

char array[5];

for (i = 0; i <= 10; ++i)
    array[i] = 'a';

array[11] = '\0';

/* notice that I've indexed through 7 more than I should have */

printf ("%s\n", array);

I know this is NEVER something you should do, but so far, out of
curiosity (and buggy code :-P), I've gotten away with it every time I've
tried, and I'm curious what the possible ill effects are.  Thanks in
advance.

James
-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment

From msimpson at braysimpson.com  Sun May 29 08:37:54 2005
From: msimpson at braysimpson.com (Morgan Simpson)
Date: Sun, 29 May 2005 08:37:54 -0700
Subject: [OCLUG-devel] arrays
In-Reply-To: <4299A801.4050406@colannino.org>
References: <4299A801.4050406@colannino.org>
Message-ID: <edde3380936ff18273b31007be425f88@braysimpson.com>

On May 29, 2005, at 4:31 AM, James Colannino wrote:

> char array[5];
>
> for (i = 0; i <= 10; ++i)
>     array[i] = 'a';
>
> array[11] = '\0';
>
> /* notice that I've indexed through 7 more than I should have */
>
> printf ("%s\n", array);

James, this is an open invitation for a segmentation fault.

Just out of curiosity, do all 10 characters print in your test case?

Regards,
Morgan Simpson
Bray, Simpson & Associates, Inc.


From x at xman.org  Sun May 29 09:22:44 2005
From: x at xman.org (Christopher Smith)
Date: Sun, 29 May 2005 09:22:44 -0700
Subject: [OCLUG-devel] arrays
In-Reply-To: <4299A801.4050406@colannino.org>
References: <4299A801.4050406@colannino.org>
Message-ID: <4299EC54.6090608@xman.org>

James Colannino wrote:

>Hey everyone.  I have another C question, this time regarding arrays. 
>I'm wondering what would happen if you did the following:
>
>char array[5];
>
>for (i = 0; i <= 10; ++i)
>    array[i] = 'a';
>
>array[11] = '\0';
>
>/* notice that I've indexed through 7 more than I should have */
>
>printf ("%s\n", array);
>
>I know this is NEVER something you should do, but so far, out of
>curiosity (and buggy code :-P), I've gotten away with it every time I've
>tried, and I'm curious what the possible ill effects are.  Thanks in
>advance.
>  
>
C doesn't have any bounds checking so it's not going to stop you from 
accessing data outside the array. Now, depending on how the allocator is 
setup, there may be some "padding" around your array that prevents 
really bad things from happening. In terms of what could go wrong? Well, 
this is a classic example of how stack overflows occur. You're writing 
past the end of the stack-allocated array, which means you're writing 
all over the stack. I'm guessing you aren't having a problem because 
you're exiting immediately after this. However, if this was in a 
subroutine, then when you return, the subroutine would pop off the 5 
bytes of your array and any arguments that were passed in, and then pop 
off the return address. If the return address has been overwritten by 
your array data, then it'll jump somewhere unanticipated. In most cases 
this will be a segmentation fault because it'll be a totally invalid 
address (which should be happening in this case). Sometimes though, you 
can be unfortunate enough to write in an address that is valid, at which 
your program will jump to that location and attempt to execute 
instructions. Very, very messy.

--Chris

From james at colannino.org  Sun May 29 10:54:50 2005
From: james at colannino.org (James Colannino)
Date: Sun, 29 May 2005 10:54:50 -0700
Subject: [OCLUG-devel] arrays
In-Reply-To: <edde3380936ff18273b31007be425f88@braysimpson.com>
References: <4299A801.4050406@colannino.org>
	<edde3380936ff18273b31007be425f88@braysimpson.com>
Message-ID: <429A01EA.1080000@colannino.org>

Morgan Simpson wrote:

> Just out of curiosity, do all 10 characters print in your test case?


Yup, they do.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From james at colannino.org  Sun May 29 11:01:21 2005
From: james at colannino.org (James Colannino)
Date: Sun, 29 May 2005 11:01:21 -0700
Subject: [OCLUG-devel] arrays
In-Reply-To: <4299EC54.6090608@xman.org>
References: <4299A801.4050406@colannino.org> <4299EC54.6090608@xman.org>
Message-ID: <429A0371.7020409@colannino.org>

Christopher Smith wrote:

> C doesn't have any bounds checking so it's not going to stop you from
> accessing data outside the array. Now, depending on how the allocator
> is setup, there may be some "padding" around your array that prevents
> really bad things from happening. In terms of what could go wrong?
> Well, this is a classic example of how stack overflows occur. You're
> writing past the end of the stack-allocated array, which means you're
> writing all over the stack. I'm guessing you aren't having a problem
> because you're exiting immediately after this. However, if this was in
> a subroutine, then when you return, the subroutine would pop off the 5
> bytes of your array and any arguments that were passed in, and then
> pop off the return address. If the return address has been overwritten
> by your array data, then it'll jump somewhere unanticipated. In most
> cases this will be a segmentation fault because it'll be a totally
> invalid address (which should be happening in this case). Sometimes
> though, you can be unfortunate enough to write in an address that is
> valid, at which your program will jump to that location and attempt to
> execute instructions. Very, very messy.


Chris, thanks for the info.  That's very interesting.  I'm guessing
that's how some programs are exploited and made to run arbitrary
instructions.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From james at colannino.org  Sun May 29 11:20:45 2005
From: james at colannino.org (James Colannino)
Date: Sun, 29 May 2005 11:20:45 -0700
Subject: [OCLUG-devel] arrays
In-Reply-To: <4299EC54.6090608@xman.org>
References: <4299A801.4050406@colannino.org> <4299EC54.6090608@xman.org>
Message-ID: <429A07FD.8060400@colannino.org>

Christopher Smith wrote:

> C doesn't have any bounds checking so it's not going to stop you from
> accessing data outside the array. Now, depending on how the allocator
> is setup, there may be some "padding" around your array that prevents
> really bad things from happening. In terms of what could go wrong?
> Well, this is a classic example of how stack overflows occur. You're
> writing past the end of the stack-allocated array, which means you're
> writing all over the stack. I'm guessing you aren't having a problem
> because you're exiting immediately after this. However, if this was in
> a subroutine, then when you return, the subroutine would pop off the 5
> bytes of your array and any arguments that were passed in, and then
> pop off the return address. If the return address has been overwritten
> by your array data, then it'll jump somewhere unanticipated. In most
> cases this will be a segmentation fault because it'll be a totally
> invalid address (which should be happening in this case). Sometimes
> though, you can be unfortunate enough to write in an address that is
> valid, at which your program will jump to that location and attempt to
> execute instructions. Very, very messy.


By the way, I'm just curious, does the kernel ever do anything about a
situation in which a process attempts to execute corrupted
instructions?  I guess there's probably not much it could do, but does
the kernel at least protect you from truly dangerous things that could
result from the random contents of a variable being executed as
instructions?  I'm guessing that since the kernel takes full control of
the hardware it would probably protect you at least to a certain
extent.  Perhaps such a thing could cause a kernel panic?

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From james at colannino.org  Sun May 29 12:06:20 2005
From: james at colannino.org (James Colannino)
Date: Sun, 29 May 2005 12:06:20 -0700
Subject: [OCLUG-devel] malloc() woes
Message-ID: <429A12AC.5090400@colannino.org>

I hope my frequent questions on the list don't start to annoy anyone. 
I'm having some trouble figuring out how to expand a variable's size if
it's not big enough.  I've already written the code, and so far, most of
what I've written doesn't cause the compiler to spit out any errors
(although I'll probably have some bugs the first time I run it.) 
There's one thing that I can't get around though.  Here's a snippet of
code to illustrate what I'm doing:

char buffer[BUFFER_SIZE];
/* BUFFER_SIZE is a constant - it's currently set to 80 */

char *buffer2;
/* this is used as temporary storage for a new pointer */

fgets (buffer, sizeof(buffer), file);
/* for the sake of brevity, the code dealing with file is not here */

if (buffer[BUFFER_SIZE] != '\n') {
    buffer2 = more_memory(buffer);

/* the function more_memory() returns a pointer to new memory if it was
successful and the old pointer if it was not.  After this function is
called, I do some checking to make sure buffer2 != buffer (which would
mean that it just returned the same pointer, and thus,  there isn't
enough memory) then I try to do the following: */

buffer = buffer2;

This results in the following compiler error:

"incompatible types in assignment"

I tried different variations that I knew would probably also fail such as:

buffer = (char *)buffer2;
&buffer[0] = (char *)buffer2;

I of course didn't expect those to work, but it was a vain attempt to
try and figure out why I can't do this.  I slowly realized that while
typing buffer by itself does denote a pointer to the string, the
variable buffer isn't directly declared as a pointer but rather as an
array, so I'm guessing that since buffer2 is a pointer and buffer is a
character array, that's where my problem is.  But now I can't figure out
how to get buffer to point to the new block of memory :(

Any ideas?  Thanks in advance :)

James

P.S. If I get annoying just let me know ;)

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From james at colannino.org  Sun May 29 12:12:55 2005
From: james at colannino.org (James Colannino)
Date: Sun, 29 May 2005 12:12:55 -0700
Subject: [OCLUG-devel] malloc() woes
In-Reply-To: <429A12AC.5090400@colannino.org>
References: <429A12AC.5090400@colannino.org>
Message-ID: <429A1437.3070806@colannino.org>

James Colannino wrote:

>if (buffer[BUFFER_SIZE] != '\n') {
>  
>

By the way, probably not a big deal since this doesn't concern my
question, but since arrays start at 0, just for the record I'll change
this to:

 if (buffer[BUFFER_SIZE - 1] != '\n') {

or maybe:

if *(buffer + BUFFER_SIZE) != '\n') {

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From x at xman.org  Sun May 29 12:15:06 2005
From: x at xman.org (Christopher Smith)
Date: Sun, 29 May 2005 12:15:06 -0700
Subject: [OCLUG-devel] malloc() woes
In-Reply-To: <429A12AC.5090400@colannino.org>
References: <429A12AC.5090400@colannino.org>
Message-ID: <429A14BA.2020902@xman.org>

Okay, so first thing is that I'm betting your "more_memory" function is 
not returning char*. Without seeing it's definition though, it's hard to 
be sure.

I'd also recommend looking in to realloc() for what you are doing.

--Chris

From x at xman.org  Sun May 29 12:22:01 2005
From: x at xman.org (Christopher Smith)
Date: Sun, 29 May 2005 12:22:01 -0700
Subject: [OCLUG-devel] malloc() woes
In-Reply-To: <429A1437.3070806@colannino.org>
References: <429A12AC.5090400@colannino.org> <429A1437.3070806@colannino.org>
Message-ID: <429A1659.4080107@xman.org>

James Colannino wrote:

>James Colannino wrote:
>
>  
>
>>if (buffer[BUFFER_SIZE] != '\n') {
>> 
>>
>>    
>>
>
>By the way, probably not a big deal since this doesn't concern my
>question, but since arrays start at 0, just for the record I'll change
>this to:
>
> if (buffer[BUFFER_SIZE - 1] != '\n') {
>
>or maybe:
>
>if *(buffer + BUFFER_SIZE) != '\n') {
>  
>
If the buffer is filled, buffer[BUFFER_SIZE-1] should equal '\0'. It 
should never be '\n' unless from garbage memory.

--Chris

From strombrg at dcs.nac.uci.edu  Sun May 29 12:47:39 2005
From: strombrg at dcs.nac.uci.edu (Dan Stromberg)
Date: Sun, 29 May 2005 12:47:39 -0700
Subject: [OCLUG-devel] malloc() woes
In-Reply-To: <429A12AC.5090400@colannino.org>
References: <429A12AC.5090400@colannino.org>
Message-ID: <1117396059.6518.159.camel@seki.nac.uci.edu>


You'll probably want to declare your initial "buffer" as a char *, and
then get some memory for it via malloc(), when you first need to use it.

Then if/when you're ready to change the amount of memory pointed to by
buffer, you'll probably want to use realloc().

On Sun, 2005-05-29 at 12:06 -0700, James Colannino wrote:
> I hope my frequent questions on the list don't start to annoy anyone. 
> I'm having some trouble figuring out how to expand a variable's size if
> it's not big enough.  I've already written the code, and so far, most of
> what I've written doesn't cause the compiler to spit out any errors
> (although I'll probably have some bugs the first time I run it.) 
> There's one thing that I can't get around though.  Here's a snippet of
> code to illustrate what I'm doing:
> 
> char buffer[BUFFER_SIZE];
> /* BUFFER_SIZE is a constant - it's currently set to 80 */
> 
> char *buffer2;
> /* this is used as temporary storage for a new pointer */
> 
> fgets (buffer, sizeof(buffer), file);
> /* for the sake of brevity, the code dealing with file is not here */
> 
> if (buffer[BUFFER_SIZE] != '\n') {
>     buffer2 = more_memory(buffer);
> 
> /* the function more_memory() returns a pointer to new memory if it was
> successful and the old pointer if it was not.  After this function is
> called, I do some checking to make sure buffer2 != buffer (which would
> mean that it just returned the same pointer, and thus,  there isn't
> enough memory) then I try to do the following: */
> 
> buffer = buffer2;
> 
> This results in the following compiler error:
> 
> "incompatible types in assignment"
> 
> I tried different variations that I knew would probably also fail such as:
> 
> buffer = (char *)buffer2;
> &buffer[0] = (char *)buffer2;
> 
> I of course didn't expect those to work, but it was a vain attempt to
> try and figure out why I can't do this.  I slowly realized that while
> typing buffer by itself does denote a pointer to the string, the
> variable buffer isn't directly declared as a pointer but rather as an
> array, so I'm guessing that since buffer2 is a pointer and buffer is a
> character array, that's where my problem is.  But now I can't figure out
> how to get buffer to point to the new block of memory :(
> 
> Any ideas?  Thanks in advance :)
> 
> James
> 
> P.S. If I get annoying just let me know ;)
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://localhost.localdomain/pipermail/oclug-devel/attachments/20050529/c74e5724/attachment.bin 

From strombrg at dcs.nac.uci.edu  Sun May 29 12:57:39 2005
From: strombrg at dcs.nac.uci.edu (Dan Stromberg)
Date: Sun, 29 May 2005 12:57:39 -0700
Subject: [OCLUG-devel] arrays
In-Reply-To: <429A07FD.8060400@colannino.org>
References: <4299A801.4050406@colannino.org> <4299EC54.6090608@xman.org>
	 <429A07FD.8060400@colannino.org>
Message-ID: <1117396660.6518.162.camel@seki.nac.uci.edu>

On Sun, 2005-05-29 at 11:20 -0700, James Colannino wrote:
> Christopher Smith wrote:
> 
> > C doesn't have any bounds checking so it's not going to stop you from
> > accessing data outside the array. Now, depending on how the allocator
> > is setup, there may be some "padding" around your array that prevents
> > really bad things from happening. In terms of what could go wrong?
> > Well, this is a classic example of how stack overflows occur. You're
> > writing past the end of the stack-allocated array, which means you're
> > writing all over the stack. I'm guessing you aren't having a problem
> > because you're exiting immediately after this. However, if this was in
> > a subroutine, then when you return, the subroutine would pop off the 5
> > bytes of your array and any arguments that were passed in, and then
> > pop off the return address. If the return address has been overwritten
> > by your array data, then it'll jump somewhere unanticipated. In most
> > cases this will be a segmentation fault because it'll be a totally
> > invalid address (which should be happening in this case). Sometimes
> > though, you can be unfortunate enough to write in an address that is
> > valid, at which your program will jump to that location and attempt to
> > execute instructions. Very, very messy.
> 
> 
> By the way, I'm just curious, does the kernel ever do anything about a
> situation in which a process attempts to execute corrupted
> instructions?  I guess there's probably not much it could do, but does
> the kernel at least protect you from truly dangerous things that could
> result from the random contents of a variable being executed as
> instructions?  I'm guessing that since the kernel takes full control of
> the hardware it would probably protect you at least to a certain
> extent.  Perhaps such a thing could cause a kernel panic?

I'm not sure what was done to resolve the problem, but years ago there
was a program called "crashme" that generated a bunch of random code and
executed it, which would crash most *ix's, including linux.

But linux adapted to it.  I'm not sure how many of the *ix vendors
followed suit.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://localhost.localdomain/pipermail/oclug-devel/attachments/20050529/5675450e/attachment.bin 

From strombrg at dcs.nac.uci.edu  Sun May 29 13:03:31 2005
From: strombrg at dcs.nac.uci.edu (Dan Stromberg)
Date: Sun, 29 May 2005 13:03:31 -0700
Subject: [OCLUG-devel] arrays
In-Reply-To: <4299A801.4050406@colannino.org>
References: <4299A801.4050406@colannino.org>
Message-ID: <1117397011.6518.170.camel@seki.nac.uci.edu>


Basically, there is a "contract between the C implementation and the
programmer".

Writing beyond the allocated bounds of an array like this, breaks your
end of the contract (the clause that says "don't reference undefined
regions of memory), which frees the C implementation to no longer hold
up its end of the contract either.  In other words, the C implementation
can do any screwball, random thing it wants in response to this, and
still be perfectly legal C.

However, one of the more likely things that will happen is that a
variable that was allocated after array[5] in the current stack frame
will get trounced, in which case your program may not error out until
much later, for what may seem like a completely unrelated reason.

On Sun, 2005-05-29 at 04:31 -0700, James Colannino wrote:
> Hey everyone.  I have another C question, this time regarding arrays. 
> I'm wondering what would happen if you did the following:
> 
> char array[5];
> 
> for (i = 0; i <= 10; ++i)
>     array[i] = 'a';
> 
> array[11] = '\0';
> 
> /* notice that I've indexed through 7 more than I should have */
> 
> printf ("%s\n", array);
> 
> I know this is NEVER something you should do, but so far, out of
> curiosity (and buggy code :-P), I've gotten away with it every time I've
> tried, and I'm curious what the possible ill effects are.  Thanks in
> advance.
> 
> James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://localhost.localdomain/pipermail/oclug-devel/attachments/20050529/fd3e4bbc/attachment.bin 

From james at colannino.org  Sun May 29 13:29:28 2005
From: james at colannino.org (James Colannino)
Date: Sun, 29 May 2005 13:29:28 -0700
Subject: [OCLUG-devel] malloc() woes
In-Reply-To: <429A1659.4080107@xman.org>
References: <429A12AC.5090400@colannino.org> <429A1437.3070806@colannino.org>
	<429A1659.4080107@xman.org>
Message-ID: <429A2628.9010100@colannino.org>

Christopher Smith wrote:

> If the buffer is filled, buffer[BUFFER_SIZE-1] should equal '\0'. It
> should never be '\n' unless from garbage memory.


You're right.  Thanks for catching that.  I changed the code to if
(buffer[BUFFER_SIZE - 2] = '\n')

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From james at colannino.org  Sun May 29 13:31:15 2005
From: james at colannino.org (James Colannino)
Date: Sun, 29 May 2005 13:31:15 -0700
Subject: [OCLUG-devel] malloc() woes
In-Reply-To: <429A14BA.2020902@xman.org>
References: <429A12AC.5090400@colannino.org> <429A14BA.2020902@xman.org>
Message-ID: <429A2693.9030206@colannino.org>

Christopher Smith wrote:

> Okay, so first thing is that I'm betting your "more_memory" function
> is not returning char*. Without seeing it's definition though, it's
> hard to be sure. 


It should be.  I probably should have posted it though.  Here's the
prototype:

char * more_memory(char *buffer);

You pass the function the old pointer and it returns a new pointer.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From james at colannino.org  Sun May 29 13:32:18 2005
From: james at colannino.org (James Colannino)
Date: Sun, 29 May 2005 13:32:18 -0700
Subject: [OCLUG-devel] malloc() woes
In-Reply-To: <1117396059.6518.159.camel@seki.nac.uci.edu>
References: <429A12AC.5090400@colannino.org>
	<1117396059.6518.159.camel@seki.nac.uci.edu>
Message-ID: <429A26D2.5040500@colannino.org>

Dan Stromberg wrote:

>You'll probably want to declare your initial "buffer" as a char *, and
>then get some memory for it via malloc(), when you first need to use it.
>
>Then if/when you're ready to change the amount of memory pointed to by
>buffer, you'll probably want to use realloc().
>  
>

That's a good idea.  I'll give that a go and see what happens.  Thanks :)

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From x at xman.org  Sun May 29 13:34:45 2005
From: x at xman.org (Christopher Smith)
Date: Sun, 29 May 2005 13:34:45 -0700
Subject: [OCLUG-devel] malloc() woes
In-Reply-To: <429A2693.9030206@colannino.org>
References: <429A12AC.5090400@colannino.org> <429A14BA.2020902@xman.org>
	<429A2693.9030206@colannino.org>
Message-ID: <429A2765.3090204@xman.org>

James Colannino wrote:

>Christopher Smith wrote:
>
>  
>
>>Okay, so first thing is that I'm betting your "more_memory" function
>>is not returning char*. Without seeing it's definition though, it's
>>hard to be sure. 
>>    
>>
>
>
>It should be.  I probably should have posted it though.  Here's the
>prototype:
>
>char * more_memory(char *buffer);
>
>You pass the function the old pointer and it returns a new pointer.
>  
>
What does it do with the old memory, and how does it decide how much new 
memory it needs to allocate?

--Chris

From hugo at teknofx.com  Sun May 29 13:52:54 2005
From: hugo at teknofx.com (Hugo Samayoa)
Date: Sun, 29 May 2005 13:52:54 -0700
Subject: [OCLUG-devel] arrays
In-Reply-To: <429A07FD.8060400@colannino.org>
References: <4299A801.4050406@colannino.org> <4299EC54.6090608@xman.org>
	<429A07FD.8060400@colannino.org>
Message-ID: <429A2BA6.3050204@teknofx.com>

James Colannino wrote:

>Christopher Smith wrote:
>
>  
>
>>C doesn't have any bounds checking so it's not going to stop you from
>>accessing data outside the array. Now, depending on how the allocator
>>is setup, there may be some "padding" around your array that prevents
>>really bad things from happening. In terms of what could go wrong?
>>Well, this is a classic example of how stack overflows occur. You're
>>writing past the end of the stack-allocated array, which means you're
>>writing all over the stack. I'm guessing you aren't having a problem
>>because you're exiting immediately after this. However, if this was in
>>a subroutine, then when you return, the subroutine would pop off the 5
>>bytes of your array and any arguments that were passed in, and then
>>pop off the return address. If the return address has been overwritten
>>by your array data, then it'll jump somewhere unanticipated. In most
>>cases this will be a segmentation fault because it'll be a totally
>>invalid address (which should be happening in this case). Sometimes
>>though, you can be unfortunate enough to write in an address that is
>>valid, at which your program will jump to that location and attempt to
>>execute instructions. Very, very messy.
>>    
>>
>
>
>By the way, I'm just curious, does the kernel ever do anything about a
>situation in which a process attempts to execute corrupted
>instructions?  I guess there's probably not much it could do, but does
>the kernel at least protect you from truly dangerous things that could
>result from the random contents of a variable being executed as
>instructions?  I'm guessing that since the kernel takes full control of
>the hardware it would probably protect you at least to a certain
>extent.  Perhaps such a thing could cause a kernel panic?
>
>James
>
>  
>
There's 5 ways to go about this...
1) Patch GCC to do bounds checking. > 
http://web.inter.nl.net/hcc/Haj.Ten.Brugge/
2) Use a tool to prevent smashing of the stack ie StackGuard or Stack 
Shield <- Protects EIP
3) Use a source code auditor ie RATS <- Posting your code to the list is 
also good.
4) Install a kernel patch that makes the stack non-executable. <- Just 
makes it harder to exploit.
5) Read some Buffer Overflow books, texts:
Aleph One's Smashing the Stack For Fun and Profit 
http://community.core-sdi.com/~juliano/smashing/P49-4-Smashing_the_stack.txt
Mudge's How to write Buffer Overflows 
http://community.core-sdi.com/~juliano/l0pht-howtowrite-bof.html

Good Book to start with.
Foster - Buffer Overflows ISBN - 1932266674


-Hugo Samayoa
Research Enginner @ eEye Digital Security

From james at colannino.org  Sun May 29 14:09:11 2005
From: james at colannino.org (James Colannino)
Date: Sun, 29 May 2005 14:09:11 -0700
Subject: [OCLUG-devel] malloc() woes
In-Reply-To: <429A2765.3090204@xman.org>
References: <429A12AC.5090400@colannino.org> <429A14BA.2020902@xman.org>
	<429A2693.9030206@colannino.org> <429A2765.3090204@xman.org>
Message-ID: <429A2F77.2030701@colannino.org>

Christopher Smith wrote:

> James Colannino wrote:
>
>> char * more_memory(char *buffer);
>>
>> You pass the function the old pointer and it returns a new pointer.
>>  
>>
> What does it do with the old memory, and how does it decide how much
> new memory it needs to allocate?


First it attempts to allocate new memory and store the pointer in a
temporary variable, buffer2.  If buffer2 isn't NULL, then the function
returns it.  If it is NULL, then the function returns the old pointer.

I modified the original program to declare buffer as a char * and use
malloc to determine its space, but basically, I start off with an
arbitrary size of 80 characters, and if it isn't enough to store the
entire line, more_memory() runs and doubles the space, afterwhich, the
program tries to read the same string into the buffer again.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From strombrg at dcs.nac.uci.edu  Sun May 29 17:59:24 2005
From: strombrg at dcs.nac.uci.edu (Dan Stromberg)
Date: Sun, 29 May 2005 17:59:24 -0700
Subject: [OCLUG-devel] arrays
In-Reply-To: <429A2BA6.3050204@teknofx.com>
References: <4299A801.4050406@colannino.org> <4299EC54.6090608@xman.org>
	 <429A07FD.8060400@colannino.org>  <429A2BA6.3050204@teknofx.com>
Message-ID: <1117414764.6518.184.camel@seki.nac.uci.edu>


Speaking of buffer overflows, has anyone had a go at compiling C
programs with "tcc -b" to enable buffer overrun checks?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://localhost.localdomain/pipermail/oclug-devel/attachments/20050529/60e4ac21/attachment.bin 

From james at colannino.org  Mon May 30 17:59:40 2005
From: james at colannino.org (James Colannino)
Date: Mon, 30 May 2005 17:59:40 -0700
Subject: [OCLUG-devel] fgets issues
Message-ID: <429BB6FC.7000001@colannino.org>

Hey everyone.  I have the following problem with fgets:

I have a string variable that I declare as the following:

char string[50];

I then open a file for reading using fopen, and I pass the pointer to
the file to another function called readstring().  Here's the function:

char * readstring(FILE *file) {

    int i;

    char *string_ptr = string;

    /* string is a globally defined variable; I wouldn't do that in
serious code unless there was no way around it */

    fgets(string_ptr, sizeof(string), file);

    if (string_ptr == NULL)
        return NULL;

    for (i = 0; (i - 1) != '\n'; i++) {
        if (string[i] == '\n')
            string[i] = '\0';
        else
            continue;
    }

    return string_ptr;
}

I then, in the main() function, call that function and then use printf()
to print the line read to the screen.  The man page of fgets tells me
that when fgets encounters EOF, it returns NULL.  Acting on this
assumption, I used the following loop to print every part of a file to
the screen:

char *string_ptr;

while (string_ptr != NULL) {
    string_ptr = readstring(file);
    printf ("%s\n", string_ptr);
}

In theory, string_ptr should be NULL after it's reached the end of the
file, but what happens is that fgets just continuously reads the line
before EOF over and over again.  Up until that point, it works, and
everytime I call fgets it moves further down the file.  However, at the
end, I get caught in an endless loop that prints the last line of the
file to the screen over and over again.

Just in case this makes a difference, I'm reading a file edited by nano
in which an empty line (lacking a '\n' character) is placed below the
last ordinary line of text.

This has me stumped :(  Am I missing something that should be obvious? 
Thanks in advance.

James

P.S. If anyone's interested, here's the entire program:

#include <stdio.h>

char * readstring(FILE *file);

char string[80];

int main(void) {

    int i;   /* used for the for loop */

    FILE *file;   /* the file I'm opening */
    file = fopen("sample.items", "r");
        if (file == NULL) {
            printf ("error opening file.\n");
            return -1;
        }

    char *string_ptr;   /* pointer returned by readstring() */

    /* loop until the pointer returned by readstring() is NULL */

    while (string_ptr != NULL) {
        string_ptr = readstring(file);
        printf ("%s\n", string_ptr);
    }

    return 0;
}


char * readstring(FILE *file) {

    int i;   /* used by the for loop */

    /* create a pointer to the globally defined string variable */
    char *string_ptr = string;

    fgets(string_ptr, sizeof(string), file);

    if (string_ptr == NULL)
        return NULL;

    /* this strips the '\n' character from the string */

    for (i = 0; (i - 1) != '\n'; i++) {
        if (string[i] == '\n')
            string[i] = '\0';
        else
            continue;
    }

    return string_ptr;
}

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment


From james at colannino.org  Mon May 30 18:14:12 2005
From: james at colannino.org (James Colannino)
Date: Mon, 30 May 2005 18:14:12 -0700
Subject: [OCLUG-devel] fgets issues
In-Reply-To: <429BB6FC.7000001@colannino.org>
References: <429BB6FC.7000001@colannino.org>
Message-ID: <429BBA64.9020109@colannino.org>

As a sidenote, I found a temporary solution.  I re-wrote the while loop
to do the following:

    while (1) {
        text = getstring(file);
        printf ("%s\n", text);

        if (feof(file))
            break;
    }

That's probably not the best solution, and I'm still interested in the
answer to my original question, but for now I got it to work :)
(although I don't know if it's the best solution.)

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"A well regulated militia being necessary to the security of a free
state, THE RIGHT of the people to keep and bear arms SHALL NOT BE
INFRINGED." --United States Constitution, Second Ammendment