467,923 Members | 1,262 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,923 developers. It's quick & easy.

problem with strcat function

hi,
i have written this strcat but sometime it is giving problem, while
handeling some strings containing
binary and if string containing zero ,
funtion which takes string 1 and its length string2 and its length as
arguments

please tell the correction ,

here iam using
typedef char SINT8;
typedef unsigned char UINT8;
typedef short SINT16;
typedef unsigned short UINT16;
typedef int SINT32;
typedef unsigned int UINT32;
typedef long long UINT64;

UINT8 *
Stringcat (UINT8 *str1
, UINT32 str1len
, UINT8 *str2
, UINT32 str2len )
{
UINT8 *str3, *temp;
temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );
while ( ( *str3++ = *str1++) );
str3--;
while ( ( *str3++ = *str2++ ) );
return temp;
}
regards
ramaswamy BM
banglore

Mar 23 '06 #1
  • viewed: 3327
Share:
20 Replies

ra******@gmail.com wrote:
hi,
i have written this strcat
What's wrong with the standard one? If you need a third string to
contain the result, it should be easy enough to use `strcat()` and some
additional code.
but sometime it is giving problem, while
handeling some strings containing
binary and if string containing zero ,
I don't really understand what you mean by "binary", but you should
know that C strings are arrays of `char` terminated by the `char` with
the value of zero.
funtion which takes string 1 and its length string2 and its length as
arguments

please tell the correction ,

here iam using
typedef char SINT8;
typedef unsigned char UINT8;
typedef short SINT16;
typedef unsigned short UINT16;
typedef int SINT32;
typedef unsigned int UINT32;
typedef long long UINT64;
These are highly misleading. What happens (to someone reading the code)
when your underlying architecture changes, together with the sizes
implied above?
UINT8 *
Stringcat (UINT8 *str1
, UINT32 str1len
, UINT8 *str2
, UINT32 str2len )
{
UINT8 *str3, *temp;
temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );
No need for a cast here. It may mask omission to include <stdlib.h>.
while ( ( *str3++ = *str1++) );
Herein lies your "zero" problem. You copy until you encounter zero.
What was then the point of passing string lengths in the first place?
str3--;
while ( ( *str3++ = *str2++ ) );
Same here...

You probably want simple loops from start to the end of the string,
using the lengths that you get passed.
return temp;
}


I'd still recommend wrapping standard `strcat()` in some extra code.

--
BR, Vladimir

Mar 23 '06 #2

Vladimir S. Oka wrote:
ra******@gmail.com wrote:
hi,
i have written this strcat


What's wrong with the standard one? If you need a third string to
contain the result, it should be easy enough to use `strcat()` and some
additional code.
but sometime it is giving problem, while
handeling some strings containing
binary and if string containing zero ,


I don't really understand what you mean by "binary", but you should
know that C strings are arrays of `char` terminated by the `char` with
the value of zero.
funtion which takes string 1 and its length string2 and its length as
arguments

please tell the correction ,

here iam using
typedef char SINT8;
typedef unsigned char UINT8;
typedef short SINT16;
typedef unsigned short UINT16;
typedef int SINT32;
typedef unsigned int UINT32;
typedef long long UINT64;


These are highly misleading. What happens (to someone reading the code)
when your underlying architecture changes, together with the sizes
implied above?
UINT8 *
Stringcat (UINT8 *str1
, UINT32 str1len
, UINT8 *str2
, UINT32 str2len )
{
UINT8 *str3, *temp;
temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );


No need for a cast here. It may mask omission to include <stdlib.h>.


You should also check for success. `calloc()`, just like `malloc()`
returns NULL if allocation did not succeed.
while ( ( *str3++ = *str1++) );


Herein lies your "zero" problem. You copy until you encounter zero.
What was then the point of passing string lengths in the first place?
str3--;
while ( ( *str3++ = *str2++ ) );


Same here...

You probably want simple loops from start to the end of the string,
using the lengths that you get passed.
return temp;
}


I'd still recommend wrapping standard `strcat()` in some extra code.

--
BR, Vladimir


