🚀 go-pugleaf

A.Main@dcs.warwick.ac.uk (Zefram):
> In any case, there's nothing wrong with using gets()
> in certain limited cases, even in production code.  

It would be nice to hear some examples.  For what it's worth, I don't
consider it sufficient to say that you write both the writer and the
reader: IMHO the program _must_ check the line length anyway (to avoid
the obvious and frequent bug where you or the poor user update only the
writer to use longer lines), and that can't be done with gets.

Personally, I see little justification to keep either gets or
scanf("%s") (without a length limit, that is) in the next revision of
the standard.

One thing I would like to see (if we're going to have a new standard
anyway, that is) is something that does what strncpy should have done.
I call mine strmaxcpy:

char *strmaxcpy(char *tgt, const char *src, size_t n) {
        assert(tgt != NULL);
        assert(src != NULL);
        assert(!memoverlap(tgt, n+1, src, strlen(src)+1));

        *tgt = '\0';
        strncat(tgt, src, n);

        return tgt;
}

(memoverlap is a function that tests whether two memory areas overlap.
My implementation -- part of Publib, of course -- is non-portable, as it
compares arbitrary pointer values.  A similar quick check should be doable
for any architecture, however.)

> In quick test programs and the like, it's very convenient and not a
> problem even if applied directly to text typed by humans.

Quick test programs sometimes live longer than intended, but otherwise
I almost agree.  The reason I don't agree is that I use my getaline
function (or xgetaline function) instead, which is good enough for
production code and handles lines of arbitrary length.  (These
functions are part of Publib, see my signature.)

However, even in quick test programs the extra effort of using fgets is
hardly important enough to keep gets.

-- 
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
Publib version 0.5: ftp://ftp.cs.helsinki.fi/pub/Software/Local/Publib/