473,320 Members | 1,724 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Two Questions about "strlen", "strcat" and "strcpy"

I have 2 questions:

1. strlen returns an unsigned (size_t) quantity. Why is an unsigned
value more approprate than a signed value? Why is unsighned value less
appropriate?

2. Would there be any advantage in having strcat and strcpy return a
pointer to the "end" of the destination string rather than returning a
pointer to its beginning?

Thanks,
Matt
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05
81 7191
In article <cr********************************@4ax.com>,
Alan Balmer <al******@spamcop.net> wrote:
On Mon, 30 Aug 2004 23:04:10 GMT, ga*****@yin.interaccess.com (Kenny
McCormack) wrote:

There's another newsgroup, just down the hall, which discusses the C
standard and things which should go in its next version.


I think we all understand that (certainly Jacob & I do). And I think we
understand the reasons why it is so. I think we all understand the context
of my little jibe.


I'm sure that Jacob understands it, but he seems reluctant to accept
it. Personally, I weary of the constant advertisements for his "better
than C" language.


Two comments:
1) The reality is that every one of us does actually program in an
environment that is "better than C" - given the accepted clc definition of
"C", namely, the minimal subset defined by "the standard". I.e, I program
in Unix and hence my environment is a superset of "standard C". You might
program under Windows using MS tools, and your environment would be
a different superset of "standard C". Jacob presumably uses his own
creation, which is, you guessed it, a superset of "standard C".

2) Maybe we need to newgroup a new group: comp.lang.c.practical.

To be honest, I don't know why Jacob keeps pushing pushing lcc here, but
I'm glad he does. One of these days, I'd like to get around to trying it
out.

Nov 14 '05 #51
On Wed, 01 Sep 2004 20:07:45 GMT, ga*****@yin.interaccess.com (Kenny
McCormack) wrote:
In article <cr********************************@4ax.com>,
Alan Balmer <al******@spamcop.net> wrote:
On Mon, 30 Aug 2004 23:04:10 GMT, ga*****@yin.interaccess.com (Kenny
McCormack) wrote:
>
There's another newsgroup, just down the hall, which discusses the C
standard and things which should go in its next version.

I think we all understand that (certainly Jacob & I do). And I think we
understand the reasons why it is so. I think we all understand the context
of my little jibe.
I'm sure that Jacob understands it, but he seems reluctant to accept
it. Personally, I weary of the constant advertisements for his "better
than C" language.


Two comments:
1) The reality is that every one of us does actually program in an
environment that is "better than C" -


Of course, but we avoid discussing it here. More particularly, we
don't jump in at every opportunity and say "you should really be using
*my* favorite implementation and platform - it would do it better."
given the accepted clc definition of
"C", namely, the minimal subset defined by "the standard". I.e, I program
in Unix and hence my environment is a superset of "standard C". You might
program under Windows using MS tools, and your environment would be
a different superset of "standard C". Jacob presumably uses his own
creation, which is, you guessed it, a superset of "standard C".

2) Maybe we need to newgroup a new group: comp.lang.c.practical.

To be honest, I don't know why Jacob keeps pushing pushing lcc here, but
I'm glad he does. One of these days, I'd like to get around to trying it
out.


Write yourself a note and pin it to the wall. Then Jacob won't need to
keep reminding you.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #52
"be*******@aol.com" <be*******@127.0.0.1:7501> wrote in message news:<41********@127.0.0.1>...
Da*****@cern.ch (Dan Pop) wrote:
Can you name a GNU F90 or later compiler? They even implemented Ada95...


<snip> The gfortran project at http://gcc.gnu.org/fortran/
, which forked from g95 , is at an earlier stage. I believe both use gcc
as a back-end and should eventually be usable wherever gcc is.
<snip>


I would say that gfortran is at a comparable level of development. It
has the advantage that it is expected to be distributed as an official
part of gcc 3.5 (that is a large part of the reason it is to be 3.5
and not 3.4.x) so it has been tested on a wider variety of systems and
will be readily available for a wider variety of systems. It also
benefits from the active participation from two experienced members of
the gcc team, Toon Moene and Richard Henderson.