Mar 23 '06 #3
ra******@gmail.com writes:
i have written this strcat but sometime it is giving problem, while
handeling some strings containing
binary and if string containing zero ,
funtion which takes string 1 and its length string2 and its length as
arguments

please tell the correction ,

here iam using
typedef char SINT8;
typedef unsigned char UINT8;
typedef short SINT16;
typedef unsigned short UINT16;
typedef int SINT32;
typedef unsigned int UINT32;
typedef long long UINT64;
These typedefs are potentially misleading. The sizes of the
predefined types can and do vary across implementations. Plain char
can be either signed or unsigned; if you want a signed type use
"signed char".

It's fortunate that you don't use UINT64, since you've defined it as a
*signed* type.

Knowing the exact sizes of the types you're using is usually not as
useful as you might think. More often, you should select types based
on what they're to be used for rather than on how big they are.
UINT8 *
Stringcat (UINT8 *str1
, UINT32 str1len
, UINT8 *str2
, UINT32 str2len )
{
UINT8 *str3, *temp;
temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );
while ( ( *str3++ = *str1++) );
str3--;
while ( ( *str3++ = *str2++ ) );
return temp;
}


A string is an array of char. Just use type char rahter than UINT8.

Use size_t (defined in <stddef.h>) for sizes and lengths. This
eliminates the need for any of your typedefs.

Your function does something quite different from strcat() (strcat()
doesn't allocated any memory). That's not a bad thing, but the name
is a bit misleading.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 23 '06 #4
ra******@gmail.com wrote:
hi,
i have written this strcat but sometime it is giving problem, while
handeling some strings containing
binary and if string containing zero ,
funtion which takes string 1 and its length string2 and its length as
arguments

please tell the correction ,

here iam using
typedef char SINT8;
typedef unsigned char UINT8;
typedef short SINT16;
typedef unsigned short UINT16;
typedef int SINT32;
typedef unsigned int UINT32;
typedef long long UINT64;
Why don't you use the portable and standard definitions in stdint.h?

UINT8 *
Stringcat (UINT8 *str1
, UINT32 str1len
, UINT8 *str2
, UINT32 str2len )
{
UINT8 *str3, *temp;
temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );
You're not checking for calloc() failure. Even otherwise, malloc()
would be sufficient.
while ( ( *str3++ = *str1++) );
str3--;
while ( ( *str3++ = *str2++ ) );
return temp;
}


Code like this will crash. If you really want to concactenate strings
the standard strcat() or strncat() would probably be sufficient.

Mar 23 '06 #5
santosh wrote:
ra******@gmail.com wrote:
.... snip ...
while ( (*str3++ = *str1++) );
str3--;
while ( (*str3++ = *str2++) );


Code like this will crash. If you really want to concactenate
strings the standard strcat() or strncat() would probably be
sufficient.


I see no reason it should crash, assuming str3 has sufficient
room. But if you want safe overall operation, use strlcat and
strncpy (non-standard). They are available, written in pure
standard C, at:

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

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

Mar 23 '06 #6
On 23 Mar 2006 01:00:47 -0800, ra******@gmail.com wrote:
hi,
i have written this strcat but sometime it is giving problem, while
handeling some strings containing
binary and if string containing zero ,
And it should. If you intend to handle "binary strings", you should
be using the length parameter instead of checking for a character with
value 0.
funtion which takes string 1 and its length string2 and its length as
arguments

please tell the correction ,

here iam using
typedef char SINT8;
typedef unsigned char UINT8;
typedef short SINT16;
typedef unsigned short UINT16;
typedef int SINT32;
typedef unsigned int UINT32;
typedef long long UINT64;

UINT8 *
Stringcat (UINT8 *str1
, UINT32 str1len
, UINT8 *str2
, UINT32 str2len )
{
UINT8 *str3, *temp;
temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );
Did you not get a syntax error here? temp and str3 are both unsigned
char*. Thanks to the useless and incorrect cast, the right side of
the expression evaluates to a char*. The two types are incompatible;
there is no implicit conversion from one to the other.
while ( ( *str3++ = *str1++) );
str3--;
You can replace these two statements with
for (; str1len > 0; str1len--)
*str3++ = *str1++;
while ( ( *str3++ = *str2++ ) );
Similar but use >=.
return temp;
}
regards
ramaswamy BM
banglore

