strdup

[Richard Bos]

Yes, you (not some other function) call fopen() and then fclose(). Who
allocates also de-allocates. That's the simple 'design pattern'.

Wrong, wrong, and wrong. Often, one function opens a file, another
function processes each line in it, and a third function closes it.
Ditto for memory.

Richard

 

[Richard Tobin]

But fopen() requires a matching fclose().

[/QUOTE]

Yes, you (not some other function) call fopen() and then fclose().

But fopen() may well call malloc(), and fclose() call free(). Would your
objection to strdup() go away if there was a corresponding function
strfree() to free the strings allocated by strdup()?

Who
allocates also de-allocates. That's the simple 'design pattern'.

Whoever calls strdup() can also call free(). Why doesn't that match
your pattern?

-- Richard

 

[Thomas Dickey]

Yes, C is often called a portable assembler -- but it isn't.

at the time the comment was originally made in the early 80's (and from
online information - before you learned C), it was true: no type-checking,
crude optimization, etc.

Since it was a "cute" statement, it was picked up by especially by students,
and propagated around.

Still not crisp type-checking, but it's grown up some.

 

[Richard Tobin]

at the time the comment was originally made in the early 80's (and from
online information - before you learned C), it was true: no type-checking,
crude optimization, etc.

C compilers *did* have some type checking in the early 80s, and most
programmers used lint to check function types across files.

A more accurate statement - and one that is still true - is that C can
be used as a portable assembler.

-- Richard

 

[Thomas Dickey]

C compilers *did* have some type checking in the early 80s, and most
programmers used lint to check function types across files.

"some". For practical purposes it could be ignored (one could go on at
length) - which leads us to lint.

I use/used lint, but that practice was very rare - I don't recall
working on _any_ program where a previous developer had used lint.

On the other hand, I did work with developers who actively worked
to make using lint harder (by removing lint-rules from makefiles,
removing the ARGSUSED comments and #ifdef lint artifacts).

Even for more of those who claimed to run lint,
this was an occasional activity,
rather than a regular part of the process.

A more accurate statement - and one that is still true - is that C can
be used as a portable assembler.

sure - I haven't used assembler much since starting to work with C.
However, the type of assembler code that I was working with then -
that would require system-dependent extensions which lie outside the scope
of this group...

 

[Christopher Benson-Manica]

Also _because_ it is so easy to write yourself.

Too bad you're not allowed to call it "strdup" if you #include
<string.h>

 

[Richard Bos]

Too bad you're not allowed to call it "strdup" if you #include
<string.h>

*Shrug* Call it str_dup() and #define strdup str_dup, then. That's
legal.

Richard

 

[Christopher Benson-Manica]

Yes, you (not some other function) call fopen() and then fclose(). Who
allocates also de-allocates. That's the simple 'design pattern'.

Where does tmpfile() fit in this design pattern? tmpfile() presumably
invokes fopen() as part of its task, but you are still responsibile for
invoking fclose() on the stream it returns (if you want the associated
file to be removed whether or not the program terminates abnormally).

 

[P.J. Plauger]

The story I heard is that there was a bias against 'hidden'
mallocs, which could lead to memory leaks. I don't subscribe to
that particular bias.

I really don't recall any discussion about strdup, possibly
because it wasn't invented -- or not widely used -- in the
early/mid 1980s when we were filtering the Unix (now Posix)
functions for machine/system independent candidates for the
Standard C library. My company Whitesmiths had a similar
function, but we didn't put it forth for standardization
either.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Roland Pibinger]

But fopen() may well call malloc(), and fclose() call free().

You program to an interface, not an implementation. What functions
fopen(), fclose() call internally is not relevant for you as user.

Would your
objection to strdup() go away if there was a corresponding function
strfree() to free the strings allocated by strdup()?

Why not just use strcpy?

Best regards,
Roland Pibinger

 

[Richard Tobin]