While Fortran 95 is a sufficiently complex language that all compilers
have bugs that prevent full conformance with the standard, neither g95
nor gfortran attempt to fully implement the language at this time. It
is expected that at the time of the gcc 3.5 release, gfortran will
parse and generate code for the full standard language, and a few
common extensions. I expect that the result will approximate a
commercial beta release, but do an acceptable job on the f77 subset.
The wider testing after the release as part of gcc should "soon" lead
to a much more robust implementation.
Nov 14 '05 #53
Kenny McCormack wrote:
.... snip ...
To be honest, I don't know why Jacob keeps pushing pushing lcc
here, but I'm glad he does. One of these days, I'd like to get
around to trying it out.


He makes many of his announcements on comp.compilers.lcc. That is
a low traffic group. Bug reports also show up there, which he
usually seems to repair very quickly.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Nov 14 '05 #54

In article <41***************@boeing.com.invalid>, Default User <fi********@boeing.com.invalid> writes:
Michael Wojcik wrote:

In article <cl****************@plethora.net>, Default User <fi********@boeing.com.invalid> writes:
Matt wrote:

> 2. Would there be any advantage in having strcat and strcpy return a
> pointer to the "end" of the destination string rather than returning a
> pointer to its beginning?

No. It returns the pointer to the start so you can chain calls:


Which makes it so much easier to overflow buffers, fail to check
results, and so forth...


No more so than any other use of those functions. Whether they're
chained or not is irrelevant.


Ugh. That's what I get for posting over-hastily. I thought I had
a counter-example, but you're right; they're only safe if you know
both how large your buffer is and how much data you're copying in,
and given that information, it's just as safe to chain them as not.
(And, of course, there are no results to be checked from strcpy and
strcat.)

--
Michael Wojcik mi************@microfocus.com

Thanks for your prompt reply and thanks for your invitatin to your
paradise. Based on Buddihism transmigration, I realize you, European,
might be a philanthropist in previous life!
-- supplied by Stacy Vickers
Nov 14 '05 #55
Michael Wojcik wrote:

In article <41***************@boeing.com.invalid>, Default User
<fi********@boeing.com.invalid> writes:
Michael Wojcik wrote:
> No. It returns the pointer to the start so you can chain calls:

Which makes it so much easier to overflow buffers, fail to check
results, and so forth...


No more so than any other use of those functions. Whether they're
chained or not is irrelevant.


Ugh. That's what I get for posting over-hastily. I thought I had
a counter-example, but you're right; they're only safe if you know
both how large your buffer is and how much data you're copying in,
and given that information, it's just as safe to chain them as not.
(And, of course, there are no results to be checked from strcpy and
strcat.)

Right. A possible counter-example you could have put forth is that the
nested calls make it a bit less intuitive to do the bounds checking,
because one of the calls is inside the other.

There are various methods for ensuring safety. Some like to a running
tab and only use strncpy() and strncat() to make sure that each call is
safe or do a numeric comparison first and reject operations that would
overflow.

Brian Rodenborn
Nov 14 '05 #56
On 30 Aug 2004 05:00:01 GMT
Default User <fi********@boeing.com.invalid> wrote:
Matt wrote:


<snip>
2. Would there be any advantage in having strcat and strcpy return a
pointer to the "end" of the destination string rather than returning
a pointer to its beginning?


No. It returns the pointer to the start so you can chain calls:
char str[80];

strcat(strcpy(str, "Hello "), "World!");


This would also work if strcpy was specified as returning a pointer to
the end of the string.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #57
"Keith Thompson" <ks***@mib.org> wrote in message
news:cl****************@plethora.net...
ma********@hotmail.com (Matt) writes:
[...]
2. Would there be any advantage in having strcat and strcpy return a
pointer to the "end" of the destination string rather than returning a
pointer to its beginning?


Possibly a slight one. Returning a pointer to the beginning doesn't
give you any information you didn't already have. Returning a pointer
to the end (presumably to the trailing '\0') could, for example, let
you catenate more characters onto the end of the string without having
to scan the whole string again to find the end of it.

The disadvantage is that it would break code that depends on the
current behavior.


