vallor <[email protected]> writes:
[...]
Meanwhile, saw someone in another group write:
char * something;
something = strdup("writable string etc.");
if( something == NULL ) { etc. }
But that won't work if --std=c99, does work for g99 and c2x.
The (Linux) man page says:
/* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
I asked Google about it being a POSIX extension
added at that late date, and it gave me an answer
about the C standard:
"C9X London meeting update" https://groups.google.com/g/comp.std.c/c/pMaEU_8Rb7w
_ _ _ _ _
2. strsep and strdup are not being added. strsep() is out because
not enough people wanted it to vote it in; strdup() lost on the
grounds that it would be the *ONLY* function other than *alloc()
in the entire library whose return could be sanely passed to free(),
and this is surprising.
_ _ _ _ _
Also:
<https://stackoverflow.com/questions/32944390/what-is-the-rationale- for-not-including-strdup-in-the-c-standard>
Anyway, pointed out that they can just use an initializer, something
about which I was clued in by a friendly person in this very group.
strdup() and strndup() are being added to the C23 standard.
I asked Google about it [strdup] being a POSIX extension
added at that late date, and it gave me an answer
about the C standard:
"C9X London meeting update" https://groups.google.com/g/comp.std.c/c/pMaEU_8Rb7w
What strdup() can do better, for any chosen value of better, than strlen()+malloc()+memcpy() ?
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <[email protected]> wrote:
strdup() and strndup() are being added to the C23 standard.
What is justification?
What strdup() can do better, for any chosen value of better, than strlen()+malloc()+memcpy() ?
On 2024-03-10, Michael S <[email protected]> wrote:
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <[email protected]> wrote:
strdup() and strndup() are being added to the C23 standard.
What is justification?
strdup is required by POSIX already and thus widely implemented.
Many programmers who are not into standards already assume it's in C.
For decades, portable programs have been doing things like this:
#if HAVE_STRDUP
#define xstrdup(s) strdup(s)
#else
char *xstrdup(const char *); // own definition
#endif
What strdup() can do better, for any chosen value of better, than
strlen()+malloc()+memcpy() ?
Not take up space in every application for a common library routine.
Kaz Kylheku <[email protected]> writes:
On 2024-03-10, Michael S <[email protected]> wrote:
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <[email protected]> wrote:
strdup() and strndup() are being added to the C23 standard.
What is justification?
strdup is required by POSIX already and thus widely implemented.
Many programmers who are not into standards already assume it's in C.
For decades, portable programs have been doing things like this:
#if HAVE_STRDUP
#define xstrdup(s) strdup(s)
#else
char *xstrdup(const char *); // own definition
#endif
What strdup() can do better, for any chosen value of better, than
strlen()+malloc()+memcpy() ?
Not take up space in every application for a common library routine.
It's a form of lazy programming. I've seen a lot of open source
code that uses strdup without checking for failure and frequently "forgetting" to free the result.
On 10/03/2024 18:47, Scott Lurndal wrote:
Kaz Kylheku <[email protected]> writes:
On 2024-03-10, Michael S <[email protected]> wrote:
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <[email protected]> wrote:
strdup() and strndup() are being added to the C23 standard.
What is justification?
strdup is required by POSIX already and thus widely implemented.
Many programmers who are not into standards already assume it's in
C.
For decades, portable programs have been doing things like this:
#if HAVE_STRDUP
#define xstrdup(s) strdup(s)
#else
char *xstrdup(const char *); // own definition
#endif
What strdup() can do better, for any chosen value of better, than
strlen()+malloc()+memcpy() ?
Not take up space in every application for a common library
routine.
It's a form of lazy programming. I've seen a lot of open source
code that uses strdup without checking for failure and frequently "forgetting" to free the result.
And it is probably more likely that machine with many gigabytes of
RAM will develop an electrical fault than that that call for a short
string will be the point where it runs out of memory.
On 10/03/2024 18:47, Scott Lurndal wrote:
Kaz Kylheku <[email protected]> writes:
On 2024-03-10, Michael S <[email protected]> wrote:
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <[email protected]> wrote:
strdup() and strndup() are being added to the C23 standard.
What is justification?
strdup is required by POSIX already and thus widely implemented.
Many programmers who are not into standards already assume it's in C.
For decades, portable programs have been doing things like this:
#if HAVE_STRDUP
#define xstrdup(s) strdup(s)
#else
char *xstrdup(const char *); // own definition
#endif
What strdup() can do better, for any chosen value of better, than
strlen()+malloc()+memcpy() ?
Not take up space in every application for a common library routine.
It's a form of lazy programming. I've seen a lot of open source
code that uses strdup without checking for failure and frequently
"forgetting" to free the result.
And it is probably more likely that machine with many gigabytes of RAM
will develop an electrical fault than that that call for a short string
will be the point where it runs out of memory.
On Mon, 11 Mar 2024 16:23:32 +0000
Malcolm McLean <[email protected]> wrote:
On 10/03/2024 18:47, Scott Lurndal wrote:
Kaz Kylheku <[email protected]> writes:
On 2024-03-10, Michael S <[email protected]> wrote:
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <[email protected]> wrote:
strdup() and strndup() are being added to the C23 standard.
What is justification?
strdup is required by POSIX already and thus widely implemented.
Many programmers who are not into standards already assume it's in
C.
For decades, portable programs have been doing things like this:
#if HAVE_STRDUP
#define xstrdup(s) strdup(s)
#else
char *xstrdup(const char *); // own definition
#endif
What strdup() can do better, for any chosen value of better, than
strlen()+malloc()+memcpy() ?
Not take up space in every application for a common library
routine.
It's a form of lazy programming. I've seen a lot of open source
code that uses strdup without checking for failure and frequently
"forgetting" to free the result.
And it is probably more likely that machine with many gigabytes of
RAM will develop an electrical fault than that that call for a short
string will be the point where it runs out of memory.
Is there any chance at all that on typical Linux machine (i.e. the one >configured to overcommit virtual memory) strdup() returns NULL?
If it was malloc() I'd say - no chance. For strdup() I'm less sure.
Malcolm McLean <[email protected]> writes:
On 10/03/2024 18:47, Scott Lurndal wrote:
Kaz Kylheku <[email protected]> writes:
Not take up space in every application for a common library routine.
It's a form of lazy programming. I've seen a lot of open source
code that uses strdup without checking for failure and frequently
"forgetting" to free the result.
And it is probably more likely that machine with many gigabytes of RAM
Actually, your assumptions that:
1) strdup is the only allocation function used by an application
2) all strings are "short"
Michael S <[email protected]> writes:
On Mon, 11 Mar 2024 16:23:32 +0000
Malcolm McLean <[email protected]> wrote:
On 10/03/2024 18:47, Scott Lurndal wrote:
Kaz Kylheku <[email protected]> writes:
On 2024-03-10, Michael S <[email protected]> wrote:
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <[email protected]> wrote:
strdup() and strndup() are being added to the C23 standard.
What is justification?
strdup is required by POSIX already and thus widely implemented.
Many programmers who are not into standards already assume it's
in C.
For decades, portable programs have been doing things like this:
#if HAVE_STRDUP
#define xstrdup(s) strdup(s)
#else
char *xstrdup(const char *); // own definition
#endif
What strdup() can do better, for any chosen value of better,
than strlen()+malloc()+memcpy() ?
Not take up space in every application for a common library
routine.
It's a form of lazy programming. I've seen a lot of open source
code that uses strdup without checking for failure and frequently
"forgetting" to free the result.
And it is probably more likely that machine with many gigabytes of
RAM will develop an electrical fault than that that call for a
short string will be the point where it runs out of memory.
Is there any chance at all that on typical Linux machine (i.e. the
one configured to overcommit virtual memory) strdup() returns NULL?
If it was malloc() I'd say - no chance. For strdup() I'm less sure.
An unanswerable question. But, consider that not all allocations
in an application use strdup as the only memory allocator (the
majority don't, and other allocations may be much larger), yet both
use the same pool of address space and host memory.
Consider also that on unix and linux, there are a number of resource
limits intended to prevent a single application from consuming all of
memory, which a call to strdup may encounter even with plenty of RAM available.
Toy applications may not have an issue with strdup. Real
applications on the other hand might, and an unexpected SIGSEGV is
extremely user-unfriendly and could have catastrophic results.
And on the gripping hand, not testing for a potential catastrophic
failure condition, no matter how unlikely isn't the sign of a good programmer.
Michael S <[email protected]> writes:
[...]
Is there any chance at all that on typical Linux machine (i.e. the one
configured to overcommit virtual memory) strdup() returns NULL?
If it was malloc() I'd say - no chance. For strdup() I'm less sure.
strdup() calls malloc(), so strdup() can return NULL if and only if
malloc() can return NULL -- but with the additional constraint that you
first need to have a string argument to strdup() that's long enough to
cause a suffiently large argument to be passed to malloc().
One data point: On my Ubuntu system, malloc(SIZE_MAX) returns NULL for
very large arguments (over about 23 GiB in my quick and dirty test).
Michael S <[email protected]> writes:
[...]
Is there any chance at all that on typical Linux machine (i.e. the one
configured to overcommit virtual memory) strdup() returns NULL?
If it was malloc() I'd say - no chance. For strdup() I'm less sure.
strdup() calls malloc(), so strdup() can return NULL if and only if
malloc() can return NULL -- but with the additional constraint that you
first need to have a string argument to strdup() that's long enough to
cause a suffiently large argument to be passed to malloc().
One data point: On my Ubuntu system, malloc(SIZE_MAX) returns NULL for
very large arguments (over about 23 GiB in my quick and dirty test).
On Mon, 11 Mar 2024 17:05:40 GMT
[email protected] (Scott Lurndal) wrote:
Michael S <[email protected]> writes:
On Mon, 11 Mar 2024 16:23:32 +0000
Malcolm McLean <[email protected]> wrote:
On 10/03/2024 18:47, Scott Lurndal wrote:
Kaz Kylheku <[email protected]> writes:
On 2024-03-10, Michael S <[email protected]> wrote:
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <[email protected]> wrote:
strdup() and strndup() are being added to the C23 standard.
What is justification?
strdup is required by POSIX already and thus widely implemented.
Many programmers who are not into standards already assume it's
in C.
For decades, portable programs have been doing things like this:
#if HAVE_STRDUP
#define xstrdup(s) strdup(s)
#else
char *xstrdup(const char *); // own definition
#endif
What strdup() can do better, for any chosen value of better,
than strlen()+malloc()+memcpy() ?
Not take up space in every application for a common library
routine.
It's a form of lazy programming. I've seen a lot of open source
code that uses strdup without checking for failure and frequently
"forgetting" to free the result.
And it is probably more likely that machine with many gigabytes of
RAM will develop an electrical fault than that that call for a
short string will be the point where it runs out of memory.
Is there any chance at all that on typical Linux machine (i.e. the
one configured to overcommit virtual memory) strdup() returns NULL?
If it was malloc() I'd say - no chance. For strdup() I'm less sure.
An unanswerable question. But, consider that not all allocations
in an application use strdup as the only memory allocator (the
majority don't, and other allocations may be much larger), yet both
use the same pool of address space and host memory.
Consider also that on unix and linux, there are a number of resource
limits intended to prevent a single application from consuming all of
memory, which a call to strdup may encounter even with plenty of RAM
available.
Toy applications may not have an issue with strdup. Real
applications on the other hand might, and an unexpected SIGSEGV is
extremely user-unfriendly and could have catastrophic results.
According to my understanding, on Linux with overcommit enabled,
typical behavior would be that allocation (of non-extravagant size,
say, no more than 100 MB) always succeeds. OOM is called later, on
access. It seems, that most commonly OOM does not hit application that
is allocating right now. Much more likely that it will kill app that
user opened hours ago, then put aside and then tried to use again.
And on the gripping hand, not testing for a potential catastrophic
failure condition, no matter how unlikely isn't the sign of a good
programmer.
Some people would say that writing code (a handler for allocation
returning NULL) that either can't be tested in principle or can be
tested only in principle, but most certainly not tested in
practice, isn't a sign of a good programmer.
Myself, I still tend to code this checks, but
(1) my main targets are not Linux with overcommit, so the
chance of allocation returning NULL could be estimated like "not going
to happen" rather than "can't happen".
(2) I am old full that like his unreasonable old habits
At least, I stopped checking return value of fclose() after being told,
with facts, how stupid it is. So, may be, one day I'd convince myself to
stop checking return value of malloc() as well.
On 2024-03-11, Scott Lurndal <[email protected]> wrote:
Malcolm McLean <[email protected]> writes:
On 10/03/2024 18:47, Scott Lurndal wrote:
Kaz Kylheku <[email protected]> writes:
Not take up space in every application for a common library routine.
It's a form of lazy programming. I've seen a lot of open source
code that uses strdup without checking for failure and frequently
"forgetting" to free the result.
And it is probably more likely that machine with many gigabytes of RAM
Actually, your assumptions that:
1) strdup is the only allocation function used by an application
2) all strings are "short"
Even if a string is long enough to need its own mmap request,
that will still return valid memory that later fails to commit.
Under overcommit conditions, you will only reliably get null return out
of a large strdup if you've exhausted your local address space
(of which you have lots under 64 bits).
An application that cares will fsync(2) the file descriptor before
closing it with close(2) and will check the fsync return value and
take appropriate action if it fails.
While I personally eschew fopen/fclose and their ilk due to
performance overhead generally, were I to use it for data which
is required to be valid, I'd always check the results of fflush
before closing with fclose().
It really depends on the application and the importance of the
data (ephemeral data, e.g. terminal output from ps(1), may not
require the same level of scrutiny as a database, for example).
Scott Lurndal <[email protected]> wrote:
Malcolm McLean <[email protected]> writes:
On 10/03/2024 18:47, Scott Lurndal wrote:
Kaz Kylheku <[email protected]> writes:
Not take up space in every application for a common library routine.
It's a form of lazy programming. I've seen a lot of open source
code that uses strdup without checking for failure and frequently
"forgetting" to free the result.
And it is probably more likely that machine with many gigabytes of RAM
Actually, your assumptions that:
1) strdup is the only allocation function used by an application
2) all strings are "short"
Even if a string is long enough to need its own mmap request,
that will still return valid memory that later fails to commit.
Malcolm McLean <[email protected]> writes:
On 11/03/2024 17:00, Scott Lurndal wrote:
Malcolm McLean <[email protected]> writes:The bank has many billions. But there is a banking crisis on and it is
On 10/03/2024 18:47, Scott Lurndal wrote:Actually, your assumptions that:
Kaz Kylheku <[email protected]> writes:
On 2024-03-10, Michael S <[email protected]> wrote:It's a form of lazy programming. I've seen a lot of open source
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <[email protected]> wrote:
strdup() and strndup() are being added to the C23 standard.
What is justification?
strdup is required by POSIX already and thus widely implemented.
Many programmers who are not into standards already assume it's in C. >>>>>>
For decades, portable programs have been doing things like this:
#if HAVE_STRDUP
#define xstrdup(s) strdup(s)
#else
char *xstrdup(const char *); // own definition
#endif
What strdup() can do better, for any chosen value of better, than >>>>>>> strlen()+malloc()+memcpy() ?
Not take up space in every application for a common library routine. >>>>>
code that uses strdup without checking for failure and frequently
"forgetting" to free the result.
And it is probably more likely that machine with many gigabytes of RAM
1) strdup is the only allocation function used by an application
2) all strings are "short"
are both flawed.
about to fail. And someone, somewhere, will be that man who tries to
withdraw some money and is told "no". But how likely is that man to be
you with your 20 pounds at the cashpoint? How likely is it to be
another bank making a cash call for a 100 million or so?
If I withdraw 20 pounds from my bank, I'll bet you that 20 pounds that
the bank still checks whether it has the money.
On 12/03/2024 15:55, Scott Lurndal wrote:
Keith Thompson <[email protected]> writes:So 2,294 Americans in 1932 had the experience "you want to withdraw
Malcolm McLean <[email protected]> writes:
On 11/03/2024 17:00, Scott Lurndal wrote:
Malcolm McLean <[email protected]> writes:The bank has many billions. But there is a banking crisis on and it is >>>> about to fail. And someone, somewhere, will be that man who tries to
On 10/03/2024 18:47, Scott Lurndal wrote:1) strdup is the only allocation function used by an application >>>>> 2) all strings are "short"
Kaz Kylheku <[email protected]> writes:
On 2024-03-10, Michael S <[email protected]> wrote:It's a form of lazy programming. I've seen a lot of open source >>>>>>> code that uses strdup without checking for failure and frequently >>>>>>> "forgetting" to free the result.
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <[email protected]> wrote:
strdup() and strndup() are being added to the C23 standard. >>>>>>>>>>
What is justification?
strdup is required by POSIX already and thus widely implemented. >>>>>>>> Many programmers who are not into standards already assume it's in C. >>>>>>>>
For decades, portable programs have been doing things like this: >>>>>>>>
#if HAVE_STRDUP
#define xstrdup(s) strdup(s)
#else
char *xstrdup(const char *); // own definition
#endif
What strdup() can do better, for any chosen value of better, than >>>>>>>>> strlen()+malloc()+memcpy() ?
Not take up space in every application for a common library routine. >>>>>>>
And it is probably more likely that machine with many gigabytes of RAM >>>>> Actually, your assumptions that:
are both flawed.
withdraw some money and is told "no". But how likely is that man to be >>>> you with your 20 pounds at the cashpoint? How likely is it to be
another bank making a cash call for a 100 million or so?
If I withdraw 20 pounds from my bank, I'll bet you that 20 pounds that
the bank still checks whether it has the money.
And as for "how likely it is that the bank will not be able
to honor withdrawal requests", I refer Malcolm to 1931.
"In 1930, 1,352 banks held more than $853 million in
deposits; in 1931, one year later, 2,294 banks failed
with nearly $1.7 billion in deposits."
cash? OK, here we go, oh sorry, that just took us over the edge and the
bank is now closed". Everyone else, either "here's your money", or
"sorry, the bank has now closed, no more withdrawal requests".
Malcolm McLean <[email protected]> writes:...
So 2,294 Americans in 1932 had the experience "you want to withdraw
cash? OK, here we go, oh sorry, that just took us over the edge and the
bank is now closed". Everyone else, either "here's your money", or
"sorry, the bank has now closed, no more withdrawal requests".
I'm pretty sure the quote above from Wikipedia is written in
a form of English that even the English understand, so I don't see
how you came up with the idea that only 2,294 Americans were
affected when 2,294 banks failed.
Nor to I see the relevence to checking the return value
of strdup(3).
On 3/12/24 19:50, Scott Lurndal wrote:
Malcolm McLean <[email protected]> writes:...
So 2,294 Americans in 1932 had the experience "you want to withdraw
cash? OK, here we go, oh sorry, that just took us over the edge and the
bank is now closed". Everyone else, either "here's your money", or
"sorry, the bank has now closed, no more withdrawal requests".
I'm pretty sure the quote above from Wikipedia is written in
a form of English that even the English understand, so I don't see
how you came up with the idea that only 2,294 Americans were
affected when 2,294 banks failed.
Every bank fails at some particular time, when it runs out of money.
There is always one particular claim on that bank's resources that
caused it to run out and for some reason he's focusing on those claims.
Other Americans also had problems due to the bank having already failed,
but at most 2294 Americans made claims that actually triggered that
failure. I haven't a clue as to why he considers that fact important,
but he has correctly made that distinction.
Actually, it may be that in some cases a bank closed immediately as soon
as a successful withdrawal request left it with too little funds, so the number might actually be less that 2294.
Nor to I see the relevence to checking the return value
of strdup(3).
Agreed.
I've seen a lot of open source code
that uses strdup without checking for failure and frequently
"forgetting" to free the result.
I was looking at the systemd source code the other day, and came across a
lot of this sort of thing:
_cleanup_free_ char *link = NULL;
Now, what do you suppose “_cleanup_free_” does?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 151:06:14 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,604 |