Remove del for email
Mar 24 '06 #7

"CBFalconer" <cb********@yahoo.com> wrote in message
news:44***************@yahoo.com...
snip

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


That seems to be a bad. I tried it twice to no avail. It seems to bring up
at&t's 404 page.
--
MrG{DRGN}


Mar 24 '06 #8
"MrG{DRGN}" <Ia****@here.com> writes:
"CBFalconer" <cb********@yahoo.com> wrote in message
news:44***************@yahoo.com...
snip

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


That seems to be a bad. I tried it twice to no avail. It seems to bring up
at&t's 404 page.


Try <http://cbfalconer.home.att.net/download/strlcpy.zip>; it includes
both strlcpy and strlcat.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 24 '06 #9
CBFalconer wrote:
santosh wrote:
ra******@gmail.com wrote:

... snip ...
while ( (*str3++ = *str1++) );
str3--;
while ( (*str3++ = *str2++) );


Code like this will crash. If you really want to concactenate
strings the standard strcat() or strncat() would probably be
sufficient.

I see no reason it should crash, assuming str3 has sufficient
room. But if you want safe overall operation, use strlcat and
strncpy (non-standard). They are available, written in pure
standard C, at:

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


Aren't function names that begin with "str" followed by another lower
case letter reserved for the implementation? If so, I think the function
names "strlcpy" and "strlcat" are in violation of this rule.

You could name them "str_lcpy" and "str_lcat" to get around this, but
that would invoke undefined behavior, in C89 at least (see Section 6.1.2
of the ANSI/ISO 9899-1990 standard; and for those with a copy of the
best book Herbert Schildt ever wrote, see pages 20 and 200, bullet 7).

--
jay
Mar 24 '06 #10
MrG{DRGN} wrote:
"CBFalconer" <cb********@yahoo.com> wrote in message

snip

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


That seems to be a bad. I tried it twice to no avail. It seems to
bring up at&t's 404 page.


Sorry. That should be:

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

A tip in general - when something like that happens, remove the
last identifier in the URL and see what happens. In this case you
would have gotten an index to the download directory.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Mar 24 '06 #11
jaysome wrote:
CBFalconer wrote:
santosh wrote:
ra******@gmail.com wrote:
... snip ...
while ( (*str3++ = *str1++) );
str3--;
while ( (*str3++ = *str2++) );

Code like this will crash. If you really want to concactenate
strings the standard strcat() or strncat() would probably be
sufficient.


I see no reason it should crash, assuming str3 has sufficient
room. But if you want safe overall operation, use strlcat and
strncpy (non-standard). They are available, written in pure
standard C, at:

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


This should end in "strlcpy.zip" -----------^^^^^^^^^^^
Aren't function names that begin with "str" followed by another
lower case letter reserved for the implementation? If so, I think
the function names "strlcpy" and "strlcat" are in violation of
this rule.

You could name them "str_lcpy" and "str_lcat" to get around this,
but that would invoke undefined behavior, in C89 at least (see
Section 6.1.2 of the ANSI/ISO 9899-1990 standard; and for those
with a copy of the best book Herbert Schildt ever wrote, see
pages 20 and 200, bullet 7).


You are absolutely right. However this came from the freeBSD
organization, I just produced an implementation. In practice the
names will probably not conflict. The documentation mentions this
IIRC. You are, of course, free to change the names.

Various people out there are attempting to have these included in
the next standard. They are much more useful, and safe, than the
existing routines.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

Mar 24 '06 #12
On 2006-03-24, jaysome <ja*****@spamcop.com> wrote:
CBFalconer wrote:
santosh wrote:
ra******@gmail.com wrote:

... snip ...
while ( (*str3++ = *str1++) );
str3--;
while ( (*str3++ = *str2++) );

Code like this will crash. If you really want to concactenate
strings the standard strcat() or strncat() would probably be
sufficient.