Perhaps a character count would be apropos, as a printf() does. This way you
have the original pointer and an offset to the end of the string.

--
Mabden
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #58
Default User wrote:
Matt wrote:
..... snip ...
2. Would there be any advantage in having strcat and strcpy
return a pointer to the "end" of the destination string rather
than returning a pointer to its beginning?


No. It returns the pointer to the start so you can chain calls:

char str[80];

strcat(strcpy(str, "Hello "), "World!");


However it is a bad habit to use it in that manner. Consider:

char buff[] = "blah";

printf("%s%s\n", buff, strcpy(buff, "foo"));

which looks fairly normal, but is unlikely to give the expected
results. Using routines such as strlcpy and strlcat (which DON'T
return the pointer) will avoid this trap.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #59
bl*@drizzle.com (Brian Raiter) wrote:
I have 2 questions:

1. strlen returns an unsigned (size_t) quantity. Why is an unsigned
value more approprate than a signed value? Why is unsighned value less
appropriate?

2. Would there be any advantage in having strcat and strcpy return a
pointer to the "end" of the destination string rather than returning a
pointer to its beginning?


I also have 2 questions:

1. Posting homework questions to usenet frequently returns
misinformation and insults. Why is this more appropriate than actual
answers?

2. Would there be any advantage in having you do your own homework?


Those sound suspiciously like homework questions (perhaps in a
course on computing ethics).

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #60
Michael Wojcik wrote:
.... snip ...
Ugh. That's what I get for posting over-hastily. I thought I had
a counter-example, but you're right; they're only safe if you know
both how large your buffer is and how much data you're copying in,
and given that information, it's just as safe to chain them as not.
(And, of course, there are no results to be checked from strcpy and
strcat.)


There are results to be checked in strlcat and strlcpy. See:

<http://cbfalconer.home.att.net/download/strlcpy.zip>

(No noises about reserved identifiers please. Covered in the ref)

--
Some useful references:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> C-library
Nov 14 '05 #61
In <41***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Kenny McCormack wrote:

... snip ...

To be honest, I don't know why Jacob keeps pushing pushing lcc
here, but I'm glad he does. One of these days, I'd like to get
around to trying it out.


He makes many of his announcements on comp.compilers.lcc. That is
a low traffic group. Bug reports also show up there, which he
usually seems to repair very quickly.


If you manage to convince him that they are bugs...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #62
Flash Gordon wrote:
On 30 Aug 2004 05:00:01 GMT
Default User <fi********@boeing.com.invalid> wrote:
Matt wrote:


<snip>
2. Would there be any advantage in having strcat and strcpy
return a pointer to the "end" of the destination string rather
than returning a pointer to its beginning?


No. It returns the pointer to the start so you can chain calls:
char str[80];

strcat(strcpy(str, "Hello "), "World!");


This would also work if strcpy was specified as returning a pointer to
the end of the string.


Yes, but only because it's strcat(). Not so if you wanted to use
strlen) or strstr() or other string functions that need a pointer to
the beginning of the string, or if you were passing the result to a
home-grown function. My example wasn't the best.

Brian Rodenborn
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #63
CBFalconer wrote:
Default User wrote:
Matt wrote:

.... snip ...
2. Would there be any advantage in having strcat and strcpy
return a pointer to the "end" of the destination string rather
than returning a pointer to its beginning?


No. It returns the pointer to the start so you can chain calls:

char str[80];

strcat(strcpy(str, "Hello "), "World!");


However it is a bad habit to use it in that manner. Consider:

char buff[] = "blah";

printf("%s%s\n", buff, strcpy(buff, "foo"));

I'm confused, you said my way was poor usage, then showed some other
usage altogether, one dependent on order of evaluation of function
arguments. Mine had no such dependency.

You could just as well show:

int i;

printf("%d%d\n", i, i = 10);
Then claim that means assigning to integers is bad.

Brian Rodenborn
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #64
Default User wrote:
CBFalconer wrote:
Default User wrote:
Matt wrote:

.... snip ...

2. Would there be any advantage in having strcat and strcpy
return a pointer to the "end" of the destination string rather
than returning a pointer to its beginning?

