substring

[Jupiter]

Hey,
I would like to know 2 things.
1)Is there any function (in C standard library) that extracts a
substring from a string?
2)Is there any function (in C standard library) that returns the
position of a substring in a string?

Thx a lot...

[Dan Pop]

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Dan Pop wrote:

In <sl*******************@ekoi.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Thomas Stegen wrote:
puts and printf are different because puts prints a string, while
printf explicitly takes a null terminated array.

I don't believe this is true. Consider the following text from C99
7.1.4 ("Use of library functions"):

If a function argument is described as being an array, the pointer
actually passed to the function shall have a value such that all
address computations and accesses to objects (that would be valid if
the pointer did point to the first element of such an array) are in
fact valid.

In the library section of the standard the word "array" is just a
convenient shorthand to denote array-like objects (including the
object returned from malloc(), for example).
The word "array" being defined by the standard, cannot be interpreted in
any other way when used in the standard.

I'm not sure why you say that. The section that I quoted clearly
states that "array" has a broader sense when used in the library
section.

I don't see any broader sense in your quote. The restrictions about
address computations are exactly the same as those defined in the
paragraph dealing with pointer arithmetic.

You can't draw any
conclusions from the fact that the description of fprintf() uses the
word "array" to describe the pointer-to-string passed as argument and
the description of puts() doesn't.

Of course you can. If you ignore the definitions of the terms used by
the standard in a purely arbitrary way (i.e. according to your own
preconceptions about the language), the standard becomes a useless
document.

There's nothing arbitrary about making use of the explicit exception
given in the introduction to the library section of the standard
(quoted above). The word "array" is used in the library section for a
data pointer on which certain operations are valid.

Precisely my point!
Here's another example:

size_t fread(void * restrict ptr,
size_t size, size_t nmemb,
FILE * restrict stream);

The fread function reads, into the array pointed to by ptr [...]

