Re: Zero terminated strings

On 4 Aug, 20:22, Flash Gordon <s...@xxxxxxxxxxxxxxxxx> wrote:
Nick Keighley wrote:
On 4 Aug, 08:06, Flash Gordon <s...@xxxxxxxxxxxxxxxxx> wrote:
Tech07 wrote:
"Flash Gordon" <s...@xxxxxxxxxxxxxxxxx> wrote in message
news:l8egk6xq4v.ln2@xxxxxxxxxxxxxxxxxxxxxxxxxx
Moi wrote:
On Sun, 02 Aug 2009 11:16:04 +0000, bartc wrote:
"Flash Gordon" <s...@xxxxxxxxxxxxxxxxx> wrote in message
news:v7adk6x42j.ln2@xxxxxxxxxxxxxxxxxxxxxxxxxx
Gareth Owen wrote:
jacob navia <ja...@xxxxxxxxxx> writes:

[sero terminated strings]

<snip>





One could inductively reason about
the list of requirements that led to the null-terminated design, but there
probably wasn't any such formal or thorough analyses. The analysis is easier
done in retrospect. I'm not sure what portion of the C/C++ programming
languages crowd has either opinion, but I have an incling that most would
opt for a different solution if it was C language creation time right now.
For doing major string handling you want a language where strings are a
first class type, at which point whether the strings are counted, use a
sentinel or whatever becomes largely irrelevant to the person using the
language (there are ways of embedding a sentinel in a
sentinel-terminated blob of data).

by first class you mean assignable and capable being compared
for equality?

   string s;
   string t = "hello";
   s = "hello";
  if (s == t) f (s);

You can write code like that in C++

And then if f is defined as

void f(string str)
{
    /* Modify str */

}

Then str is passed by value (if other built in types are) so the
modification to str does not affect s in the caller...

All the memory management handled for you, just as it is for type int...
including when you do things like string concatenation etc

The type being available without having to take extra measures...





I'm not
ready to say whether a library-only approach can adequately remedy the
issues, but of course, an ISO Standard remedy is much more difficult to do
than an in-house one.
A library approach will ALWAYS have major disadvantages compared to a
fully built in string type (built in the same way int is in C).

a language that provides the right hooks can add first class types.
Eg. C++ (and maybe Navia-C)

However,
building it in to C properly would be a massive change (even C++ has not
done it as I understand, just faked it with clases).

in what way has C++ "faked it". You can some pretty clever things
with C++ strings.

Well, I can't say I've learned C++, so I don't know how closely it fits.

Train people by making them write comms software over poor serial links
where you get significant amounts of corruption, they will soon learn
simple "tricks" (so simple they can easily be implemented in assembler
even) that will deal with bad data.

I'm not sure I'd like to rely on an application that relied
on "simple tricks" to recover from comms errors!

Why not use a decent link-level protocol?

Simple "tricks" are all you need to implement a decent link level
protocol. I know, I've done it. I did it so well with worked with the
data going across 4 serial links, one of which was un-shieled 3-wire
(data-in, data-out and signal ground) in an electrically noisy environment.

Wait for a valid first byte of a header (anything else you receive is
obviously invalid)

Check the header bytes (including message type and length, for which you
know the valid range) as they are coming in and assume that you have
dropped at least one byte if any of them are wrong. Check the checksum
at the end.

If you are happy with a checksum then you didn't have a very noisy
line.

"simple tricks" go something like

parity, checksum, crc, golay encoding (or other inter leaving
scheme),
FEC

I submit that somewher ein the middle of thta it stops being simple.

<snip basic link layer protocol>

take a look ar LAP-D or a varient.

<snip>

What is relevant to my original point (giving people experience of
working on systems with highly unreliable data transfer, and having them
solve the problem) is seeing the interface failing abysmally (before I
rewrote it as described) because there was *not* a link level protocol
seriously hammered in to me how unreliable data is when it comes from
else where, *even* when the "else where" is another computer sitting
within about four feet of the final destination and me having complete
control over all systems involved!

I suppose inventing all this is educational (I've built such
protocols
myself) but you'd really be better off not reinventing wheels.

Tanenbaum's books used to be good (they even have jokes in them!)


In other conditions (e.g. where I had to worry about bandwidth so just
repeatedly throwing the packet was not appropriate) I would want
something more sophisticated.


--
The nice thing about standards is that there are so many of them to
choose from.
Andrew S. Tanenbaum
.

Quantcast