strdup

[klaushuotari]

Sorry to bother you, but I just have to.

What about strdup()? It wasn't in standard C run-time library, yet
many apps use it liberally as it was in there.

I don't know if that particular function is included in C99. Not too
difficult to code own version of it, but why it wasn't included in
library in the first place? Is there some rationale behind it? There
are peculiar and dangerous functions like strtok(), so why not
strdup() which seems to be very useful function?

What might be the reasons to exclude something that useful from
library? And why C++ has the keyword "asm", but C doesn't? I don't
understand.

 

[Richard Heathfield]

(e-mail address removed) said:

Sorry to bother you, but I just have to.

What about strdup()? It wasn't in standard C run-time library, yet
many apps use it liberally as it was in there.

I don't know if that particular function is included in C99. Not too
difficult to code own version of it, but why it wasn't included in
library in the first place? Is there some rationale behind it?

My guess would be that the ISO guys couldn't agree whether to put it in

And why C++ has the keyword "asm", but C doesn't?

Because it's pointless, probably. Any embedded assembly language makes
your code non-portable anyway, so you might as well just use a compiler
extension for it.

 

[klaushuotari]

Richard Heathfield kirjoitti:

(e-mail address removed) said:


My guess would be that the ISO guys couldn't agree whether to put it in


Because it's pointless, probably. Any embedded assembly language makes
your code non-portable anyway, so you might as well just use a compiler
extension for it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Probably so. But considering that C gets often labeled as "portable
assembly" I would most definitely included possibility to drop to
assembly level when coding in C. I know it argues against the paradigm
of a portability, but nevertheless I would like the fact that the
possibility to asm was inherent in C. I don't know... I just wonder
that "asm" is a possibility in such a high-level lang such a C++, but
not in C which gets used more often when programming toaster owens.
Maybe it's good though. And anyways one could always call low-level
routines in libraries. Maybe that's good.

 

[Roland Pibinger]

What about strdup()? It wasn't in standard C run-time library, yet
many apps use it liberally as it was in there.

I don't know if that particular function is included in C99.

No, it isn't!

Not too
difficult to code own version of it, but why it wasn't included in
library in the first place? Is there some rationale behind it?

Because the C Standard library doesn't include any functions that
return allocated memory and oblige the user to call free. It's a
simple but effective 'design pattern'.

What might be the reasons to exclude something that useful from
library?

strdup() isn't "useful" for the mentioned reason.

Best regards,
Roland Pibinger

 

[Peter Nilsson]

Richard Heathfield kirjoitti:

Or an assembler!

Probably so. But considering that C gets often labeled as
"portable assembly"

A label that is taken too literally by many noobs. It's really
statement implying that C is very low on the high level language
ladder.

I would most definitely included possibility to drop to
assembly level when coding in C. I know it argues against the
paradigm of a portability,

There's a difference between the portability of C programs and
the portability of C. An asm keyword, and more importanty the
additional syntax, likely implementation defined, yields no
advantage for either.

but nevertheless I would like the fact that the
possibility to asm was inherent in C.

Assembly was never inherent to C! Indeed the whole point of
C was to _replace_ assembly. What typically happened was that
you wrote critical code in assembler and simply linked them
into your C code.

I don't know... I just wonder that "asm" is a possibility in
such a high-level lang such a C++,

I'm sure most C++ implementors wonder why "asm" was in C++
too. The majority of (rare) C or C++ code that uses assembly
tend to use alternative syntax anyway!

 

[Flash Gordon]

Roland Pibinger wrote, On 21/03/07 22:43:

No, it isn't!


Because the C Standard library doesn't include any functions that
return allocated memory and oblige the user to call free. It's a
simple but effective 'design pattern'.

What about malloc and realloc? You could call it stralloc if that would
make you happier.

strdup() isn't "useful" for the mentioned reason.

There are times when it is incredibly useful. However, I'm not that
bothered because I'm using wrapper functions for all allocation routines
anyway, so implementing strdup (as ffstrdup) is no big deal to me.

 

[Richard Tobin]

Not too
difficult to code own version of it, but why it wasn't included in
library in the first place? Is there some rationale behind it?

[/QUOTE]

Because the C Standard library doesn't include any functions that
return allocated memory and oblige the user to call free.

Can you point me to some reference showing that that was the reason?