Now, the following is perfectly valid, although `a' is not an array.

int a;
fread(&a, sizeof a, 1, fp);
Every scalar can be considered as either an array of 1 of its type, or as
an array of sizeof(scalar) unsigned characters. This is explained in
other parts of the standard.
Were it not for the exception quoted above such an interpretation
might be questionable. As it is, it's the only reasonable way to
interpret this aspect of the standard.

No exception is needed. The standard explains how any object can be
accessed on a byte by byte basis by treating it as an array of characters.
This is enough for your example.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Jeremy Yallop]

Dan Pop wrote:

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Dan Pop wrote:

In <sl*******************@ekoi.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Thomas Stegen wrote:
> puts and printf are different because puts prints a string, while
> printf explicitly takes a null terminated array.

I don't believe this is true. Consider the following text from C99
7.1.4 ("Use of library functions"):

If a function argument is described as being an array, the pointer
actually passed to the function shall have a value such that all
address computations and accesses to objects (that would be valid if
the pointer did point to the first element of such an array) are in
fact valid.

In the library section of the standard the word "array" is just a
convenient shorthand to denote array-like objects (including the
object returned from malloc(), for example).

The word "array" being defined by the standard, cannot be interpreted in
any other way when used in the standard.
I'm not sure why you say that. The section that I quoted clearly
states that "array" has a broader sense when used in the library
section.

I don't see any broader sense in your quote. The restrictions about
address computations are exactly the same as those defined in the
paragraph dealing with pointer arithmetic.

Perhaps, but I was responding to the claim that:

puts and printf are different because puts prints a string, while
printf explicitly takes a null terminated array.

A null terminated "array" in the library section is no different from
a string. In particular, the address computations that can be
performed on each are precisely the same.
Every scalar can be considered as either an array of 1 of its type, or as
an array of sizeof(scalar) unsigned characters. This is explained in
other parts of the standard.

True. The guarantee is slightly stronger, I think: all the character
types can be used to access any object.

Were it not for the exception quoted above such an interpretation
might be questionable. As it is, it's the only reasonable way to
interpret this aspect of the standard.

No exception is needed.

Well, why is it there, then? I agree that the guarantees elsewhere in
the standard can be taken as sufficient to allow the current meaning,
but I don't think that they're unambiguous enough.

Jeremy.

[Thomas Stegen]

Jeremy Yallop wrote:

puts and printf are different because puts prints a string, while
printf explicitly takes a null terminated array.

A null terminated "array" in the library section is no different from
a string. In particular, the address computations that can be
performed on each are precisely the same.

The library section defines a string as:

"7.1.1 Definitions of terms
1 A string is a contiguous sequence of characters terminated by and
including the first null character. [...] The length of a string is
the number of bytes preceding the null character and the value of a
string is the sequence of the values of the contained characters, in
order."

Seems to go to great lengths to avoid the term array i think.
Furthermore the descriptions of functions are very careful
where the term string is used and where the term array is used.

Not that the outcome of this discussion will have much effect
on my coding style ;)

--
Thomas.

[Jeremy Yallop]

Thomas Stegen wrote:

Jeremy Yallop wrote:

puts and printf are different because puts prints a string, while
printf explicitly takes a null terminated array.

A null terminated "array" in the library section is no different from
a string. In particular, the address computations that can be
performed on each are precisely the same.

The library section defines a string as:

"7.1.1 Definitions of terms
1 A string is a contiguous sequence of characters terminated by and
including the first null character. [...] The length of a string is
the number of bytes preceding the null character and the value of a
string is the sequence of the values of the contained characters, in
order."

Seems to go to great lengths to avoid the term array i think.
Furthermore the descriptions of functions are very careful
where the term string is used and where the term array is used.

It seems to me that "string" is used wherever the "array" argument is
null-terminated. This is entirely in keeping with the way these terms
are used elsewhere in the standard: "array" denotes the properties of
the object; "string" describes the value that the object has when
accessed as a sequence of char.

Consequently, the description for [f]printf() uses "array" rather than
"string" (in the 's' specifier section) because the argument is not
necessarily null-terminated. I don't think there's any other
significant difference between "string" and "array" in the library
section. "Array" tends to be used for output parameters for obvious
reasons.

For example:

size_t strxfrm(char * restrict s1,
const char * restrict s2,
size_t n);

The strxfrm function transforms the string pointed to by s2 and
places the resulting string into the array pointed to by s1.

Nobody can seriously claim that this description means that `s1' must
be an actual array whereas `s2' may be split across two or more
objects.

Jeremy.

[Dan Pop]

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Perhaps, but I was responding to the claim that:

puts and printf are different because puts prints a string, while
printf explicitly takes a null terminated array.

A null terminated "array" in the library section is no different from
a string. In particular, the address computations that can be
performed on each are precisely the same.

This is the root of your misunderstanding. The definition of array you
have quoted yourself *explicitly* requires pointer arithmetic to work
inside the array.

The definition of string contains NO such requirement:

1 A string is a contiguous sequence of characters terminated by
and including the first null character. The term multibyte
string is sometimes used instead to emphasize special processing
given to multibyte characters contained in the string or to
avoid confusion with a wide string. A pointer to a string is a
pointer to its initial (lowest addressed) character. The length
of a string is the number of bytes preceding the null character
and the value of a string is the sequence of the values of the
contained characters, in order.

A direct consequence of this anomaly is that NO function expecting a
string parameter that is not explicitly required to be contained in an
array, cannot be *portably* implemented in C, because a C implementation
would necessarily rely on pointer arithmetic working inside the string.
But the definition of string quoted above provide no such guarantee.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Dan Pop wrote:

In <sl*******************@ekoi.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Dan Pop wrote:
An implementation doing array bounds checking *can* detect that the end
of the array has been reached without encountering any null character.
At this point, the implementation is free to do anything it wants,
including making demons fly out of your nose.

I find this a bit upsetting, if true. This means that we can have two
pointers that compare equal, one of which is known to point to a valid
object, and yet dereferencing the other has undefined behaviour.

Yup, C99 *explicitly* mentions this possibility:

It seems that you're right. It is pretty counterintuitive (if you
have the wrong intuitions, I suppose).

It's not that counterintuitive to people familiar with segmented memory
systems. Imagine what happens if s1 is allocated at the end of a segment
and s2 at the beginning of another segment and there is one byte of
overlap (the first byte of s2) between the two segments...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Ben Pfaff]

Da*****@cern.ch (Dan Pop) writes:

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Dan Pop wrote:

In <sl*******************@ekoi.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Dan Pop wrote:
> An implementation doing array bounds checking *can* detect that the end
> of the array has been reached without encountering any null character.
> At this point, the implementation is free to do anything it wants,
> including making demons fly out of your nose.

I find this a bit upsetting, if true. This means that we can have two
pointers that compare equal, one of which is known to point to a valid
object, and yet dereferencing the other has undefined behaviour.

Yup, C99 *explicitly* mentions this possibility:

It seems that you're right. It is pretty counterintuitive (if you
have the wrong intuitions, I suppose).

It's not that counterintuitive to people familiar with segmented memory
systems. Imagine what happens if s1 is allocated at the end of a segment
and s2 at the beginning of another segment and there is one byte of
overlap (the first byte of s2) between the two segments...

It's unclear to me why, if it can't make inter-segment pointer
arithmetic work properly, a compiler would go to the trouble of
ensuring that inter-segment pointer comparisons work properly.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Dan Pop]

In <87************@pfaff.stanford.edu> Ben Pfaff <bl*@cs.stanford.edu> writes:

Da*****@cern.ch (Dan Pop) writes:

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

>Dan Pop wrote:
>> In <sl*******************@ekoi.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:
>>
>>>Dan Pop wrote:
>>>> An implementation doing array bounds checking *can* detect that the end
>>>> of the array has been reached without encountering any null character.
>>>> At this point, the implementation is free to do anything it wants,
>>>> including making demons fly out of your nose.
>>>
>>>I find this a bit upsetting, if true. This means that we can have two
>>>pointers that compare equal, one of which is known to point to a valid
>>>object, and yet dereferencing the other has undefined behaviour.
>>
>> Yup, C99 *explicitly* mentions this possibility:
>
>It seems that you're right. It is pretty counterintuitive (if you
>have the wrong intuitions, I suppose).

It's not that counterintuitive to people familiar with segmented memory
systems. Imagine what happens if s1 is allocated at the end of a segment
and s2 at the beginning of another segment and there is one byte of
overlap (the first byte of s2) between the two segments...

It's unclear to me why, if it can't make inter-segment pointer
arithmetic work properly, a compiler would go to the trouble of
ensuring that inter-segment pointer comparisons work properly.

Maybe because the compiler has nothing to do for that: the underlying
hardware may implement address comparisons this way.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Jeremy Yallop]

Dan Pop wrote:

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Perhaps, but I was responding to the claim that:

puts and printf are different because puts prints a string, while
printf explicitly takes a null terminated array.

A null terminated "array" in the library section is no different from
a string. In particular, the address computations that can be
performed on each are precisely the same.
This is the root of your misunderstanding.

I prefer "This is the point under discusssion".
The definition of array you have quoted yourself *explicitly*
requires pointer arithmetic to work inside the array.

The definition of string contains NO such requirement:

You may be right, although that would make "contiguous" a rather
unhelpful word to describe the bytes that contain a string. If two
pointers into a string cannot be compared for equality and if no valid
pointer arithmetic on one will yield a pointer equivalent to the other
then the bytes aren't contiguous in any useful sense. Just to be
clear, though, are you claiming that in the following:

#include <string.h>
char *strcpy(char * restrict s1, const char * restrict s2);

The strcpy function copies the string pointed to by s2 (including
the terminating null character) into the array pointed to by s1.

`s1' *must* point to a single object, whereas `s2' may point to two
adjacent objects spanned by a single string?

