Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > string concatenation

Reply
Thread Tools

string concatenation

 
 
Michael Wojcik
Guest
Posts: n/a
 
      02-20-2004

In article <(E-Mail Removed) >, http://www.velocityreviews.com/forums/(E-Mail Removed) (James Kuyper) writes:
> (E-Mail Removed) (Michael Wojcik) wrote in message news:<(E-Mail Removed)>...
> > Presumably in at least some cases they could be provided by the
> > implementation, and in such a case programs using them would not
> > invoke UB, correct?

>
> You need to be careful when you read the standard, it contains many
> pieces of technical jargon which are defined by the standard itself to
> mean something not quite the same as the ordinary english definition.
> This is one example. "undefined behavior" doesn't mean "behavior that
> is undefined"; it's a piece of technical jargon used by the C
> standard, which roughly means "behavior that is not defined by the C
> standard".


Right. I understood that...

> The behavior of such code remains UB even if the implementation
> chooses to provide it's own definition. UB includes, as one of it's
> literal infinity of possibilities, behaving exactly as the
> implementation has defined it to behave.


....but missed this bit when I glanced over the Standard before posting
that message. I somehow got the impression that if the implementation
provided additional str* functions (with external linkage), a program
running under that implementation could invoke them without causing UB.
Which doesn't make much sense, now that I think about it.

(Thanks also to Dan for posting a similar correction.)

--
Michael Wojcik (E-Mail Removed)

A: Because it messes up 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?
-- David Bonde
 
Reply With Quote
 
 
 
 
Sean Burke
Guest
Posts: n/a
 
      03-06-2004

Brian Inglis <(E-Mail Removed)> writes:

> On Fri, 13 Feb 2004 17:12:51 GMT in comp.std.c, Sean Burke
> <(E-Mail Removed)> wrote:
>
> >
> >Maurizio Loreti <(E-Mail Removed)> writes:
> >
> >> (E-Mail Removed) (Dan Pop) writes:
> >>
> >> > In <(E-Mail Removed)> Sean Burke <(E-Mail Removed)> writes:
> >> >
> >> > >Since you mention security (e.g. buffer overflows),
> >> > >it's worth adding that strcpy, strcat have long since
> >> > >been deprecated in favor of strlcpy, strlcat.

>
> You mispelled n as noted below.
>
> >> > On the contrary, any C program using these identifiers with external
> >> > linkage invokes undefined behaviour.
> >>
> >> Maybe Mr. Burke misspelled "strncpy" and "strncat", mentioned in
> >> ISO/IEC 9899:1999 under 7.21.2.4 and 7.21.3.2 ? Their prototypes (in
> >> <string.h>) are
> >>
> >> char *strncpy(char * restrict, const char * restrict, size_t);
> >> char *strncat(char * restrict, const char * restrict, size_t);

> >
> >No, I meant strlcpy/strlcat, and I find them to be better
> >than the strn* calls. I'm astonished to learn that they
> >aren't yet standardised.

>
> You must be one of those Pascal types who like to access strings as
> character arrays with indices, instead of pointers as K&R intended.
> You wouldn't have liked BCPL, B, or NB either! ;^>
>
> The BSD string functions strl{cat,cpy} are unlikely to be standardised
> as they aren't supported by many libraries, and don't fit with any of
> the current string handling functions, except strspn() and strcspn(),
> which are also not heavily advertised or used, as their names are
> confusing, nondescriptive, unobvious, and they too return counts
> instead of pointers.
>
> In any case, I prefer to check my string lengths before I do anything
> with strcpy(); strncpy()'s handy for clearing previous junk from
> buffers; never need strcat(), as I like to know where I am, and going
> to be in a buffer. Avoids buffer overflows, heap and stack overwrites,
> SIGSEGV, ACCVIO, and other unpleasantries, don't ya know.


I'm not sure why you've revived this long-dormant thread.
As far as factual matters go, I recall that the upshot of
the discussion was that:

1. strcpy/strcat have not been formally deprecated in the
C standard

2. strlcpy/strlcat have not been incorporated into the
C standard

As far as matters of preference go, if you find strncpy/ncat
adequate for your needs, that's great. I agree that strlen()
alone is sufficient to avoid overflows with strcpy/cat, as
long as you are careful.

I find that code using strlcpy/lcat is cleaner and less
susceptible to error, but YMMV.

Oh, and as for strspn, strcspn - I find these are very useful
functions, but it's another example of the power of idiom in
programming. It took me a long time to notice that I could
this, for example:

if (strspn(argv[i], "-0123456789") != strlen(argv[i]))
fprintf(stderr, "The argument \"%s\" must be a decimal integer.\n", argv[i]);

-SEan










 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      03-06-2004
Brian Inglis wrote:
>

.... snip ...
>
> The BSD string functions strl{cat,cpy} are unlikely to be
> standardised as they aren't supported by many libraries, and don't
> fit with any of the current string handling functions, except
> strspn() and strcspn(), which are also not heavily advertised or
> used, as their names are confusing, nondescriptive, unobvious, and
> they too return counts instead of pointers.


Which (return values) is precisely why they should be used in
preference to the already available standard routines. They
greatly reduce the prevalence of errors. They are also easily
implemented with purely standard C and no library dependencies, so
there is no reason to eschew them. For one implementation (put in
public domain) see:

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

For justifications for their use, etc, see:

<http://www.courtesan.com/todd/papers/strlcpy.html>

