substring

[Dan Pop]

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.

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.

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

 

[Jeremy Yallop]

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 < Yes, I see what you mean.

Jeremy.

 

[Dan Pop]

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