I see no reason it should crash, assuming str3 has sufficient
room. But if you want safe overall operation, use strlcat and
strncpy (non-standard). They are available, written in pure
standard C, at:

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


Aren't function names that begin with "str" followed by another lower
case letter reserved for the implementation? If so, I think the function
names "strlcpy" and "strlcat" are in violation of this rule.

You could name them "str_lcpy" and "str_lcat" to get around this, but
that would invoke undefined behavior, in C89 at least (see Section
6.1.2 of the ANSI/ISO 9899-1990 standard)


How about an ANSI section number, for those of us stuck with the draft?
Mar 24 '06 #13
CBFalconer wrote:
jaysome wrote:
CBFalconer wrote:
santosh wrote:

ra******@gmail.com wrote:
... snip ...
> while ( (*str3++ = *str1++) );
> str3--;
> while ( (*str3++ = *str2++) );

Code like this will crash. If you really want to concactenate
strings the standard strcat() or strncat() would probably be
sufficient.

I see no reason it should crash, assuming str3 has sufficient
room. But if you want safe overall operation, use strlcat and
strncpy (non-standard). They are available, written in pure
standard C, at:

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


This should end in "strlcpy.zip" -----------^^^^^^^^^^^
Aren't function names that begin with "str" followed by another
lower case letter reserved for the implementation? If so, I think
the function names "strlcpy" and "strlcat" are in violation of
this rule.

You could name them "str_lcpy" and "str_lcat" to get around this,
but that would invoke undefined behavior, in C89 at least (see
Section 6.1.2 of the ANSI/ISO 9899-1990 standard; and for those
with a copy of the best book Herbert Schildt ever wrote, see
pages 20 and 200, bullet 7).

You are absolutely right. However this came from the freeBSD
organization, I just produced an implementation. In practice the
names will probably not conflict. The documentation mentions this
IIRC. You are, of course, free to change the names.


I'd go so far as to say that the names will *never* conflict. Even in
the time frame between when the C89 standard was drafted and when it was
approved, there was no good reason to restrict identifier name
unambiguity to just six characters. If there was such a reason, I'd love
to hear the rationale.
Various people out there are attempting to have these included in
the next standard. They are much more useful, and safe, than the
existing routines.


I agree. I've started to use your code in some of my projects and have
seen first-hand how it makes things so much easier.

Thanks
--
jay
Mar 24 '06 #14
jaysome <ja*****@spamcop.com> writes:
CBFalconer wrote:
santosh wrote:
ra******@gmail.com wrote:
... snip ...
while ( (*str3++ = *str1++) );
str3--;
while ( (*str3++ = *str2++) );

Code like this will crash. If you really want to concactenate
strings the standard strcat() or strncat() would probably be
sufficient.

I see no reason it should crash, assuming str3 has sufficient
room. But if you want safe overall operation, use strlcat and
strncpy (non-standard). They are available, written in pure
standard C, at:
<http://cbfalconer.home.att.net/download/strlcat.zip>