If your system has these routines, congratulations. If not, feel
free to mount mine. In either case using them will reduce your
error rate.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-07-2004
Sean Burke <(E-Mail Removed)> writes:
[...]
> Oh, and as for strspn, strcspn - I find these are very useful
> functions, but it's another example of the power of idiom in
> programming. It took me a long time to notice that I could
> this, for example:
>
> if (strspn(argv[i], "-0123456789") != strlen(argv[i]))
> fprintf(stderr,
> "The argument \"%s\" must be a decimal integer.\n",
> argv[i]);


[code reformatted to fit screen]

That's fine if you consider "3-2", "---", and "" to be decimal integers.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
 
Reply With Quote
 
Derk Gwen
Guest
Posts: n/a
 
      03-07-2004
# > if (strspn(argv[i], "-0123456789") != strlen(argv[i]))
# > fprintf(stderr,
# > "The argument \"%s\" must be a decimal integer.\n",
# > argv[i]);
#
# [code reformatted to fit screen]
#
# That's fine if you consider "3-2", "---", and "" to be decimal integers.

if (strtol(p,&q,0), p==q) not an integer
else if (*q) integer followed by something else
else an integer

--
Derk Gwen http://derkgwen.250free.com/html/index.html
We found a loophole; they can't keep us out anymore.
 
Reply With Quote
 
Sean Burke
Guest
Posts: n/a
 
      03-07-2004

Derk Gwen <(E-Mail Removed)> writes:

> # > if (strspn(argv[i], "-0123456789") != strlen(argv[i]))
> # > fprintf(stderr,
> # > "The argument \"%s\" must be a decimal integer.\n",
> # > argv[i]);
> #
> # [code reformatted to fit screen]
> #
> # That's fine if you consider "3-2", "---", and "" to be decimal integers.
>
> if (strtol(p,&q,0), p==q) not an integer
> else if (*q) integer followed by something else
> else an integer


Anyone who knows how to use strtol doesn't need advice from me.
But how many people just pass the argument to atoi() and let any
problems manifest themselves further along?

I think the method I illustrated has the virtue of being a
"pretty good" filter, while also being much more widely
applicable than strtol().

Suppose I want to accept an IP address, but I want to ensure
that it's not a domain name:

if (strspn(argv[i], ".0123456789") != strlen(argv[i]))
fprintf(stderr, "Arg \"%s\" must be an numeric IP address.\n", argv[i]);

Sure, "...0" would pass this filter, but the chief goal is
to reject "foo.bar.com". Yes, I could use inet_addr() instead,
but what does inet_addr() do with "9.37.190.192.in-addr.arpa"?

Certainly, regcomp/regexec provide a filtering method that can
be both precise and very general. But strspn/cspn() provide a
useful balance of precision and convenience.

-SEan






 
Reply With Quote
 
Sean Burke
Guest
Posts: n/a
 
      03-07-2004

Derk Gwen <(E-Mail Removed)> writes:

> # > if (strspn(argv[i], "-0123456789") != strlen(argv[i]))
> # > fprintf(stderr,
> # > "The argument \"%s\" must be a decimal integer.\n",
> # > argv[i]);
> #
> # [code reformatted to fit screen]
> #
> # That's fine if you consider "3-2", "---", and "" to be decimal integers.
>
> if (strtol(p,&q,0), p==q) not an integer
> else if (*q) integer followed by something else
> else an integer


Anyone who knows how to use strtol doesn't need advice from me.
But how many people just pass the argument to atoi() and let any
problems manifest themselves further along?

I think the method I illustrated has the virtue of being a
"pretty good" filter, while also being much more widely
applicable than strtol().

Suppose I want to accept an IP address, but I want to ensure
that it's not a domain name:

if (strspn(argv[i], ".0123456789") != strlen(argv[i]))
fprintf(stderr, "Arg \"%s\" must be an numeric IP address.\n", argv[i]);

Sure, "...0" would pass this filter, but the chief goal is
to reject "foo.bar.com". Yes, I could use inet_addr() instead,
but what does inet_addr() do with "9.37.190.192.in-addr.arpa"?

Certainly, regcomp/regexec provide a filtering method that can
be both precise and very general. But strspn/cspn() provide a
useful balance of precision and convenience.

-SEan






 
Reply With Quote
 
Valentin Nechayev
Guest
Posts: n/a
 
      03-07-2004
>>> Sean Burke wrote:

SB> Sure, "...0" would pass this filter, but the chief goal is
SB> to reject "foo.bar.com". Yes, I could use inet_addr() instead,
SB> but what does inet_addr() do with "9.37.190.192.in-addr.arpa"?

$ host 127.0.0.1
1.0.0.127.IN-ADDR.ARPA domain name pointer localhost
$ ping 1.0.0.127.in-addr.arpa
ping: cannot resolve 1.0.0.127.in-addr.arpa: No address associated with name

Feel the difference between asking A and PTR


-netch-
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
String concatenation vs. string formatting Andrew Berg Python 13 07-10-2011 11:24 PM
String Concatenation & Removing Space Sparky Arbuckle ASP .Net 5 09-01-2005 10:47 PM
String Concatenation problems Daniel Bergquist Perl 2 07-16-2004 01:43 AM
Re: Use of uninitialized value in concatenation (.) or string Error Sukhbir Dhillon Perl 1 04-05-2004 02:31 AM
what's the difference between VHDL 93 CONCATENATION and VHDL 87 CONCATENATION? walala VHDL 3 09-18-2003 04:17 AM



Advertisments