groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use `strsave()`, not `strdup()`.


From: Ralph Corderoy
Subject: Re: Use `strsave()`, not `strdup()`.
Date: Tue, 09 Nov 2021 14:56:27 +0000

Hi Branden,

> Stroustrup bangs the exception drum pretty hard in Chapter 14 of the
> special edition of _The C++ Programming Language_

Groff's source was a light-touch use of C++, more C with Classes, AIUI,
but even so it was enough to deter contributors who knew to avoid the
language and the slippery slope it was keen to ski.  It would be nice if
it didn't adopt lots of extra C++ style.  :-)

> I'll venture that K&R erred when they taught the whole world their
> Hello, World program.  It should have called `puts()` instead.  Having
> promoted the language in fulsome terms for its smallness and
> terseness, they advised every novice to the language to reach for an
> unnecessarily big tool on their first day.

This was deliberate so readers could soon be introduced to formatted
output as the next program, the Fahrenheit-Celsius table.  There's
little point introducing puts() and then immediately confusing the
reader by switching to another function for printing.  What's its name
again?  Which one do I use when?  Why are there two?  You mean puts()
prints a newline but printf() doesn't?

> Ralph pointed out that *puts() implementors might pointlessly allocate
> memory, too,

No, I pointed out it might allocate memory; it's you who is claiming
it's pointless.

> and that's fair, up to a point--if you have anything less than
> complete trust in a library, you'll have to do things yourself.

It's nothing to do with trust in a library.  You expect the library to
implement the standard behaviour which does not guarantee memory
allocation will not occur.

> But in my opinion *puts() has no _excuse_ to ever allocate memory
> except from the stack.

It doesn't need an excuse.  It's clear simple behaviour.  The first
write to a FILE could spot the pointer to the buffer is NULL and
allocate it.

> > All that matters is "Cannot allocate memory".
>
> I reiterate that for an input processor like groff, knowing where you
> were in the input when things went pear-shaped _can_ be helpful.

As I said in another email, knowing how much was requested is helpful
because it's quite unusual to run out of memory these days so it's often
an unreasonable size due to corruption of the bits holding its value.

-- 
Cheers, Ralph.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]