Matthew Dillon wrote:
:Roland Mainz wrote:
: [The following falls under the category micro-optimisation but may IMO
: still be worth an investigation]
: After working on various parts of OpenSolaris I found that is common to
: use the following sequence to concatenate strings:
: -- snip --
[EMAIL PROTECTED] wrote:
James Carlson wrote:
[snip]
As for strMANYcat, the operation seems sort of obvious and somewhat
useful, but I wonder how often in real, well-written code this
situation actually comes up _and_ snprintf isn't a better answer.
Umpf. See my original posting. My
James Carlson wrote:
[snip]
As for strMANYcat, the operation seems sort of obvious and somewhat
useful, but I wonder how often in real, well-written code this
situation actually comes up _and_ snprintf isn't a better answer.
Umpf. See my original posting. My intention was to improve
[EMAIL PROTECTED] wrote:
See my comment to Casper Dik - this is IMO bad for at least two reasons:
- You have to handle the varargs overhead. The source code looks smaller
and cleaner but I am not sure whether the resulting binary will be
smaller
*What* varargs overhead?
Maybe not on
[EMAIL PROTECTED] wrote:
Why not a varargs: strMANYcat():
strMANYcat(s, foo, /, bar, NULL);
(In most cases, the function call overhead dominates the finding the
end of string because pushing stack frames modifies memory and
finding the end of a string likely to be in the L1
Roland Mainz writes:
James Carlson wrote:
[snip]
As for strMANYcat, the operation seems sort of obvious and somewhat
useful, but I wonder how often in real, well-written code this
situation actually comes up _and_ snprintf isn't a better answer.
Umpf. See my original posting. My
James Carlson wrote:
[snip]
As for strMANYcat, the operation seems sort of obvious and somewhat
useful, but I wonder how often in real, well-written code this
situation actually comes up _and_ snprintf isn't a better answer.
Umpf. See my original posting. My intention was to improve
Just asked around, one of the very old staff here suggested that the
reason was that early CPUs only had only very few register so having the
s1 in one of them as result of being the function's return value saved
some instructions. Weired (at least for todays standards).
While I thought of a
James Carlson [EMAIL PROTECTED] wrote:
Joerg Schilling writes:
I have a re-implementation in my libschily
[...]
* WARNING: a NULL constant is not a NULL pointer, so a caller must
* cast a NULL constant to a pointer: (char *)NULL
How's that?
This is a conclusion from the C
James Carlson [EMAIL PROTECTED] wrote:
Alan Coopersmith writes:
Also, as I noted on IRC, strlcat() is close to this, and much safer.
snprintf is simpler still and just as safe.
This does not work in case the call to strlcat() would be done from
within a loop.
Jörg
--
EMail:[EMAIL
Joerg Schilling writes:
How's that?
This is a conclusion from the C standard
I should have been more explicit. It seemed like a strange place for
a comment like this.
that:
strcatl(char *to, size_t tolen, ...)
but, then, that calls the return value into question. The
James Carlson [EMAIL PROTECTED] wrote:
This is a conclusion from the C standard
I should have been more explicit. It seemed like a strange place for
a comment like this.
If you did see the modifications done to my software by people from SuSE or
Debian, you would understand why I put
Why not a varargs: strMANYcat():
strMANYcat(s, foo, /, bar, NULL);
(In most cases, the function call overhead dominates the finding the
end of string because pushing stack frames modifies memory and
finding the end of a string likely to be in the L1 cache is *really*
cheap)
[EMAIL PROTECTED] writes:
- calling strMANYcat() is shorter (generated code wise) then
multiple calls to strcat()
- varargs is really cheap in the called function (and the cost
is all in a single location)
But the return value of strcat() is indeed useless.
Joerg Schilling writes:
I have a re-implementation in my libschily
[...]
*WARNING: a NULL constant is not a NULL pointer, so a caller must
*cast a NULL constant to a pointer: (char *)NULL
How's that?
strcatl(char *to, ...)
Sigh ... not safe from target overflow problems.
Roland Mainz wrote:
char *s;
...
strcat(s, foo);
strcat(s, /);
strcat(s, bar);
Also, as I noted on IRC, strlcat() is close to this, and much safer.
You could write the above as:
char *s;
int len; /* size of buffer s */
int used = 0;
used = strlcpy(s, foo, len);
if (used len)
used +=
Alan Coopersmith writes:
Also, as I noted on IRC, strlcat() is close to this, and much safer.
snprintf is simpler still and just as safe.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 /
[The following falls under the category micro-optimisation but may IMO
still be worth an investigation]
After working on various parts of OpenSolaris I found that is common to
use the following sequence to concatenate strings:
-- snip --
...
char *s;
...
strcat(s, foo);
strcat(s, /);
strcat(s,
[EMAIL PROTECTED] wrote:
Comments/suggestions/ideas welcome...
Why not a varargs: strMANYcat():
strMANYcat(s, foo, /, bar, NULL);
(In most cases, the function call overhead dominates the finding the
end of string because pushing stack frames modifies memory and
finding the end of a
Hi!
[The following falls under the category micro-optimisation but may IMO
still be worth an investigation]
After working on various parts of OpenSolaris I found that is common to
use the following sequence to concatenate strings:
-- snip --
...
char *s;
...
strcat(s, foo);
strcat(s, /);
20 matches
Mail list logo