No. It returns the pointer to the start so you can chain calls:

char str[80];

strcat(strcpy(str, "Hello "), "World!");


However it is a bad habit to use it in that manner. Consider:

char buff[] = "blah";

printf("%s%s\n", buff, strcpy(buff, "foo"));


I'm confused, you said my way was poor usage, then showed some
other usage altogether, one dependent on order of evaluation of
function arguments. Mine had no such dependency.


No, my point is that the fact that strcpy returns a pointer to its
first argument encourages such evil usage by the unaware.
strlcpy, on the other hand, returns a length, so cannot be used in
such a manner, and forces proper separate evaluation. I guess I
was unclear again.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #65
[ removed CLCM from the distribution ]

CBFalconer wrote:

However it is a bad habit to use it in that manner. Consider:

char buff[] = "blah";

printf("%s%s\n", buff, strcpy(buff, "foo"));


I'm confused, you said my way was poor usage, then showed some
other usage altogether, one dependent on order of evaluation of
function arguments. Mine had no such dependency.


No, my point is that the fact that strcpy returns a pointer to its
first argument encourages such evil usage by the unaware.
strlcpy, on the other hand, returns a length, so cannot be used in
such a manner, and forces proper separate evaluation. I guess I
was unclear again.


But what is wrong with the usage you show then? If you removed the
first usage of buff, then you'd have:

printf("%s\n", strcpy(buff, "foo"));
That works just fine, causes no problems and does just what you'd think.

Brian Rodenborn

Nov 14 '05 #66
Default User wrote:
CBFalconer wrote:
However it is a bad habit to use it in that manner. Consider:

char buff[] = "blah";

printf("%s%s\n", buff, strcpy(buff, "foo"));

I'm confused, you said my way was poor usage, then showed some
other usage altogether, one dependent on order of evaluation of
function arguments. Mine had no such dependency.


No, my point is that the fact that strcpy returns a pointer to its
first argument encourages such evil usage by the unaware.
strlcpy, on the other hand, returns a length, so cannot be used in
such a manner, and forces proper separate evaluation. I guess I
was unclear again.


But what is wrong with the usage you show then? If you removed the
first usage of buff, then you'd have:

printf("%s\n", strcpy(buff, "foo"));

That works just fine, causes no problems and does just what you'd think.


Yes, but try what I wrote, and you won't get what you might
expect.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"If I knew then what I know today, I would still have invaded
Iraq. It was the right decision" - G.W. Bush, 2004-08-02
Nov 14 '05 #67
CBFalconer wrote:

> However it is a bad habit to use it in that manner. Consider:
> >
> char buff[] = "blah";
> >
> printf("%s%s\n", buff, strcpy(buff, "foo"));
Yes, but try what I wrote, and you won't get what you might
expect.

I got one of the two possible results. Why would I not expect that? As
I said, as far as I can see all your example does is illustrate
something about order of evaluation of arguments.

If you think it demonstrates something else, just assume I'm too stupid
to figure it out and explain it.

Brian Rodenborn
Nov 14 '05 #68
Default User wrote:
CBFalconer wrote:
>>However it is a bad habit to use it in that manner. Consider:
>>
>> char buff[] = "blah";
>>
>> printf("%s%s\n", buff, strcpy(buff, "foo"));

Yes, but try what I wrote, and you won't get what you might
expect.


I got one of the two possible results. Why would I not expect that? As
I said, as far as I can see all your example does is illustrate
something about order of evaluation of arguments. [...]


I think there's only one possible result. Regardless
of order of evaluation, the second and third arguments to
the printf() call have the same value, to wit, `&buff[0]'.
Also, there's a sequence point just before printf() starts
to execute, so when printf() uses those two pointers it
must find that they both point to "foo". Unless I've
missed something really fundamental, the above code *must*
output "foofoo\n". No (ahem) two ways about it.

--
Er*********@sun.com

Nov 14 '05 #69
Eric Sosman wrote:
Default User wrote:
CBFalconer wrote:
>>> However it is a bad habit to use it in that manner. Consider:
>>>
>>> char buff[] = "blah";
>>>
>>> printf("%s%s\n", buff, strcpy(buff, "foo"));
I think there's only one possible result. Regardless
of order of evaluation, the second and third arguments to
the printf() call have the same value, to wit, `&buff[0]'.
Also, there's a sequence point just before printf() starts
to execute, so when printf() uses those two pointers it
must find that they both point to "foo". Unless I've
missed something really fundamental, the above code *must*
output "foofoo\n". No (ahem) two ways about it.