A direct consequence of this anomaly is that NO function expecting a

string parameter that is not explicitly required to be contained in an
array, cannot be *portably* implemented in C, because a C implementation
would necessarily rely on pointer arithmetic working inside the string.
But the definition of string quoted above provide no such guarantee.

Again, you may well be right according to the letter of the standard
but that this sort of absurdity is a consequence shows (to me) that
this is not its intent.

Jeremy.

[Jeremy Yallop]

Dan Pop wrote:

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Perhaps, but I was responding to the claim that:

puts and printf are different because puts prints a string, while
printf explicitly takes a null terminated array.

A null terminated "array" in the library section is no different from
a string. In particular, the address computations that can be
performed on each are precisely the same.
This is the root of your misunderstanding.

I prefer "This is the point under discussion".
The definition of array you have quoted yourself *explicitly*
requires pointer arithmetic to work inside the array.

The definition of string contains NO such requirement:

You may be right, although that would make "contiguous" a rather
unhelpful word to describe the bytes that contain a string. If two
pointers into a string cannot be compared for equality and if no valid
pointer arithmetic on one will yield a pointer equivalent to the other
then the bytes aren't contiguous in any useful sense. Just to be
clear, though, are you claiming that in the following:

#include <string.h>
char *strcpy(char * restrict s1, const char * restrict s2);