(Correction: <http://cbfalconer.home.att.net/download/strlcpy.zip>.)
Aren't function names that begin with "str" followed by another lower
case letter reserved for the implementation? If so, I think the
function names "strlcpy" and "strlcat" are in violation of this rule.
Yes, as acknowledged on the index page:

My implementation of the BSD standard routines strlcpy and
strlcat. NOTE: the names are illegal in standard C, and should
have a prefix added for general use. You don't need to do this if
you are very sure your system doesn't implement them.

But in BSD, I believe the functions (or equivalent functions with the
same names) are part of the implementation. (I'm actually not sure
what that implies about the identifiers being reserved.)
You could name them "str_lcpy" and "str_lcat" to get around this, but
that would invoke undefined behavior, in C89 at least (see Section
6.1.2 of the ANSI/ISO 9899-1990 standard; and for those with a copy of
the best book Herbert Schildt ever wrote, see pages 20 and 200, bullet
7).


Referring to the permission to limit external identifiers to 6
significant characters. C99 expanded the limit to 31 characters.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 24 '06 #15
Jordan Abel wrote:
On 2006-03-24, jaysome <ja*****@spamcop.com> wrote:
CBFalconer wrote:
santosh wrote:
ra******@gmail.com wrote:
... snip ...
> while ( (*str3++ = *str1++) );
> str3--;
> while ( (*str3++ = *str2++) );

Code like this will crash. If you really want to concactenate
strings the standard strcat() or strncat() would probably be
sufficient.
I see no reason it should crash, assuming str3 has sufficient
room. But if you want safe overall operation, use strlcat and
strncpy (non-standard). They are available, written in pure
standard C, at:

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


Aren't function names that begin with "str" followed by another lower
case letter reserved for the implementation? If so, I think the function
names "strlcpy" and "strlcat" are in violation of this rule.

You could name them "str_lcpy" and "str_lcat" to get around this, but
that would invoke undefined behavior, in C89 at least (see Section
6.1.2 of the ANSI/ISO 9899-1990 standard)

How about an ANSI section number, for those of us stuck with the draft?


Should be:

References: ANSI Sec. 3.1.2, Sec. 3.9.1; ISO Sec. 6.1.2,
Sec. 6.9.1; Rationale Sec. 3.1.2; H&S Sec. 2.5 pp. 22-3.

if the C FAQ is correct.

--
jay
Mar 24 '06 #16
On 2006-03-24, Keith Thompson <ks***@mib.org> wrote:
jaysome <ja*****@spamcop.com> writes:
Aren't function names that begin with "str" followed by another lower
case letter reserved for the implementation? If so, I think the
function names "strlcpy" and "strlcat" are in violation of this rule.
Yes, as acknowledged on the index page:

My implementation of the BSD standard routines strlcpy and
strlcat. NOTE: the names are illegal in standard C, and should
have a prefix added for general use. You don't need to do this if
you are very sure your system doesn't implement them.

But in BSD, I believe the functions (or equivalent functions with the
same names) are part of the implementation.


Indeed they are. Although (reserved namespace or not) they disappear
in strictly compliant mode, the same as more glaringly non-standard
functions like funopen(). So if you provide your own copies, the roof
won't actually fall in, even though it's allowed to. (You can also use
platform-specific tests to select the builtin versions, etc., etc.,
all OT.)
(I'm actually not sure what that implies about the identifiers
being reserved.)


Isn't the point of reserving the identifiers to allow such functions
to be added, both as extensions and ultimately to the standard?

--
- David A. Holland
(the above address works if unscrambled but isn't checked often)
Mar 24 '06 #17
David Holland <dh******@reverse-this--edu.harvard.fas> writes:
On 2006-03-24, Keith Thompson <ks***@mib.org> wrote:
> jaysome <ja*****@spamcop.com> writes:
>> Aren't function names that begin with "str" followed by another lower
>> case letter reserved for the implementation? If so, I think the
>> function names "strlcpy" and "strlcat" are in violation of this rule.

>
> Yes, as acknowledged on the index page:
>
> My implementation of the BSD standard routines strlcpy and
> strlcat. NOTE: the names are illegal in standard C, and should
> have a prefix added for general use. You don't need to do this if
> you are very sure your system doesn't implement them.
>
> But in BSD, I believe the functions (or equivalent functions with the
> same names) are part of the implementation.


Indeed they are. Although (reserved namespace or not) they disappear
in strictly compliant mode, the same as more glaringly non-standard
functions like funopen(). So if you provide your own copies, the roof
won't actually fall in, even though it's allowed to. (You can also use
platform-specific tests to select the builtin versions, etc., etc.,
all OT.)
> (I'm actually not sure what that implies about the identifiers
> being reserved.)


Isn't the point of reserving the identifiers to allow such functions
to be added, both as extensions and ultimately to the standard?


I suppose so.

A *program* can't declare its own strlcat() function (with external
linkage) without risking the wrath of the nasal demons. I wasn't sure
whether an *implementation* can legally declare such a function but I
think it can. C99 4p6 says:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

with a footnote:

This implies that a conforming implementation reserves no
identifiers other than those explicitly reserved in this
International Standard.

Since no strictly conforming program can use strlcat(), an
implementation can legally provide it as an extension.

An implementation *cannot* legally provide an external function
called, for example, foo(), unless it can guarantee that it won't
affect any program that uses that identifier itself.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 25 '06 #18
[On extensions in general, with strlcat as an example]

In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> wrote:
... C99 4p6 says:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

with a footnote:

This implies that a conforming implementation reserves no
identifiers other than those explicitly reserved in this
International Standard.

Since no strictly conforming program can use strlcat(), an
implementation can legally provide it as an extension.


Indeed -- and then a not-strictly-conforming program can use it.

The biggest danger is that, by doing so, the not-strictly-conforming
program may fail to port to a future Standard C ("C08", perhaps),
if the authors of that future standard choose to include a strlcat()
function that is *different* from the one provided by the implementation
in question.

As an implementor (a role I take on now and then), I attempt to
write functions that might be taken up by a future standard.
Sometimes I succeed (snprintf()) and sometimes I fail (funopen()),
and sometimes they change the parameters on me.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40į39.22'N, 111į50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Mar 25 '06 #19
Chris Torek wrote:
[On extensions in general, with strlcat as an example]

In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> wrote:
... C99 4p6 says:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

with a footnote:

This implies that a conforming implementation reserves no
identifiers other than those explicitly reserved in this
International Standard.

Since no strictly conforming program can use strlcat(), an
implementation can legally provide it as an extension.

Indeed -- and then a not-strictly-conforming program can use it.

The biggest danger is that, by doing so, the not-strictly-conforming
program may fail to port to a future Standard C ("C08", perhaps),
if the authors of that future standard choose to include a strlcat()
function that is *different* from the one provided by the implementation
in question.


So in other words, an implementation is allowed to define their own
str[a-z]+ identifier, and that's conforming to the standard. But by
doing so, they run the risk of potential problems when a future version
of the standard decides to introduce that same identifier?

If so, why is an identifier like str[a-z]+ not reserved for: just the
standard and not the implementation? After all, aren't identifiers like
_strlcat() reserved for the implementation and not the standard (and
therefore an implementation should use _strlcat() instead of strlcat())?

I'd think that the standard wouldn't choose an arbitrary name like
strlcat(), but rather base it on its functionality in one or more
existing implementations. That would certainly reduce the danger. It's
the more esoteric brands of str[a-z]* that may cause a problem for a
particular implementation, I guess.

--
jay
Mar 25 '06 #20
On 2006-03-25, jaysome <ja*****@spamcop.com> wrote:
Chris Torek wrote:
[On extensions in general, with strlcat as an example]

In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> wrote:
... C99 4p6 says:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

with a footnote:

This implies that a conforming implementation reserves no
identifiers other than those explicitly reserved in this
International Standard.

Since no strictly conforming program can use strlcat(), an
implementation can legally provide it as an extension.

Indeed -- and then a not-strictly-conforming program can use it.

The biggest danger is that, by doing so, the not-strictly-conforming
program may fail to port to a future Standard C ("C08", perhaps),
if the authors of that future standard choose to include a strlcat()
function that is *different* from the one provided by the implementation
in question.


So in other words, an implementation is allowed to define their own
str[a-z]+ identifier, and that's conforming to the standard. But by
doing so, they run the risk of potential problems when a future version
of the standard decides to introduce that same identifier?

If so, why is an identifier like str[a-z]+ not reserved for: just the
standard and not the implementation? After all, aren't identifiers like
_strlcat() reserved for the implementation and not the standard (and
therefore an implementation should use _strlcat() instead of strlcat())?

I'd think that the standard wouldn't choose an arbitrary name like
strlcat(), but rather base it on its functionality in one or more
existing implementations.


The problem is where existing implementations conflict, or where the
standard decides to handle some corner cases in a way that existing
implementations don't. e.g. snprintf's return value.
Mar 25 '06 #21

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by jorntk | last post: by
18 posts views Thread by Ian Stanley | last post: by
23 posts views Thread by JC | last post: by
2 posts views Thread by collinm | last post: by
24 posts views Thread by diego.arias.vel | last post: by
8 posts views Thread by ctara_shafa | last post: by
87 posts views Thread by Robert Seacord | last post: by
28 posts views Thread by Mahesh | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.