-- Richard

 

[Malcolm McLean]

Because the C Standard library doesn't include any functions that
return allocated memory and oblige the user to call free. It's a
simple but effective 'design pattern'.

But fopen() requires a matching fclose().

 

[Old Wolf]

Because the C Standard library doesn't include any functions that
return allocated memory and oblige the user to call free.

Actually, it includes three such functions.

 

[Keith Thompson]

Richard Heathfield kirjoitti:

(e-mail address removed) said: [...]

And why C++ has the keyword "asm", but C doesn't?

Because it's pointless, probably. Any embedded assembly language makes
your code non-portable anyway, so you might as well just use a compiler
extension for it.

Probably so. But considering that C gets often labeled as "portable
assembly" I would most definitely included possibility to drop to
assembly level when coding in C. I know it argues against the paradigm
of a portability, but nevertheless I would like the fact that the
possibility to asm was inherent in C. I don't know... I just wonder
that "asm" is a possibility in such a high-level lang such a C++, but
not in C which gets used more often when programming toaster owens.
Maybe it's good though. And anyways one could always call low-level
routines in libraries. Maybe that's good.

Please don't quote signatures.

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

Compiler implementers are perfectly free to provide inline assembly as
an extension. It just doesn't matter whether the standard reserves an
"asm" keyword for this purpose. Probably C++ has it because it was
originally based on an earlier version of C; both editions of K&R
mention that some implementations reserve the words "asm" and
"fortran".

<OT>
C++ even defines a construct for inline assembly:

asm ( string-literal ) ;

But the contents of the string-literal, and the effect of the
construct, are entirely implementation-defined.
</OT>

Since there's no guarantee that any code using "asm" will be even
vaguely portable, what is the advantage of reserving a keyword, as
opposed to, say, using some identifier from the implementation
namespace like __ASM__, or using a "#pragma"?

 

[klaushuotari]

Richard Heathfield kirjoitti:

(e-mail address removed) said: [...]
And why C++ has the keyword "asm", but C doesn't?
Because it's pointless, probably. Any embedded assembly language makes
your code non-portable anyway, so you might as well just use a compiler
extension for it.

Probably so. But considering that C gets often labeled as "portable
assembly" I would most definitely included possibility to drop to
assembly level when coding in C. I know it argues against the paradigm
of a portability, but nevertheless I would like the fact that the
possibility to asm was inherent in C. I don't know... I just wonder
that "asm" is a possibility in such a high-level lang such a C++, but
not in C which gets used more often when programming toaster owens.
Maybe it's good though. And anyways one could always call low-level
routines in libraries. Maybe that's good.

Please don't quote signatures.

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

Compiler implementers are perfectly free to provide inline assembly as
an extension. It just doesn't matter whether the standard reserves an
"asm" keyword for this purpose. Probably C++ has it because it was
originally based on an earlier version of C; both editions of K&R
mention that some implementations reserve the words "asm" and
"fortran".

<OT>
C++ even defines a construct for inline assembly:

asm ( string-literal ) ;

But the contents of the string-literal, and the effect of the
construct, are entirely implementation-defined.
</OT>

Since there's no guarantee that any code using "asm" will be even
vaguely portable, what is the advantage of reserving a keyword, as
opposed to, say, using some identifier from the implementation
namespace like __ASM__, or using a "#pragma"?