The strcpy function copies the string pointed to by s2 (including
the terminating null character) into the array pointed to by s1.

`s1' *must* point to a single object, whereas `s2' may point to two
adjacent objects spanned by a single string?

A direct consequence of this anomaly is that NO function expecting a

string parameter that is not explicitly required to be contained in an
array, cannot be *portably* implemented in C, because a C implementation
would necessarily rely on pointer arithmetic working inside the string.
But the definition of string quoted above provide no such guarantee.

Again, you may well be right according to the letter of the standard
but that this sort of absurdity is a consequence shows (to me) that
this is not its intent.

Jeremy.

[Dan Pop]

In <sl*******************@embo.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Dan Pop wrote:

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Perhaps, but I was responding to the claim that:

puts and printf are different because puts prints a string, while
printf explicitly takes a null terminated array.

A null terminated "array" in the library section is no different from
a string. In particular, the address computations that can be
performed on each are precisely the same.
This is the root of your misunderstanding.

I prefer "This is the point under discussion".

I've made that point far too often in this discussion and no one could
provide a quote from the standard proving me wrong. By that time, you
should have gotten it, hence my actual wording.

The definition of array you have quoted yourself *explicitly*
requires pointer arithmetic to work inside the array.

The definition of string contains NO such requirement:

You may be right, although that would make "contiguous" a rather
unhelpful word to describe the bytes that contain a string.

It's helpful enough in deciding whether s1 (in your previous example)
can be used where a string is expected or not.
If two
pointers into a string cannot be compared for equality and if no valid
pointer arithmetic on one will yield a pointer equivalent to the other
then the bytes aren't contiguous in any useful sense. Just to be
clear, though, are you claiming that in the following:

#include <string.h>
char *strcpy(char * restrict s1, const char * restrict s2);

The strcpy function copies the string pointed to by s2 (including
the terminating null character) into the array pointed to by s1.

`s1' *must* point to a single object, whereas `s2' may point to two
adjacent objects spanned by a single string?

Precisely. This is what the standard says, with no room for an alternate
interpretation. All the relevant quotes already provided in this thread.

A direct consequence of this anomaly is that NO function expecting a

string parameter that is not explicitly required to be contained in an
array, cannot be *portably* implemented in C, because a C implementation
would necessarily rely on pointer arithmetic working inside the string.
But the definition of string quoted above provide no such guarantee.

Again, you may well be right according to the letter of the standard
but that this sort of absurdity is a consequence shows (to me) that
this is not its intent.

I agree that the actual standard wording is sloppy and that it *probably*
does not reflect the intent. But this doesn't make any shred of a
difference: until fixed, it is the current wording that rules what is
allowed and what is not allowed.

OTOH, there might be a non-obvious reason the standard is worded this way.
When I posted this question to comp.std.c (about half a year ago), nobody
provided any useful insights.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Jeremy Yallop]

Dan Pop wrote:

I agree that the actual standard wording is sloppy and that it *probably*
does not reflect the intent. But this doesn't make any shred of a
difference: until fixed, it is the current wording that rules what is
allowed and what is not allowed.
Perhaps a defect report is called for. How would you suggest
resolving the inconsistency? Fixing the definition of string to
preclude spanning non-overlapping objects seems like the obvious
solution.
OTOH, there might be a non-obvious reason the standard is worded this way.
When I posted this question to comp.std.c (about half a year ago), nobody
provided any useful insights.

In <news:ag**********@sunnews.cern.ch>? Yes, I see what you mean.

Jeremy.

[Dan Pop]

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

Dan Pop wrote:

I agree that the actual standard wording is sloppy and that it *probably*
does not reflect the intent. But this doesn't make any shred of a
difference: until fixed, it is the current wording that rules what is
allowed and what is not allowed.

Perhaps a defect report is called for. How would you suggest
resolving the inconsistency? Fixing the definition of string to
preclude spanning non-overlapping objects seems like the obvious
solution.

I entirely agree. I can't see any problems created by explicitly
requiring that each C string is stored inside a C object. But even then
we could discuss about the validity of:

struct { char s1[3], s2[4]; } foo = {"abc", "def"};

if (foo.s1 + sizeof foo.s1 == foo.s2) puts(foo.s1);

Is the fact that the string is entirely contained in the foo object
enough? In my opinion it should be, but people like JW might disagree...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de