But fopen() may well call malloc(), and fclose() call free().

[/QUOTE]

You program to an interface, not an implementation. What functions
fopen(), fclose() call internally is not relevant for you as user.

Likewise it is irrelevant that strdup() calls malloc() - strdup() and
free() are matching allocation and freeing functions.

Why not just use strcpy?

I'm trying to understand your design pattern, not argue about whether
strdup() in particular is a useful function.

-- Richard

 

[Roland Pibinger]

Where does tmpfile() fit in this design pattern? tmpfile() presumably
invokes fopen()

nobody knows, nobody needs to know.

as part of its task, but you are still responsibile for
invoking fclose() on the stream it returns (if you want the associated
file to be removed whether or not the program terminates abnormally).

The temp file will automatically be removed when the program
terminates normally. You neither have to call fopen() nor fclose(). It
may even be UB if you call fclose().

Best regards,
Roland Pibinger

 

[Richard Tobin]

as part of its task, but you are still responsibile for
invoking fclose() on the stream it returns (if you want the associated
file to be removed whether or not the program terminates abnormally).

[/QUOTE]

The temp file will automatically be removed when the program
terminates normally. You neither have to call fopen() nor fclose(). It
may even be UB if you call fclose().

What? C89 says: "The tmpfile function creates a temporary binary file
that will automatically be removed when it is closed or at program
termination".

-- Richard

 

[Christopher Benson-Manica]

The temp file will automatically be removed when the program
terminates normally.

Or when it is closed (7.19.4.3 n869). If the program may terminate
abnormally, however, you can either crack open the implementation's
documentation to determine whether the associated temporary file will
be removed if you've left the stream open, or you can fclose() the
stream yourself and not worry about the implementation. Additionally,
closing files opened by tmpfile() may be required if the program starts
bumping against FOPEN_MAX. The point is that invoking fclose() on the
stream returned by tmpfile() is a perfectly reasonable thing to do,
and I'm not convinced it fits the *alloc()/free() paradigm.

 

[Keith Thompson]

The temp file will automatically be removed when the program
terminates normally. You neither have to call fopen() nor fclose(). It
may even be UB if you call fclose().

I don't think it's UB. The description of the fclose() function
doesn't even mention fopen(); there's no requirement that the argument
to fclose() must be a FILE* previously returned by fopen().

 

[lawrence.jones]

I really don't recall any discussion about strdup, possibly
because it wasn't invented -- or not widely used -- in the
early/mid 1980s when we were filtering the Unix (now Posix)
functions for machine/system independent candidates for the
Standard C library. My company Whitesmiths had a similar
function, but we didn't put it forth for standardization
either.

It's in the SVID, so I'm pretty sure it was invented by then, but I too
don't recall any discussion of it. I proposed adding it for C99, but it
was shot down. According to the minutes, "The major issue was the
desirability of adding a function to the standard library which
allocates heap memory automatically for the user."

-Larry Jones

There's a connection here, I just know it. -- Calvin

 

[Malcolm McLean]

Only by people who know neither C nor assembly very well.

But there's another qualification for knowing whether C is a "portable
assembly" or not.

 

[CBFalconer]

*Shrug* Call it str_dup() and #define strdup str_dup, then.
That's legal.

No it isn't.

 

[CBFalconer]

Wrong, wrong, and wrong. Often, one function opens a file,
another function processes each line in it, and a third
function closes it. Ditto for memory.

No, you simply complicate the technique by using something like:

init(stuff);
run(whatever);
cleanup(stuff);

and run(whatever) may very well build up lists, trees, etc. based
on a root initialized by init, so that cleanup knows how to unload
the whole schmeer. You can of course combine this with the more
local technique.

 

[CBFalconer]

You program to an interface, not an implementation. What functions
fopen(), fclose() call internally is not relevant for you as user.


Why not just use strcpy?

Because that requires preallocation of the destination. If you
want you can always:

#define str_free(s) free(s)