--
Keith Thompson (The_Other_Keith) (e-mail address removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Good points there. What is the importance of portability? Not every
platform will be the same. Some new platforms will demand new
operators, new shift in thinking. Future computing power will demand
whole new approach to programming. Soon we will have parallel
computing coupled with neural networks or something like that (I'm no
expert). What is the position of C? How to efficiently model real
world problems with some programming language? I don't know, but at
the moment I'm perfectly happy with C. It has passed the test of time.
1 + 1 = 3.

 

[Keith Thompson]

Please don't quote signatures. [...]
--
Keith Thompson (The_Other_Keith) (e-mail address removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

The stuff following the "-- " delimiter, which I've left in place
above, is called a "signature". When you post a followup, please
don't include the signature, or anything else not relevant to your
followup, in the quoted material. Quote just enough so that your
followup makes sense to someone who hasn't seen the parent article.

Good points there. What is the importance of portability? Not every
platform will be the same. Some new platforms will demand new
operators, new shift in thinking. Future computing power will demand
whole new approach to programming. Soon we will have parallel
computing coupled with neural networks or something like that (I'm no
expert). What is the position of C? How to efficiently model real
world problems with some programming language? I don't know, but at
the moment I'm perfectly happy with C. It has passed the test of time.
1 + 1 = 3.

Portability can be important, unimportant, or impossible, depending on
the application. Whether it's important or not, the "asm" keyword
doesn't achieve it.

 

[klaushuotari]

Portability can be important, unimportant, or impossible, depending on
the application. Whether it's important or not, the "asm" keyword
doesn't achieve it.

The more I think of that the more I believe that's true. So should
"asm" be a no-no when thinking about new keywords included in the
language C?

 

[CBFalconer]

(e-mail address removed) said:
.... snip ... .... snip ...

My guess would be that the ISO guys couldn't agree whether to put
it in <string.h> (because it's a string function) or <stdlib.h>
(because it's a function that allocates memory), so it died in
committee.

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.

 

[CBFalconer]

Richard Heathfield kirjoitti:
(e-mail address removed) said: [...]
And why C++ has the keyword "asm", but C doesn't?

Because it's pointless, probably. Any embedded assembly language makes
your code non-portable anyway, so you might as well just use a compiler
extension for it.

Probably so. But considering that C gets often labeled as "portable
assembly" I would most definitely included possibility to drop to
assembly level when coding in C. I know it argues against the paradigm
of a portability, but nevertheless I would like the fact that the
possibility to asm was inherent in C. I don't know... I just wonder
that "asm" is a possibility in such a high-level lang such a C++, but
not in C which gets used more often when programming toaster owens.
Maybe it's good though. And anyways one could always call low-level
routines in libraries. Maybe that's good.

Please don't quote signatures.

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

Compiler implementers are perfectly free to provide inline assembly as
an extension. It just doesn't matter whether the standard reserves an
"asm" keyword for this purpose. Probably C++ has it because it was
originally based on an earlier version of C; both editions of K&R
mention that some implementations reserve the words "asm" and
"fortran".

<OT>
C++ even defines a construct for inline assembly:

asm ( string-literal ) ;

But the contents of the string-literal, and the effect of the
construct, are entirely implementation-defined.
</OT>

Since there's no guarantee that any code using "asm" will be even
vaguely portable, what is the advantage of reserving a keyword, as
opposed to, say, using some identifier from the implementation
namespace like __ASM__, or using a "#pragma"?

--
Keith Thompson (The_Other_Keith) (e-mail address removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Good points there. What is the importance of portability? Not every
platform will be the same. Some new platforms will demand new
operators, new shift in thinking. Future computing power will demand
whole new approach to programming. Soon we will have parallel
computing coupled with neural networks or something like that (I'm no
expert). What is the position of C? How to efficiently model real
world problems with some programming language? I don't know, but at
the moment I'm perfectly happy with C. It has passed the test of time.
1 + 1 = 3.

I am quoting the whole schmeer to make a point. If you read Keiths
article, why did you continue to quote the sig? Why did you fail
to snip other irrelevant material?

 

[Keith Thompson]

The more I think of that the more I believe that's true. So should
"asm" be a no-no when thinking about new keywords included in the
language C?

Please don't snip attribution lines (lines of the form "So-and-so writes:").

In my opinion, yes, adding an "asm" keyword to C would be a bad idea.

 

[Richard Bos]

Richard Heathfield kirjoitti:

Also _because_ it is so easy to write yourself.

Probably so. But considering that C gets often labeled as "portable
assembly"

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

I would most definitely included possibility to drop to
assembly level when coding in C. I know it argues against the paradigm
of a portability, but nevertheless I would like the fact that the
possibility to asm was inherent in C.

How would you write a C interpreter if you had to allow for assembly?
(Come to think of it, how does a C++ interpreter handle this? Or are C++
interpreters not allowed?)

Richard

 

[Roland Pibinger]

Actually, it includes three such functions.

;-)

 

[Roland Pibinger]

Can you point me to some reference showing that that was the reason?

No, but try to find an example in K&R that forces the caller to 'free'
the returned object.

Best regards,
Roland Pibinger

 

[Roland Pibinger]

in message
But fopen() requires a matching fclose().

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

Best wishes,
Roland Pibinger