Re: Get_Line vs Adasockets

["David Thompson" <david.thompson1@worldnet.att.net>]

Ken Garlington <Ken.Garlington@computer.org> wrote :
...
> important difference between C and Ada. In C, you would do a read like this:
>
>    read(incoming_socket, buf, sizeof(buf));
>
Actually result_len_or_err_flag = read ...;
Yes, combining both in one return value is ugly.

> where "buf" is the buffer you've allocated, and sizeof(buf) is the maximum
> size of the string you'll accept. You have to pass the size of the buffer
> separately, since in C the size of an array is not intrinsically available
> to the called program.

Yes.

> ... To find out the length of the string that was
> actually passed, you would do something like
>
>    current_string_length = strlen(buf)
>
> which would determine the size of the string based on where the null
> terminator is located.
>
No.  (I assume you mean actually received/"returned".)
But read() (or recv() or other similar OS calls) does *not*
add the null terminator needed to ensure a valid C string,
plus it is perfectly valid (to the OS and socket stack)
for the data received to *include* null data characters.
(Whether it is valid for the protocol you are implementing,
e.g. HTTP SMTP FTP etc., is your problem.)

You use the value returned from read(), if > 0.
If < 0 (canonically -1), an error occurred; if = 0,
you hit end of file (which for an incoming TCP socket
means the peer entity has done a TCP shutdown).
You must check; no exceptions are raised.

If you want to treat the incoming socket (or other file)
as text lines, use the "high[er] level" (and Standard!)
facilities of <stdio.h>.  On Un*x at least you can "wrap"
an already open socket in a stdio stream with fdopen().
Then use fgets(), which still needs to be passed
the buffer size explicitly, but stops at "newline"
(canonically one character in C) and appends
the null terminator to ensure a valid C string.

>  The equivalent in Ada is ...

--
- David.Thompson 1 now at worldnet.att.net