SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 03 | June | 1998 ]

<< Previous Message << >> Next Message >>


Date: Wed, 3 Jun 1998 08:05:54 PST8PDT
From: Peter Skye <pskye@peterskye.com >
Reply-To: scoug-programming@scoug.com
To: scoug-programming@scoug.com
Subject: SCOUG-Programming: Summarizing

Content Type: text/plain

Rollin White wrote:
>
> Let's proceed with with our definition of GetLine(). It must:
>
> 1. Read and return a pointer to a line of data received on the specified socket.
> 2. Remove any line delimiters (CR, LF, or both)
> 3. Must not modify the line data in any other way
> 4. Be able to indicate a timeout or disconnect condition
>
> What else?

For starters, you might get a CR as your last character just before its
trailing LF hits the buffer, so that CR is at the end of your string and
LF is at the front of the next string. So what happens if the first
buffer character is LF?

I've got to review RFC 959 which Greg mentioned ... I'm still real
nervous about allowing BS, RUBOUT and whatever else through. If the
protocol is relying on "the other guy" to not send us these characters,
remember that "the other guy" isn't just the person/program at the other
end of the wire; it's also everything in our local machine that does or
doesn't do something with the data before we get it.

The actual "bad things" that might happen if these characters get
through are, of course, minimal. The Q&D ("quick and dirty") approach
is just to let them through, and if the string fails syntactically in
the parser throw the whole thing out. The elegant method is to allow
for everything that might happen and write extra to code that is either
never or almost never used, depending on what happens in real world
situations.

I'm willing to go Q&D on this project. Buff it out later.

- Peter Skye

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================


<< Previous Message << >> Next Message >>

Return to [ 03 | June | 1998 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.