Mon Dec 10 04:50:08 2018
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2014-08-01

HANGOUT

2018-12-10 | 2018-11-10 | 2018-10-10 | 2018-09-10 | 2018-08-10 | 2018-07-10 | 2018-06-10 | 2018-05-10 | 2018-04-10 | 2018-03-10 | 2018-02-10 | 2018-01-10 | 2017-12-10 | 2017-11-10 | 2017-10-10 | 2017-09-10 | 2017-08-10 | 2017-07-10 | 2017-06-10 | 2017-05-10 | 2017-04-10 | 2017-03-10 | 2017-02-10 | 2017-01-10 | 2016-12-10 | 2016-11-10 | 2016-10-10 | 2016-09-10 | 2016-08-10 | 2016-07-10 | 2016-06-10 | 2016-05-10 | 2016-04-10 | 2016-03-10 | 2016-02-10 | 2016-01-10 | 2015-12-10 | 2015-11-10 | 2015-10-10 | 2015-09-10 | 2015-08-10 | 2015-07-10 | 2015-06-10 | 2015-05-10 | 2015-04-10 | 2015-03-10 | 2015-02-10 | 2015-01-10 | 2014-12-10 | 2014-11-10 | 2014-10-10 | 2014-09-10 | 2014-08-10 | 2014-07-10 | 2014-06-10 | 2014-05-10 | 2014-04-10 | 2014-03-10 | 2014-02-10 | 2014-01-10 | 2013-12-10 | 2013-11-10 | 2013-10-10 | 2013-09-10 | 2013-08-10 | 2013-07-10 | 2013-06-10 | 2013-05-10 | 2013-04-10 | 2013-03-10 | 2013-02-10 | 2013-01-10 | 2012-12-10 | 2012-11-10 | 2012-10-10 | 2012-09-10 | 2012-08-10 | 2012-07-10 | 2012-06-10 | 2012-05-10 | 2012-04-10 | 2012-03-10 | 2012-02-10 | 2012-01-10 | 2011-12-10 | 2011-11-10 | 2011-10-10 | 2011-09-10 | 2011-08-10 | 2011-07-10 | 2011-06-10 | 2011-05-10 | 2011-04-10 | 2011-03-10 | 2011-02-10 | 2011-01-10 | 2010-12-10 | 2010-11-10 | 2010-10-10 | 2010-09-10 | 2010-08-10 | 2010-07-10 | 2010-06-10 | 2010-05-10 | 2010-04-10 | 2010-03-10 | 2010-02-10 | 2010-01-10 | 2009-12-10 | 2009-11-10 | 2009-10-10 | 2009-09-10 | 2009-08-10 | 2009-07-10 | 2009-06-10 | 2009-05-10 | 2009-04-10 | 2009-03-10 | 2009-02-10 | 2009-01-10 | 2008-12-10 | 2008-11-10 | 2008-10-10 | 2008-09-10 | 2008-08-10 | 2008-07-10 | 2008-06-10 | 2008-05-10 | 2008-04-10 | 2008-03-10 | 2008-02-10 | 2008-01-10 | 2007-12-10 | 2007-11-10 | 2007-10-10 | 2007-09-10 | 2007-08-10 | 2007-07-10 | 2007-06-10 | 2007-05-10 | 2007-04-10 | 2007-03-10 | 2007-02-10 | 2007-01-10 | 2006-12-10 | 2006-11-10 | 2006-10-10 | 2006-09-10 | 2006-08-10 | 2006-07-10 | 2006-06-10 | 2006-05-10 | 2006-04-10 | 2006-03-10 | 2006-02-10 | 2006-01-10 | 2005-12-10 | 2005-11-10 | 2005-10-10 | 2005-09-10 | 2005-08-10 | 2005-07-10 | 2005-06-10 | 2005-05-10 | 2005-04-10 | 2005-03-10 | 2005-02-10 | 2005-01-10 | 2004-12-10 | 2004-11-10 | 2004-10-10 | 2004-09-10 | 2004-08-10 | 2004-07-10 | 2004-06-10 | 2004-05-10 | 2004-04-10 | 2004-03-10 | 2004-02-10 | 2004-01-10 | 2003-12-10 | 2003-11-10 | 2003-10-10 | 2003-09-10 | 2003-08-10 | 2003-07-10 | 2003-06-10 | 2003-05-10 | 2003-04-10 | 2003-03-10 | 2003-02-10 | 2003-01-10 | 2002-12-10 | 2002-11-10 | 2002-10-10 | 2002-09-10 | 2002-08-10 | 2002-07-10 | 2002-06-10 | 2002-05-10 | 2002-04-10 | 2002-03-10 | 2002-02-10 | 2002-01-10 | 2001-12-10 | 2001-11-10 | 2001-10-10 | 2001-09-10 | 2001-08-10 | 2001-07-10 | 2001-06-10 | 2001-05-10 | 2001-04-10 | 2001-03-10 | 2001-02-10 | 2001-01-10 | 2000-12-10 | 2000-11-10 | 2000-10-10 | 2000-09-10 | 2000-08-10 | 2000-07-10 | 2000-06-10 | 2000-05-10 | 2000-04-10 | 2000-03-10 | 2000-02-10 | 2000-01-10 | 1999-12-10

