Re: null terminated strings

In article <43E9029A.8EC832CC@xxxxxxxxxxxx>,
JF Mezei <jfmezei.spamnot@xxxxxxxxxxxx> writes:
sol gongola wrote:
program does no data validation (or length checking). Null (or other)
terminated strings are blamed because they were being used in the programs
involved with the overrun situation. It's really the code that is at fault.

My first reaction is to agree with the above. When you write routines
that will write to a buffer, you should require the caller to supply a
maximum length for that buffer and make sure you don't exceed it.

And the io commands in C such as fread do provide a maximum length argument.

However, strcpy doesn't. And I guess this is where the C run time has
flaws because it can go bezerk and write 2 megs worth of data in an 80
byte buffer.

Consider a customer name record field that starts out at 30 bytes, but
later in the project, it is increased to 40 bytes. By that time, you
may have written code that copies the name to temporary buffers, and at
this point, when you increase the field size, you need to do due
diligence and check to see that any temporary buffers to which you copy
the name are also increased.

Languages such as COBOL would automaically pad or truncate fields during
a MOVE operation to ensure no data overrun (and may issue compiler
warnings, but C's lack of a formal string type prevents it from issuing
compiler warnings (although it does when you move a long to a short etc).

Don't be so sure of that. While I am sure COBOL2006 (or whatever they
are using today) does this the COBOL compilers that were contemporaries
of the time when C was being developed did not do range checking and
overwriting one working storage entry while referencing another was
trivial. I actually used to demonstrate it in two ways when I taught
COBOL. One was using array out of bounds examples and one was by doing
arithmetic on the values contained in an alpha field. COBOL was no
saint. I even know someone who made considerable use of these "capa-
bilities" in order to embed non-printing characters into declared strings
in order to create a terminal handling routine back before we had DISPLAY
AT verbs.


So it takes more experienmce and more self discipline to program in C
properly. Problem is when you unleash young windows weenies and they
start to write C code, they don't see the problems and they don't have
enough experience and self discipline to write armoured code.

I have heard people here advocate doing things that are very bad examples
of programming practice, too. In any case, it is not the languages fault
no matter what. The responsibility falls on the shoulders of management
or the programmer. Choose the right tool for the job and know how to
use that tool properly. if you are trying to turn out hex allen screw
with a phillips screwdriver, don't blame either of them when the head
gets all chewed up.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@xxxxxxxxxxxxxxx | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
.

Relevant Pages

  • Re: Using Cobol when writing CGIs for the OSU web server.
    ... does one need C-stubs? ... I had COBOL main program call up some C routines. ... The main bone of contention are strings. ... a descriptop which points to the buffer). ...
    (comp.os.vms)
  • Re: [Lit.] Buffer overruns
    ... >> As has been pointed out, C strings are unrelated to C buffer overflow ... > is a infrastructure source length available based on nul-terminated, ... > data-pattern based length paradigm ... ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... > As has been pointed out, C strings are unrelated to C buffer overflow ... is a infrastructure source length available based on nul-terminated, ... data-pattern based length paradigm ... ...
    (sci.crypt)
  • Re: String concatenation function, request for comments.
    ... usefulness, efficiency, and most importantly the correctness of this small piece of code. ... as the responsibility of freeing the memory would be left to the client. ... If the resultant buffer is needed beyond the second call to the function, it can be copied to another buffer at the clients digression. ... If the strings specified for concatenation exceed the buffer available, ...
    (comp.lang.c)
  • Re: String concatenation function, request for comments.
    ... >> left to the client. ... If the resultant buffer is needed beyond the second ... >> If the strings specified for concatenation exceed the buffer available, ... > This demonstrates a fragility of the interface. ...
    (comp.lang.c)
Loading