I don't think that you can guarantee anything. Given the snippet above,
aren't you invoking UB, since "foofoo\n" overruns the inital allocation
of buff (which I suspect should be 5 characters)?
Nov 14 '05 #70
red floyd wrote:
Eric Sosman wrote:
Default User wrote:
CBFalconer wrote:

>>>> However it is a bad habit to use it in that manner. Consider:
>>>>
>>>> char buff[] = "blah";
>>>>
>>>> printf("%s%s\n", buff, strcpy(buff, "foo"));


I think there's only one possible result. Regardless
of order of evaluation, the second and third arguments to
the printf() call have the same value, to wit, `&buff[0]'.
Also, there's a sequence point just before printf() starts
to execute, so when printf() uses those two pointers it
must find that they both point to "foo". Unless I've
missed something really fundamental, the above code *must*
output "foofoo\n". No (ahem) two ways about it.


I don't think that you can guarantee anything. Given the snippet above,
aren't you invoking UB, since "foofoo\n" overruns the inital allocation
of buff (which I suspect should be 5 characters)?


printf() sends output to the `stdout' stream, not
to an in-memory buffer.

(Oddly enough, my first glance at the code came up
with exactly the same mis-reading! I guess the name
`buff' carries more suggestive power than expected.)

--
Er*********@sun.com

Nov 14 '05 #71
Eric Sosman wrote:

(Oddly enough, my first glance at the code came up
with exactly the same mis-reading! I guess the name
`buff' carries more suggestive power than expected.)


Yep. I misread it as sprintf().

<EMILY-LATELLA> Never Mind </EMILY-LATELLA>
Nov 14 '05 #72
Default User wrote:
CBFalconer wrote:
> However it is a bad habit to use it in that manner. Consider:
> > >
> char buff[] = "blah";
> > >
> printf("%s%s\n", buff, strcpy(buff, "foo"));

Yes, but try what I wrote, and you won't get what you might
expect.


I got one of the two possible results. Why would I not expect that?
As I said, as far as I can see all your example does is illustrate
something about order of evaluation of arguments.

If you think it demonstrates something else, just assume I'm too
stupid to figure it out and explain it.


There is only one possible result. It is NOT "blahfoo". Both
arguments load a pointer to the buffer buff. Both are evaluated
before printf is called. The strcpy makes buff hold "foo" as a
side effect. The output should be "foofoo".

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
Nov 14 '05 #73
CBFalconer wrote:

There is only one possible result. It is NOT "blahfoo". Both
arguments load a pointer to the buffer buff. Both are evaluated
before printf is called. The strcpy makes buff hold "foo" as a
side effect. The output should be "foofoo".


I see what you are getting at. But again, it really only demonstrates a
problem using side-effects when using pointers multiple times in a
function call parameter list.

It has little to do with using the return value of the str* functions
in other calls, which was the original assertion. Unless they returned
void, you could demonstrate the same thing.

Brian Rodenborn
Nov 14 '05 #74
Default User wrote:
CBFalconer wrote:
There is only one possible result. It is NOT "blahfoo". Both
arguments load a pointer to the buffer buff. Both are evaluated
before printf is called. The strcpy makes buff hold "foo" as a
side effect. The output should be "foofoo".


I see what you are getting at. But again, it really only demonstrates
a problem using side-effects when using pointers multiple times in a
function call parameter list.

It has little to do with using the return value of the str* functions
in other calls, which was the original assertion. Unless they returned
void, you could demonstrate the same thing.


It presents an easily overlooked means of injecting stinging
insects into a program. Better designed routines, such as strlcpy
and strlcat, do not return the pointer but a useful entity, i.e.
the resultant length. Thus they never lure the programmer into
this mistake. I for one would dearly love the next standard, or
even some intermediate thing equivalent to C95, to include these
routines.

See the whole story about them on my site:

<http://cbfalconer.home.att.net/download/strlcpy.zip>

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
Nov 14 '05 #75
CBFalconer wrote:
Default User wrote:
CBFalconer wrote: It has little to do with using the return value of the str*
functions in other calls, which was the original assertion. Unless
they returned void, you could demonstrate the same thing.


It presents an easily overlooked means of injecting stinging
insects into a program. Better designed routines, such as strlcpy
and strlcat, do not return the pointer but a useful entity, i.e.
the resultant length. Thus they never lure the programmer into
this mistake. I for one would dearly love the next standard, or
even some intermediate thing equivalent to C95, to include these
routines.


Well, that's your opinion and that's fine and all. I just don't see
that it's really that big of a deal.

What really happens in your example is a confusion based on the fact
that the first argument passed to printf() is a pointer to an entity
that is changed via side-effect in another argument. That would happen
with your strlcpy as well.
The usual usage of the nested str* calls is something like this:

size t len;
char buff[40] = "Hello";

len = strlen(strcat(buff, " World!");

Brian Rodenborn

Nov 14 '05 #76
Default User wrote:
CBFalconer wrote:
Default User wrote:

It has little to do with using the return value of the str*
functions in other calls, which was the original assertion.
Unless they returned void, you could demonstrate the same thing.


It presents an easily overlooked means of injecting stinging
insects into a program. Better designed routines, such as strlcpy
and strlcat, do not return the pointer but a useful entity, i.e.
the resultant length. Thus they never lure the programmer into
this mistake. I for one would dearly love the next standard, or
even some intermediate thing equivalent to C95, to include these
routines.


Well, that's your opinion and that's fine and all. I just don't see
that it's really that big of a deal.

What really happens in your example is a confusion based on the
fact that the first argument passed to printf() is a pointer to
an entity that is changed via side-effect in another argument.
That would happen with your strlcpy as well.

The usual usage of the nested str* calls is something like this:

size t len;
char buff[40] = "Hello";

len = strlen(strcat(buff, " World!");


Using strlcpy that would be (safely):

len = strlcat(buff, " World!", sizeof buff);

assuming buff is local so sizeof works. Otherwise supply that
constant. Notice there is only one function call involved.
Insufficient space is detectable after the call.

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
Nov 14 '05 #77
"Matt" <ma********@hotmail.com> wrote in message
news:cl****************@plethora.net...
I have 2 questions:

1. strlen returns an unsigned (size_t) quantity. Why is an unsigned
value more approprate than a signed value? Why is unsighned value less
appropriate?
You have a very good point here.
The obvious but simplistic reason is that negative string lengths are
meaningless. But then wouldn't it make sense for strlen(NULL) to be -1 ?
With the current C spec, it is undefined behaviour, and most implementations
will crash...
The decent but somewhat optimistic explanation is that it allows for strings
to be as large as the largest object (size_t). But I have seen
implementations where the largest objects were larger than size_t could
handle, and strings were still limited to 64KB.
On a 32 bit system, defining strlen as returning an int would make it
inconsistent with C99 but would prevent signed/unsigned clashes resulting in
hard to find bugs such as this one:

int n = -1;
const char *str = "Hello, world\n";
if (strlen(str) > n) {
// why does this test fail?
printf("OK\n");
}
2. Would there be any advantage in having strcat and strcpy return a
pointer to the "end" of the destination string rather than returning a
pointer to its beginning?


For some uses, it would be advantageous for strcpy or strcat to return a
pointer to the end of the string, or the length of the string, or nothing at
all. People can define their own alternatives and some are quite common
albeit not standard. The C string functions were defined a LONG time ago,
changing the semantics is impossible without breaking millions of lines of
existing code.

Chqrlie

PS: talking about string functions, I strongly advise against any use of
strncpy and strncat, whose semantics are IMHO quite broken and *very* error
prone.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #78
Charlie Gordon wrote:
The obvious but simplistic reason is that negative string lengths are
meaningless. But then wouldn't it make sense for strlen(NULL) to be -1 ?


No, NULL doesn't denote a string, and even if it did,
a length of -1 would "make sense" only if it pertained
to going backward from the given starting location.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #79
On 19 Sep 2004 12:34:58 GMT in comp.lang.c.moderated, "Douglas A.
Gwyn" <DA****@null.net> wrote:
Charlie Gordon wrote:
The obvious but simplistic reason is that negative string lengths are
meaningless. But then wouldn't it make sense for strlen(NULL) to be -1 ?


No, NULL doesn't denote a string, and even if it did,
a length of -1 would "make sense" only if it pertained
to going backward from the given starting location.


It could also refer to the character before the end of string.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #80
Brian Inglis <Br**********@SystematicSW.Invalid> wrote:
On 19 Sep 2004 12:34:58 GMT in comp.lang.c.moderated, "Douglas A.
Gwyn" <DA****@null.net> wrote:
Charlie Gordon wrote:
The obvious but simplistic reason is that negative string lengths are
meaningless. But then wouldn't it make sense for strlen(NULL) to be -1 ?


No, NULL doesn't denote a string, and even if it did,
a length of -1 would "make sense" only if it pertained
to going backward from the given starting location.


It could also refer to the character before the end of string.


Not as a return value from strlen(), it doesn't. And besides, C != Icon.

Richard
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #81
Brian Inglis wrote:
<DA****@null.net> wrote:
Charlie Gordon wrote:
The obvious but simplistic reason is that negative string lengths are
meaningless. But then wouldn't it make sense for strlen(NULL) to be -1 ?

No, NULL doesn't denote a string, and even if it did,
a length of -1 would "make sense" only if it pertained
to going backward from the given starting location.

It could also refer to the character before the end of string.


I suppose almost any arbitrary meaning could be assigned
to meaningless cases. However, strlen can't return a
negative value for any valid string, at least not while
preserving its traditional behavior.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #82

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: softwareengineer2006 | last post by:
All Interview Questions And Answers 10000 Interview Questions And Answers(C,C++,JAVA,DOTNET,Oracle,SAP) I have listed over 10000 interview questions asked in interview/placement test papers for...
0
by: connectrajesh | last post by:
INTERVIEWINFO.NET http://www.interviewinfo.net FREE WEB SITE AND SERVICE FOR JOB SEEKERS /FRESH GRADUATES NO ADVERTISEMENT
2
by: freepdfforjobs | last post by:
Full eBook with 4000 C#, JAVA,.NET and SQL Server Interview questions http://www.questpond.com/SampleInterviewQuestionBook.zip Download the JAVA , .NET and SQL Server interview sheet and rate...
4
by: Drew | last post by:
I posted this to the asp.db group, but it doesn't look like there is much activity on there, also I noticed that there are a bunch of posts on here pertaining to database and asp. Sorry for...
8
by: Krypto | last post by:
Hi, I have used Python for a couple of projects last year and I found it extremely useful. I could write two middle size projects in 2-3 months (part time). Right now I am a bit rusty and trying...
0
by: ramu | last post by:
C# Interview Questions and Answers8 http://allinterviewsbooks.blogspot.com/2008/07/c-interview-questions-and-answers8.html C# Interview Questions and Answers7...
1
by: ramu | last post by:
C# Interview Questions and Answers8 http://allinterviewsbooks.blogspot.com/2008/07/c-interview-questions-and-answers8.html C# Interview Questions and Answers7...
0
by: ramu | last post by:
C# Interview Questions and Answers8 http://allinterviewsbooks.blogspot.com/2008/07/c-interview-questions-and-answers8.html C# Interview Questions and Answers7...
0
by: reema | last post by:
EJB Interview Questions http://interviewdoor.com/technical/EJB-Interview-Questions.htm CSS Interview Questions http://interviewdoor.com/technical/CSS-Interview-Questions.htm C Interview Questions...
0
by: reema | last post by:
EJB Interview Questions http://interviewdoor.com/technical/EJB-Interview-Questions.htm CSS Interview Questions http://interviewdoor.com/technical/CSS-Interview-Questions.htm C Interview Questions...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.