Key: archive Value: 2014-08-01

Key: id Value: 542460

MESSAGE
DATE 2014-08-29
FROM Ruben Safir
SUBJECT Subject: [NYLXS - HANGOUT] C Pointer Reviews
From owner-hangout-outgoing-at-mrbrklyn.com Fri Aug 29 19:47:19 2014
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 803B116116B; Fri, 29 Aug 2014 19:47:19 -0400 (EDT)
Delivered-To: hangout-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 6B65B161171; Fri, 29 Aug 2014 19:47:19 -0400 (EDT)
Delivered-To: hangout-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 04B1016116B
for ; Fri, 29 Aug 2014 19:47:18 -0400 (EDT)
Received: from [10.0.0.57] (unknown [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTP id 87F622EA39
for ; Fri, 29 Aug 2014 19:47:17 -0400 (EDT)
Message-ID: <5401113B.8090908-at-panix.com>
Date: Fri, 29 Aug 2014 19:48:11 -0400
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: hangout
Subject: [NYLXS - HANGOUT] C Pointer Reviews
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: owner-hangout-at-mrbrklyn.com
Precedence: bulk
Reply-To: hangout-at-mrbrklyn.com

Not Mine:



http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BitOp/pointer.html


Pointer Arithmetic


Introduction

There's a joke that C has the speed and efficieny of assembly language
combined with readability of....assembly language. In other words, it's
just a glorified assembly language.

It's perhaps too harsh a judgement of C, but certainly one of the
reasons the language was invented was to write operating systems.
Writing such code requires the ability to access addresses in memory in
an efficient manner. This is why pointers are such an important part of
the C language. They're also a big reason programmers have bugs.

If you're going to master C, you need to understand pointer arithmetic,
and in particular, the relationship between arrays and pointers.


Arbitrary Pointer Casting

Because most ISAs use the same number of bits as integers, it's not so
uncommon to cast integers as pointers.

Here's an example.

// Casting 32 bit int, 0x0000ffff, to a pointer
char * ptr = reinterpret_cast( 0x0000ffff ) ;
char * ptr2 = reinterpret_cast( 0x0000ffff ) ;

In general, this is one of the pitfalls of C. Arbitrary pointer casting
allows you to point anywhere in memory.

Unfortunately, this is not good for safe programs. In a safe programming
language (say, Java), the goal is to access objects from pointers only
when there's an object there. Furthermore, you want to call the correct
operations based on the object's type.

Arbitrary pointer casting allows you to access any memory location and
do anything you want at that location, regardless of whether you can
access that memory location or whether the data is valid at that memory
location.


Arrays and Pointer Arithmetic

In C, arrays have a strong relationship to pointers.

Consider the following declaration.

int arr[ 10 ] ;

What type does *arr* have? You might say "it's an int array". And, so it
is. However, *arr*, by itself, without any index subscripting, can be
assigned to an integer pointer.

OK, now what do you think of *arr[ i ]*? What is that? (Assume *i* is
some int). You might say, it's the *i^th * element of the array. That's
correct too. What type does *arr[i]* have?

It's an *int*! (Beginning programming students often think *arr[ i ]* is
not the same as an int, because it uses brackets. It takes a while to
convince them they have the same type as a plain int variable).

Do you know, however, that *arr[ i ]* is defined using pointer arithmetic?

In particular:

arr[ i ] == * ( arr + i )

Let's take a closer look at *arr + i*. What does that mean? *arr* is a
pointer to *arr[ 0 ]*. In fact, it is defined to be *& arr[ 0 ]*.

A pointer is an address in memory. *arr* contains an address in
memory---the address where *arr[ 0 ]* is located.

What is *arr + i*? If *arr* is a pointer to *arr[ 0 ]* then *arr + i* is
a pointer to *arr[ i ]*.

Perhaps this is easier shown in a diagram.

We assume that each *int* takes up 4 bytes of memory. If *arr* is at
address 1000, then *arr + 1* is address 1004, *arr + 2* is address 1008,
and in general, *arr + i* is address *1000 + (i * 4)*.

Now that you see the diagram, something may strange. Why is *arr + 1* at
address 1004 and not 1001?

That's pointer arithmetic in action. *arr + 1* points to one element
past *arr*. *arr + 3* is points to 3 elements past *arr*. Thus, *arr +
i* points to *i* elements past *arr*.

The idea is to have *arr + i* point to *i* elements after *arr*
regardless of what type of element the array holds.


The Type's the Thing

Suppose the array had contained *short* where a *short* is only 2 bytes.
If *arr* is at address 1000, then, *arr + 1* is address 1002 (instead of
1004). *arr + 2* is at address 1004 (instead of 1008), and in general
*arr + i* is at address *1000 + (2 * i)*.

Here's a diagram of that.

Notice that *arr + 1* is now 2 bytes after *arr* and *arr + 2* is 4
bytes. When we had an int array, *arr + 1* was 4 bytes after *arr* and
*arr + 2* was 8 bytes afterwards.

Why is there a difference? What's the differnce between *arr* before and
now?

The difference is in the type. Before, *arr* had (roughly) type *int **
and now *arr* has type *short **.

In C, a pointer is not only an address, it tells you what (in principle)
the data type at that address is. Thus, *int ** is a pointer to an int.
Not only does it tell you the data type, but you can also determine the
data type's size.

You can find out the data type's size with the *sizeof()* operator.

sizeof( int ) ==> 4
sizeof( short ) ==> 4

That's important, because that's how pointer arithmetic computes
address. It uses the size of the data type, which it knows from the
pointer's type.

Here's the formula for computing the address of *ptr + i* where *ptr*
has type *T **. then the formula for the address is:

addr( ptr + i ) = addr( ptr ) + [ sizeof( T ) * i ]


T can be a pointer

How does pointer arithmetic work if you have an array of pointers, for
example:

int * arr[ 10 ] ;
int ** ptr = arr ;

In this case, *arr* has type *int ***. Thus, *T* has type *int **. All
pointers have the same size, thus the address of *ptr + i* is:

addr( ptr + i ) = addr( ptr ) + [ sizeof( int * ) * i ]
= addr( ptr ) + [ 4 * i ]


Static arrays are constant

When you declare

int arr[ 10 ] ;

*arr* is a constant. It is defined to be the address, *& arr[ 0 ]*.

You can't do the following:

int arr[ 10 ] ;

arr = arr + 1 ; // NO! Can't reassign to arr--it's constant

However, you can declare a pointer /variable/.

int arr[ 10 ] ;
int * ptr ;

ptr = arr + 1 ; // This is OK. ptr is a variable.


Parameter Passing an Array

If you pass an array to a function, it's type changes.

void foo( int arr[ 10 ], int size ) {
// code here
}

The compiler translates arrays in a parameter list to:

void foo( int * arr, int size ) {
// code here
}

Thus, it becomes *arr* becomes a pointer variable.

Why doesn't this cause problems? After all, won't we pass *arr* as an
argument? Isn't *arr* a constant?

Yes, it is. However, we pass a *copy* of the address to *arr* the
parameter. Thus, the copy can be manipulated while the original pointer
address that was passed during the function call is unchanged.


Subtraction

We can also compute *ptr - i*. For example, suppose we have an int array
called *arr*.

int arr[ 10 ] ;
int * p1, * p2 ;

p1 = arr + 3 ; // p1 == & arr[ 3 ]
p2 = p1 - 2 ; // p1 == & arr[ 1 ]

We can have a pointer point to the middle of the array (like *p1*). We
can then create a new pointer that is two elements back of *p1*.

As it turns out, we can even point way past the end of the array.

int arr[ 10 ] ;
int * p1, * p2 ;

p1 = arr + 100 ; // p1 == & arr[ 100 ]
p2 = arr - 100 ; // p1 == & arr[ -100 ]

The compiler still computes an address, and does not core dump. For
example, if *arr* is address 1000_ten , then *p1* is address *1400_ten *
and *p2* is address *600_ten *. The compiler still uses the formula for
pointer arithmetic to compute the address.


Passing the Array Size

This is why it's usually important to keep track of the array size and
pass it in as a parameter. When you're in a function, you can't tell the
size of the array. All you have is a pointer, and that's it. No
indication of how big that array is.

If you try to compute the array's size using *sizeof*, you just get 4.

// Compiler translates arr's type to int *
void foo ( int arr[], int size ) {
// Prints 4
cout << sizeof( arr ) ;

int arr2[ 10 ] ;

// Prints 40
cout << sizeof( arr2 ) ;
}

If you declare a local array (not using dynamic memory allocation), you
can get the size of the array. However, once you pass that array, all
that's passed is the address. There's no information about the array
size anymore.


Two dimensional Arrays

Suppose you declare:

int arr[ 10 ][ 12 ] ;

What type is *arr*? You may have been told that it's *int ***, but
that's incorrect. Two dimensional arrays (as declared above) are
contiguous in memory. If you create an array of pointers to dynamically
allocated arrays, such as:

int * arr[ 10 ] ;

then, *arr* has type *int *** (or at least has a type compatible with
*int ***).

The type is rather complicated, and is due to the fact that *arr[ 0 ] =
& arr[ 0 ][ 0 ]*, *arr[ 1 ] = & arr[ 1 ][ 0 ]*, and in general, *arr[ i
] = & arr[ i ][ 0 ]*.

Pointer arithmetic says that *arr + i* gives you *& arr[ i ]*, yet this
skips an entire row of 12 elements, i.e., skips 48 bytes times *i*.
Thus, if *arr* is address *1000_ten *, then *arr + 2* is address
*1096_ten *.

If the array's type were truly *int ***, pointer arithmetic would say
the address is *1008_ten *, so that doesn't work.

So, what's the lesson?

/*A two-dimensional array is not the same as an array of pointers to
1D arrays*/

The actual type for a two-dimensional array, is declared as:

int (*ptr)[ 10 ] ;

Which is a pointer to an array of 10 elements. Thus, when you do pointer
arithmetic, it can compute the size of the array and handle it
correctly. The parentheses are NOT optional above. Without the
parentheses, *ptr* becomes an array of 10 pointers, not a pointer to an
array of 10 ints.

If you have a conventional two dimensional array, and you want to
compute the address for *arr[ row ][ col ]* and you have *ROWS* rows
(where ROWS is some constant) and *COLS* columns, then the formula for
the address in memory is:

addr( & arr[ row ][ col ] ) = addr( arr ) + [ sizeof( int ) * COLS * row ]
+ [ sizeof( int ) * col ]

Two dimensional arrays are stored in row major order, that is, row by
row. Each row contains *COLS* elements, which is why you see *COLS* in
the formula. In fact, you don't see *ROWS*.

When you have a 2D array as a parameter to a function, there's no need
to specify the number of rows. You just need to specify the number of
columns. The reason is the formula above. The compiler can compute the
address of an element in a 2D array just knowing the number of columns.

Thus, the following is valid in C, i.e. it compiles:

void sumArr( int arr[][ COLS ], int numRows, int numCols ) {
}

The following is also valid in C.

void sumArr( int arr[ ROWS ][ COLS ], int numRows, int numCols ) {
}

The compiler ignores ROWS. Thus, any 2D array with the *COLS* columns
and any number of rows can be passed to this function.

The following, however, is NOT valid in C:

void sumArr( int arr[][], int numRows, int numCols ) {
}

It's not syntactically valid to declare *int arr[][]* in C.

However, it's OK to write:

void sumArr( int **arr, int numRows, int numCols ) {
}

Note that *int **arr* is an array of pointers (possibly to 1D arrays),
while *int arr[][ COLS ]* is a 2D array. They are not the same type, and
are not interchangeable.


Pointer Subtraction

It turns out you can subtract two pointers of the same type. The result
is the distance (in array elements) between the two elements.

For example:

int arr[ 10 ] ;
int * p1 = arr + 2 ;
int * p2 = arr + 5 ;

cout << ( p2 - p1 ) ; // Prints 3
cout << ( p1 - p3 ) ; // Prints -3

The formula used is rather simple. Assume that *p1* and *p2* are both
pointers of type *T **. Then, the value computed is:

( p2 - p1 ) == ( addr( p2 ) - addr( p1 ) ) / sizeof( T )

This can result in negative values if *p2* has a smaller address than *p1*.

*p2* and *p1* need not point to valid elements in an array. The formula
above still works even when *p2* and *p1* contain invalid addresses
(because they contain /some/ address).

Pointer subtraction isn't used very much, but can be handy to determine
the distances between two array elements (i.e., the difference in the
array indexes). You may not know exactly which element you're pointing
to using pointer subtraction, but you can tell relative distances.


Dereferencing causes problems

In general, you can make a pointer point anywhere. For example, *arr +
1000* is valid, even if the array has only ten elements. *arr - 1000* is
also valid. That is, you can compute it, and it won't core dump.

However, /dereferencing/ pointers to invalid memory causes problems.
Thus, **( arr - 1000 )* core dumps because you are trying to access the
address.

Here's an analogy. You can write down anyone's address on a piece of
paper, however, you can't just go inside the person's house at that
address (which is like dereferencing). Thus, computing addresses is
fine, dereferencing it may cause problems if the address is not a valid
address in memory.


Nasty Types in C

In "C" you can create really difficult types. For example, function
pointers have horrid syntax, as do pointers in 2D arrays. This makes
certain kinds of declarations in C a pain to read.

Fortunately, our goal is simply to understand pointer arithmetic which
is adding integers to pointers and subtracting pointers. This allows us
to get a view of how C computes addresses.


Summary

A knowledge of pointer arithmetic separates those who passably know C,
from those who know C really well. It's said that a good programmer
understands pointers very well, while an average programmer finds
anything with more than one pointer difficult to manage (e.g., a pointer
to a pointer to an int is seen as difficult).

Part of the reason we study this is the importance of pointers in C and
the importance of C to systems programming, which falls under
"low-level" programming.

  1. 2014-08-03 Contrarian <adrba-at-nyct.net> Re: [NYLXS - HANGOUT] I was really really dumb
  2. 2014-08-04 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] I was really really dumb
  3. 2014-08-04 Ron Guerin <ron-at-vnetworx.net> Re: [NYLXS - HANGOUT] I was really really dumb
  4. 2014-08-04 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] I was really really dumb
  5. 2014-08-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Weeeeeee!!!
  6. 2014-08-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Email Survalience
  7. 2014-08-05 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Email Survalience
  8. 2014-08-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Linux Programming
  9. 2014-08-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Linux Classes
  10. 2014-08-05 einker <eminker-at-gmail.com> Re: [NYLXS - HANGOUT] Linux Classes
  11. 2014-08-05 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Linux Classes
  12. 2014-08-05 einker <eminker-at-gmail.com> Re: [NYLXS - HANGOUT] Linux Classes
  13. 2014-08-05 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Linux Classes
  14. 2014-08-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] NYLXS Meeting
  15. 2014-08-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: Fwd: Coding Tutor
  16. 2014-08-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: Coding Tutor
  17. 2014-08-05 Ron Guerin <ron-at-vnetworx.net> Re: [NYLXS - HANGOUT] Re: Coding Tutor
  18. 2014-08-06 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Linux Jobs
  19. 2014-08-06 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: Coding Tutor
  20. 2014-08-06 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] QUIZ Time!!
  21. 2014-08-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] QUIZ Time!!
  22. 2014-08-06 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Movie Night
  23. 2014-08-07 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Movie Night
  24. 2014-08-07 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] monkey copyright
  25. 2014-08-07 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] monkey copyright
  26. 2014-08-07 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: Coding Tutor
  27. 2014-08-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: Coding Tutor
  28. 2014-08-11 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Robin Williams Died
  29. 2014-08-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Movie of the Week
  30. 2014-08-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Training Scholarships
  31. 2014-08-14 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] artificial music
  32. 2014-08-14 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] NYLXS Meeting
  33. 2014-08-14 eminker-at-gmail.com Re: [NYLXS - HANGOUT] NYLXS Meeting
  34. 2014-08-14 eminker-at-gmail.com Re: [NYLXS - HANGOUT] NYLXS Meeting
  35. 2014-08-14 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] NYLXS Meeting
  36. 2014-08-14 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] NYLXS Meeting
  37. 2014-08-16 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] NYLXS Meeting
  38. 2014-08-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] networking puzzle
  39. 2014-08-17 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] networking puzzle - Optimum Tech Support to
  40. 2014-08-17 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [richter-at-ecos.de: ANNOUNCE: Embperl 2.5.0]
  41. 2014-08-18 Kevin Mark <kevin.mark-at-verizon.net> Re: [NYLXS - HANGOUT] End of my pharmacy career?
  42. 2014-08-18 Kevin Mark <kevin.mark-at-verizon.net> Re: [NYLXS - HANGOUT] End of my pharmacy career?
  43. 2014-08-18 Kevin Mark <kevin.mark-at-verizon.net> Re: [NYLXS - HANGOUT] NYLXS Meeting
  44. 2014-08-18 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] End of my pharmacy career?
  45. 2014-08-18 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] End of my pharmacy career?
  46. 2014-08-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] fare beaters united!
  47. 2014-08-19 Kevin Mark <kevin.mark-at-verizon.net> Re: [NYLXS - HANGOUT] End of my pharmacy career?
  48. 2014-08-19 Kevin Mark <kevin.mark-at-verizon.net> Re: [NYLXS - HANGOUT] End of my pharmacy career?
  49. 2014-08-19 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] End of my pharmacy career?
  50. 2014-08-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Linux Jobs
  51. 2014-08-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Job Inquiries
  52. 2014-08-19 Kevin Mark <kevin.mark-at-verizon.net> Re: [NYLXS - HANGOUT] End of my pharmacy career?
  53. 2014-08-19 Kevin Mark <kevin.mark-at-verizon.net> Re: [NYLXS - HANGOUT] End of my pharmacy career?
  54. 2014-08-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Paper Rxs Quickly Becoming a Thing of the Past | Pharmacist
  55. 2014-08-19 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Fwd: Paper Rxs Quickly Becoming a Thing of
  56. 2014-08-19 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] End of my pharmacy career?
  57. 2014-08-19 Ruben Safir <mrbrklyn-at-panix.com>
  58. 2014-08-20 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Movie of the Week
  59. 2014-08-20 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Movie of the Week
  60. 2014-08-20 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] opeldap ebook
  61. 2014-08-20 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Books to learn LDAP services
  62. 2014-08-20 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Best States to Move to the economy
  63. 2014-08-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [eblake-at-redhat.com: POSIX ruling on up-to-date vs. identical
  64. 2014-08-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] All your futures are mine
  65. 2014-08-22 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [isoc-ny] U.S. -at-CopyrightOffice issues draft of 3rd edition
  66. 2014-08-22 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] old coders
  67. 2014-08-24 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] I'd be happy to pay of a GNU Desktop that works - College Bound
  68. 2014-08-24 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] more college choices
  69. 2014-08-25 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Shoshana's wedding
  70. 2014-08-25 Robert Menes <viewtiful.icchan-at-gmail.com> Re: [NYLXS - HANGOUT] Shoshana's wedding
  71. 2014-08-25 einker <eminker-at-gmail.com> Re: [NYLXS - HANGOUT] Shoshana's wedding
  72. 2014-08-25 einker <eminker-at-gmail.com> Re: [NYLXS - HANGOUT] Shoshana's wedding
  73. 2014-08-25 einker <eminker-at-gmail.com> Re: [NYLXS - HANGOUT] Shoshana's wedding
  74. 2014-08-25 einker <eminker-at-gmail.com> Re: [NYLXS - HANGOUT] Shoshana's wedding
  75. 2014-08-25 Paul Robert Marino <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] Shoshana's wedding
  76. 2014-08-25 Ron Guerin <ron-at-vnetworx.net> Re: [NYLXS - HANGOUT] Shoshana's wedding
  77. 2014-08-26 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Shoshana's wedding
  78. 2014-08-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: [lisa-at-gatestaffing.com: [php-337] [JOB] PHP
  79. 2014-08-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Graduate School Prerequesits
  80. 2014-08-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] I'd be happy to pay of a GNU Desktop that works
  81. 2014-08-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: [nylug-talk] I'd be happy to pay of a GNU Desktop that works
  82. 2014-08-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] BS versus MS cont...
  83. 2014-08-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [info-at-meetup.com: New comment in Jos?? Valim presents Elixir!]
  84. 2014-08-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [info-at-meetup.com: Tomorrow: You and 150 other Ruby developers are
  85. 2014-08-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [info-at-meetup.com: New comment in Jos?? Valim presents Elixir!]
  86. 2014-08-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [nyc-on-rails] NYC Talent Hack
  87. 2014-08-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] the Go Language
  88. 2014-08-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Meeting Tonight
  89. 2014-08-28 Paul Robert Marino <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] the Go Language
  90. 2014-08-28 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] the Go Language
  91. 2014-08-28 Paul Robert Marino <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] the Go Language
  92. 2014-08-28 Paul Robert Marino <prmarino1-at-gmail.com> Subject: [NYLXS - HANGOUT] New GLP firewall project
  93. 2014-08-28 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] New GLP firewall project
  94. 2014-08-28 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] New GLP firewall project
  95. 2014-08-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Ruby groups
  96. 2014-08-28 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Ruby groups
  97. 2014-08-29 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] C Pointer Reviews
  98. 2014-08-29 Ron Guerin <ron-at-vnetworx.net> Re: [NYLXS - HANGOUT] Ruby groups
  99. 2014-08-30 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Ruby groups
  100. 2014-08-30 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Math and Computer Sciences
  101. 2014-08-31 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Degrees to get back to work after 50...

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!