Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #101407 > unrolled thread

Correct way of doing string manipulation functions

Back to article view | Back to comp.lang.c

Contents

  Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-10 15:43 -0800
    Re: Correct way of doing string manipulation functions "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-10 19:36 -0500
      Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-11 03:41 +0000
        Re: Correct way of doing string manipulation functions James Kuyper <jameskuyper@verizon.net> - 2017-01-11 07:19 -0500
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:36 -0800
    Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 16:41 -0800
      Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 16:54 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:38 -0800
          Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-11 18:24 -0800
      Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-11 03:38 +0000
        Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 20:02 -0800
          Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 20:28 -0800
          Re: Correct way of doing string manipulation functions Ian Collins <ian-news@hotmail.com> - 2017-01-11 18:19 +1300
            Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-11 02:40 -0800
        Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 20:18 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:37 -0800
        Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-11 18:23 -0800
    Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-11 01:12 +0000
      Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-11 11:59 +0000
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:39 -0800
    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-10 17:55 -0800
      Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 18:21 -0800
      Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-11 03:21 +0000
        Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-11 07:33 -0800
          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-11 07:43 -0800
          Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-11 15:50 +0000
            Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-11 08:07 -0800
              Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:46 -0800
                Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 03:04 -0800
                  Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 03:37 -0800
                    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 05:47 -0800
                      Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 06:14 -0800
                        Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 06:34 -0800
                        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 07:38 -0800
                          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 07:59 -0800
              Re: Correct way of doing string manipulation functions Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 22:24 -0800
                Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-15 03:30 -0800
                  Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 03:52 -0800
                    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-15 04:23 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:42 -0800
    Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-10 19:19 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:40 -0800
    Re: Correct way of doing string manipulation functions Barry Schwarz <schwarzb@dqel.com> - 2017-01-10 20:31 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:45 -0800
    Re: Correct way of doing string manipulation functions Gareth Owen <gwowen@gmail.com> - 2017-01-11 17:20 +0000
      Re: Correct way of doing string manipulation functions "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-11 12:38 -0500
        Strings as first class citizens (Was: Correct way of doing string manipulation functions) gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-11 17:53 +0000
          Re: Strings as first class citizens (Was: Correct way of doing string manipulation functions) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-11 12:46 -0800
            Re: Strings as first class citizens (Was: Correct way of doing string manipulation functions) fir <profesor.fir@gmail.com> - 2017-01-11 14:40 -0800
            Re: Strings as first class citizens (Was: Correct way of doing string manipulation functions) Robert Wessel <robertwessel2@yahoo.com> - 2017-01-11 18:12 -0600
        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-11 09:56 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:48 -0800
    Re: Correct way of doing string manipulation functions Thiago Adams <thiago.adams@gmail.com> - 2017-01-11 12:09 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 15:00 -0800
    Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 15:11 -0800
      Re: Correct way of doing string manipulation functions "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-11 19:03 -0500
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 02:46 -0800
      Re: Correct way of doing string manipulation functions Barry Schwarz <schwarzb@dqel.com> - 2017-01-12 00:08 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 03:02 -0800
          Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 11:38 +0000
            Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-12 13:51 +0000
              Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 14:41 +0000
          Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 09:32 -0800
            Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 18:15 +0000
            Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-12 11:46 -0800
              Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 13:52 -0800
            Re: Correct way of doing string manipulation functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-12 16:50 -0800
              Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 00:59 +0000
                Re: Correct way of doing string manipulation functions raltbos@xs4all.nl (Richard Bos) - 2017-01-13 08:59 +0000
                  Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 13:07 +0000
                  Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-13 10:11 -0800
                    Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-13 18:49 +0000
                Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 08:43 -0800
                Re: Correct way of doing string manipulation functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 09:45 -0800
                  Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:17 +0000
                    Re: Correct way of doing string manipulation functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 10:30 -0800
                      Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:48 +0000
                        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 11:02 -0800
                          Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 19:15 +0000
                            Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 12:18 -0800
                      Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-13 12:14 -0800
                        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 12:49 -0800
                          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:19 -0800
                    Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 10:46 -0800
                      Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 11:55 -0800
                  Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 10:41 -0800
                    Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 10:51 -0800
                    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 12:28 -0800
                      Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:07 -0800
                        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 13:29 -0800
                          Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-13 21:45 +0000
                            Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:59 -0800
                              Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 15:08 -0800
                            Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 14:13 -0800
                          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:47 -0800
              Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 08:02 -0800
        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-12 07:50 -0800
        Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-12 08:37 -0800
          Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 09:41 -0800
      Re: Correct way of doing string manipulation functions Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 17:39 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 18:02 -0800

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#101521

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 12/01/17 11:02, Fernando D. Bozzo wrote:
>> El jueves, 12 de enero de 2017, 9:08:46 (UTC+1), Barry Schwarz
>> escribió:
>>> On Wed, 11 Jan 2017 15:11:43 -0800 (PST), "Fernando D. Bozzo"
> <snip>
>>>> for (int i = (pos + 1); i <= len; i++)
>>>> {
>>>>     text_out[i - (pos + 1)] = text_in[i];
>>>
>>> You have an aversion to strcpy??
>>>
>>
>> Ha ha ha! :) No, I have no aversion to any function at all, but
>> strcpy copies the entire string, and I just need to copy the filename
>> part of the input string. Is there a way to to this with strcpy? I
>> did not try to specify text_in[pos+1] as source string... may be you
>> refer to this. I will do a test later to see if works, and yes,
>> should be better to use a standard function that a new one
>
> No, you can't do this with strcpy,

Why not?

> memcpy(dest, src, bytes);
> dest[bytes] = '\0'; /* to null-terminate the target */

In the function in question, the bytes being copied are at the end of
the source string and therefor include a null.  By just using the right
size you can use a single memcpy call with no separate termination.

Or a call to strcpy!

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#101525

On 12/01/17 13:51, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
<snip>

>> No, you can't do this with strcpy,
>
> Why not?

Oh, it was the rightmost bytes? I missed that. Sorry.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101532

El jueves, 12 de enero de 2017, 12:02:17 (UTC+1), Fernando D. Bozzo  escribió:
[...]
> Is there a way to to this with strcpy? I did not try to specify text_in[pos+1] as source string... may be you refer to this.
> I will do a test later to see if works, and yes, should be better to use a standard function that a new one
> 


Ok, I've tested it and IT WORKS Wonderfully! :D

strcpy(text_out, &text_in[(pos + 1)]);


You did make me think that, because a string have their characters always stored in consecutively addresses, then should not be any problem in starting in the middle of that string, and in the case of needing to copy from another part of the string I suppose that I can use the other one, strncpy(), indicating the length to copy.

Wonderful, thanks.-

[toc] | [prev] | [next] | [standalone]

#101536

On 12/01/17 17:32, Fernando D. Bozzo wrote:
<snip>
>
> strcpy(text_out, &text_in[(pos + 1)]);

You may (or may not) find

strcpy(text_out, text_in + pos + 1);

to be more readable.

> You did make me think that, because a string have their characters
> always stored in consecutively addresses, then should not be any
> problem in starting in the middle of that string, and in the case of
> needing to copy from another part of the string I suppose that I can
> use the other one, strncpy(), indicating the length to copy.

Be careful with strncmp. Under some circumstances, it will not 
null-terminate the target string. Consider this code:

#include <stdio.h>
#include <string.h>

int main(void)
{
   char source[] = "abcdefgh";
   char target[5] = "1111";
   size_t i = 0;
   strncpy(target, source, 3);
   printf("%s\n", target);
   return 0;
}

which prints not "abc" but "abc1".

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101542

"Fernando D. Bozzo" <fdbozzo@gmail.com> writes:
[...]
> You did make me think that, because a string have their characters
> always stored in consecutively addresses, then should not be any
> problem in starting in the middle of that string, and in the case of
> needing to copy from another part of the string I suppose that I can
> use the other one, strncpy(), indicating the length to copy.
[...]

Be careful with strncpy().
http://the-flat-trantor-society.blogspot.com/2012/03/no-strncpy-is-not-safer-strcpy.html

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101559

El jueves, 12 de enero de 2017, 20:45:59 (UTC+1), Keith Thompson  escribió:
> Be careful with strncpy().
> http://the-flat-trantor-society.blogspot.com/2012/03/no-strncpy-is-not-safer-strcpy.html
> 


Thanks for the article!

[toc] | [prev] | [next] | [standalone]

#101566

On Thursday, January 12, 2017 at 5:32:54 PM UTC, Fernando D. Bozzo wrote:
> 
> You did make me think that, because a string have their characters
>  always stored in consecutively addresses, then should not be any 
> problem in starting in the middle of that string, and in the case 
> of needing to copy from another part of the string I suppose that 
> I can use the other one, strncpy(), indicating the length to copy.
> 
> Wonderful, thanks.-
>
As a general rule, C string should be treated as atomic. Taking
a suffix of another string and treating it as a whole string is
something to avoid, except in low level leaf functions. 

The reasons are firstly to avoid creating unaligned pointers,
secondly and relatedly to help interfacing with code written in
other languages, and thirdly because the structure of the program
can quickly become a mess if pointers point into objects, maybe
even overlapping.

[toc] | [prev] | [next] | [standalone]

#101567

On 13/01/17 00:50, Malcolm McLean wrote:
> On Thursday, January 12, 2017 at 5:32:54 PM UTC, Fernando D. Bozzo wrote:
>>
>> You did make me think that, because a string have their characters
>>  always stored in consecutively addresses, then should not be any
>> problem in starting in the middle of that string, and in the case
>> of needing to copy from another part of the string I suppose that
>> I can use the other one, strncpy(), indicating the length to copy.
>>
>> Wonderful, thanks.-
>>
> As a general rule, C string should be treated as atomic.

Whose rule? Is this another Malcolm-only rule?

> Taking
> a suffix of another string and treating it as a whole string is
> something to avoid, except in low level leaf functions.

Why? (Oh, okay, you're getting to that...)

> The reasons are firstly to avoid creating unaligned pointers,

Huh? Consider:

#include <stdio.h>

int main(void)
{
   const char hw[] = "Hello, World.";
   const char *s = hw + 7;
   printf("%s\n", s);
   return 0;
}

Would you say that s is "unaligned"? If so, what do you mean by that?

> secondly and relatedly to help interfacing with code written in
> other languages,

Which specific languages did you have in mind, and how precisely does 
substring access interfere with C's interface to these languages?

> and thirdly because the structure of the program
> can quickly become a mess if pointers point into objects, maybe
> even overlapping.

I would certainly agree that one should always take great care with 
pointers, and one should always be sure of where they point, and why, 
and for how long they should point there, but I see no reason to impose 
a blanket ban on pointers to string suffixes.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101586

Richard Heathfield <rjh@cpax.org.uk> wrote:

> On 13/01/17 00:50, Malcolm McLean wrote:
> > On Thursday, January 12, 2017 at 5:32:54 PM UTC, Fernando D. Bozzo wrote:
> >>
> >> You did make me think that, because a string have their characters
> >>  always stored in consecutively addresses, then should not be any
> >> problem in starting in the middle of that string, and in the case
> >> of needing to copy from another part of the string I suppose that
> >> I can use the other one, strncpy(), indicating the length to copy.
> >>
> >> Wonderful, thanks.-
> >>
> > As a general rule, C string should be treated as atomic.
> 
> Whose rule? Is this another Malcolm-only rule?

As a general rule, in fact, I agree with it. It's a rule with a great
many exceptions, but as a first principle, from which to depart only
when necessary, it is sound.

> > The reasons are firstly to avoid creating unaligned pointers,
> 
> Huh? Consider:
> 
> #include <stdio.h>
> 
> int main(void)
> {
>    const char hw[] = "Hello, World.";
>    const char *s = hw + 7;
>    printf("%s\n", s);
>    return 0;
> }
> 
> Would you say that s is "unaligned"? If so, what do you mean by that?

I would say the word "unaligned" is badly chosen, but I agree with
Malcolm that if you do these things without needing to, you may well
start changing s and wondering what happened to hw, or vice versa.

It's a different matter, of course, when you're explicitly dealing with
sub-strings. There's no real problem with that, because at that point
you're doing string pointer manipulation not because you want to do some
clever premature optimisation with pointers, but because you need to
manipulate strings to begin with.

> I would certainly agree that one should always take great care with 
> pointers, and one should always be sure of where they point, and why, 
> and for how long they should point there, but I see no reason to impose 
> a blanket ban on pointers to string suffixes.

Well, he did (for once) say "as a _general_ rule", not as an absolute
one. I agree that it should be a first principle, not a final one.

Richard

[toc] | [prev] | [next] | [standalone]

#101606

On 13/01/17 08:59, Richard Bos wrote:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> On 13/01/17 00:50, Malcolm McLean wrote:
>>> On Thursday, January 12, 2017 at 5:32:54 PM UTC, Fernando D. Bozzo wrote:
>>>>
>>>> You did make me think that, because a string have their characters
>>>>  always stored in consecutively addresses, then should not be any
>>>> problem in starting in the middle of that string, and in the case
>>>> of needing to copy from another part of the string I suppose that
>>>> I can use the other one, strncpy(), indicating the length to copy.
>>>>
>>>> Wonderful, thanks.-
>>>>
>>> As a general rule, C string should be treated as atomic.
>>
>> Whose rule? Is this another Malcolm-only rule?
>
> As a general rule, in fact, I agree with it. It's a rule with a great
> many exceptions, but as a first principle, from which to depart only
> when necessary, it is sound.

Oh dear.

Oh dear oh dear oh dear.

Oh deary deary me.

Okay, let's look at it.

>>> The reasons are firstly to avoid creating unaligned pointers,
>>
>> Huh? Consider:
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>>    const char hw[] = "Hello, World.";
>>    const char *s = hw + 7;
>>    printf("%s\n", s);
>>    return 0;
>> }
>>
>> Would you say that s is "unaligned"? If so, what do you mean by that?
>
> I would say the word "unaligned" is badly chosen, but I agree with
> Malcolm that if you do these things without needing to, you may well
> start changing s and wondering what happened to hw, or vice versa.

That's more to do with aliasing than alignment.

> It's a different matter, of course, when you're explicitly dealing with
> sub-strings. There's no real problem with that, because at that point
> you're doing string pointer manipulation not because you want to do some
> clever premature optimisation with pointers, but because you need to
> manipulate strings to begin with.

That's the first mention of optimisation I've seen. I wasn't even 
/thinking/ about optimisation. That would have been premature. I was 
thinking about substring manipulation, for the very good reason that we 
were talking about pointing at substrings. And I (perhaps incorrectly) 
assumed that was what Malcolm was talking about as well.

Maybe he would care to clarify.

>> I would certainly agree that one should always take great care with
>> pointers, and one should always be sure of where they point, and why,
>> and for how long they should point there, but I see no reason to impose
>> a blanket ban on pointers to string suffixes.
>
> Well, he did (for once) say "as a _general_ rule", not as an absolute
> one. I agree that it should be a first principle, not a final one.

I don't think that /avoiding/ substring-pointing should even be a first 
principle, let alone a final principle. If Malcolm had said "mind how 
you go with pointers, as they can be a bit pointy", I'd have had no 
problem with it.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101636

raltbos@xs4all.nl (Richard Bos) writes:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>> On 13/01/17 00:50, Malcolm McLean wrote:
[...]
>> > The reasons are firstly to avoid creating unaligned pointers,
>> 
>> Huh? Consider:
>> 
>> #include <stdio.h>
>> 
>> int main(void)
>> {
>>    const char hw[] = "Hello, World.";
>>    const char *s = hw + 7;
>>    printf("%s\n", s);
>>    return 0;
>> }
>> 
>> Would you say that s is "unaligned"? If so, what do you mean by that?
>
> I would say the word "unaligned" is badly chosen, but I agree with
> Malcolm that if you do these things without needing to, you may well
> start changing s and wondering what happened to hw, or vice versa.

If you do *anything* without needing to, you may run into problems.

Since hw is defined as const, and s is a pointer to const char, there's
no need to be concerned about accidentally modifying anything.

I think Malcolms's concern is that the base address of the array object
hw is likely to be on a 4-byte or 8-byte boundary, and the address of
the character pointed to by s is not.  But since s is a byte pointer, it
is as aligned as it needs to be.  Malcolm's concern about "unaligned
pointers" is unfounded.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101648

On 13/01/2017 18:11, Keith Thompson wrote:
> raltbos@xs4all.nl (Richard Bos) writes:
>> Richard Heathfield <rjh@cpax.org.uk> wrote:
>>> On 13/01/17 00:50, Malcolm McLean wrote:
> [...]
>>>> The reasons are firstly to avoid creating unaligned pointers,
>>>
>>> Huh? Consider:
>>>
>>> #include <stdio.h>
>>>
>>> int main(void)
>>> {
>>>    const char hw[] = "Hello, World.";
>>>    const char *s = hw + 7;
>>>    printf("%s\n", s);
>>>    return 0;
>>> }
>>>
>>> Would you say that s is "unaligned"? If so, what do you mean by that?
>>
>> I would say the word "unaligned" is badly chosen, but I agree with
>> Malcolm that if you do these things without needing to, you may well
>> start changing s and wondering what happened to hw, or vice versa.
>
> If you do *anything* without needing to, you may run into problems.
>
> Since hw is defined as const, and s is a pointer to const char, there's
> no need to be concerned about accidentally modifying anything.
>
> I think Malcolms's concern is that the base address of the array object
> hw is likely to be on a 4-byte or 8-byte boundary, and the address of
> the character pointed to by s is not.  But since s is a byte pointer, it
> is as aligned as it needs to be.  Malcolm's concern about "unaligned
> pointers" is unfounded.

I have a library that usually allocates strings starting at a 16-byte 
boundary, and usually over-allocates so that the whole string resides in 
a block size which is a multiple of 16.

Then many things can be done very efficiently (especially if you also 
arrange for spare data past the end of the string is always zeros).

However, that doesn't apply to substrings, which can start at any 
byte-offset, and end abruptly at any odd address, so have to be treated 
differently, and less efficiently.

I don't think concern about such matters is unfounded.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101616

On Thursday, January 12, 2017 at 7:00:08 PM UTC-6, Richard Heathfield wrote:
> Would you say that s is "unaligned"? If so, what do you mean by that?

Sequences of characters which are manipulated as a group (i.e. "strings"
in the language-agnostic sense) can be represented in a variety of ways.
Before the PDP-11, it was common to store two or more characters into each
machine word.  Strings stored in this way were often awkward to work with,
but were more compact than those stored using one character per machine
word.  The PDP-11 made it possible for code to achieve the storage
efficiency advantages of having two or more characters per machine word
while retaining the convenience of having individually-addressable
characters.

For some operations, using separately-addressable characters is more
time-efficient than packing multiple characters per word, but for
others the reverse is true.  When C was invented, space efficiency was
often more important than time efficiency, and having strings stored as
bytes without any regard for word boundaries allowed better space
efficiency than either of the previous means of storage (one character
per word, or a group of characters per word).  If, however, a program
spends more time hashing or comparing strings and copying them in their
entirety than it spends on operations that require manipulating individual
characters, it may be much faster (sometimes more than 4x) to have such
operations treat e.g. a 50- character string as 13 four-chararacter words,
rather than as 50 individual characters.

[toc] | [prev] | [next] | [standalone]

#101625

On Friday, January 13, 2017 at 1:00:08 AM UTC, Richard Heathfield wrote:
> On 13/01/17 00:50, Malcolm McLean wrote:
> >
> > As a general rule, C string should be treated as atomic.
> 
> Whose rule? Is this another Malcolm-only rule?
> 
> > Taking
> > a suffix of another string and treating it as a whole string is
> > something to avoid, except in low level leaf functions.
> 
> Why? (Oh, okay, you're getting to that...)
> 
> > The reasons are firstly to avoid creating unaligned pointers,
> 
> Huh? Consider:
> 
> #include <stdio.h>
> 
> int main(void)
> {
>    const char hw[] = "Hello, World.";
>    const char *s = hw + 7;
>    printf("%s\n", s);
>    return 0;
> }
> 
> Would you say that s is "unaligned"? If so, what do you mean by that?
>

hw will almost certainly have the last three bits of the pointer clear.
s has them set. It is unaligned, on many architectures we cannot read
32 or 64 bits from it. 
>
> > secondly and relatedly to help interfacing with code written in
> > other languages,
> 
> Which specific languages did you have in mind, and how precisely does 
> substring access interfere with C's interface to these languages?
>
Anything which implements its string copy function as a tight loop 
reading 4 or 8 bytes at a time.  Or anything which does runtime
checks for valid UTF-8. 
Or anything which garbage collects by assuming that a pointer to the
allocated block must be live.
>
> > and thirdly because the structure of the program
> > can quickly become a mess if pointers point into objects, maybe
> > even overlapping.
> 
> I would certainly agree that one should always take great care with 
> pointers, and one should always be sure of where they point, and why, 
> and for how long they should point there, but I see no reason to impose 
> a blanket ban on pointers to string suffixes.
> 
No, it's not a blanket ban. It's a coding practice which tends to lead to
problems because you have created two pointers which mean different
things but alias each other. One says "pointers" - a technical term in 
C, one says "inters", a term in undertaking. Obviously highly undesirable
that those pointers are liked by using the same memory, unless you really
are squeezed for bytes.

[toc] | [prev] | [next] | [standalone]

#101637

On 13/01/17 17:45, Malcolm McLean wrote:
> On Friday, January 13, 2017 at 1:00:08 AM UTC, Richard Heathfield wrote:
>> On 13/01/17 00:50, Malcolm McLean wrote:
>>>
>>> As a general rule, C string should be treated as atomic.
>>
>> Whose rule? Is this another Malcolm-only rule?
>>
>>> Taking
>>> a suffix of another string and treating it as a whole string is
>>> something to avoid, except in low level leaf functions.
>>
>> Why? (Oh, okay, you're getting to that...)
>>
>>> The reasons are firstly to avoid creating unaligned pointers,
>>
>> Huh? Consider:
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>>    const char hw[] = "Hello, World.";
>>    const char *s = hw + 7;
>>    printf("%s\n", s);
>>    return 0;
>> }
>>
>> Would you say that s is "unaligned"? If so, what do you mean by that?
>>
>
> hw will almost certainly have the last three bits of the pointer clear.
> s has them set. It is unaligned, on many architectures we cannot read
> 32 or 64 bits from it.

It's a char *. It's guaranteed to be addressable as a char *. Who cares 
whether we can read 32 or 64 bits from it, as long as we can read a char 
from it? (And if a char is 32 or 64 bits, which it might be and indeed 
is on some implementations, then we /will/ be able to read 32 or 64 bits 
from it.)

>>> secondly and relatedly to help interfacing with code written in
>>> other languages,
>>
>> Which specific languages did you have in mind, and how precisely does
>> substring access interfere with C's interface to these languages?
>>
> Anything which implements its string copy function as a tight loop
> reading 4 or 8 bytes at a time.  Or anything which does runtime
> checks for valid UTF-8.

If that's a problem at all, it's already a problem for strings. Why 
would it be an /extra/ problem for substrings?

> Or anything which garbage collects by assuming that a pointer to the
> allocated block must be live.

In which case you can't even call strtol, strtoul, strtod...

>>> and thirdly because the structure of the program
>>> can quickly become a mess if pointers point into objects, maybe
>>> even overlapping.
>>
>> I would certainly agree that one should always take great care with
>> pointers, and one should always be sure of where they point, and why,
>> and for how long they should point there, but I see no reason to impose
>> a blanket ban on pointers to string suffixes.
>>
> No, it's not a blanket ban.

Good.

> It's a coding practice which tends to lead to
> problems because you have created two pointers which mean different
> things but alias each other.

That only leads to problems if you allow it to lead to problems. This is 
true of many aspects of C programming.

> One says "pointers" - a technical term in
> C, one says "inters", a term in undertaking. Obviously highly undesirable
> that those pointers are liked by using the same memory, unless you really
> are squeezed for bytes.

Is that the only reason you'd point to substrings? I can think of lots 
of reasons why you'd want to point to substrings, but saving a couple of 
bytes isn't one of them.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101638

On Friday, January 13, 2017 at 6:17:56 PM UTC, Richard Heathfield wrote:
> On 13/01/17 17:45, Malcolm McLean wrote:
> 
> > Anything which implements its string copy function as a tight loop
> > reading 4 or 8 bytes at a time.  Or anything which does runtime
> > checks for valid UTF-8.
> 
> If that's a problem at all, it's already a problem for strings. Why 
> would it be an /extra/ problem for substrings?
> 
The compiler can and usually will prevent string from being created with unaligned
first addresses, on platforms where unaligned accesses are cheaper or easier to
integrate with other code. It can't do anything if you take a suffix. 

There does need to be a fix, but that fix might involve patching in some special
code, or even prohibiting the C from passing an unaligned string at all. Part
of the art of programming is to be nice to other people, by which I don't mean
old ladies (except old ladies who also happen to be programmers).

[toc] | [prev] | [next] | [standalone]

#101645

On 13/01/17 18:30, Malcolm McLean wrote:
> On Friday, January 13, 2017 at 6:17:56 PM UTC, Richard Heathfield wrote:
>> On 13/01/17 17:45, Malcolm McLean wrote:
>>
>>> Anything which implements its string copy function as a tight loop
>>> reading 4 or 8 bytes at a time.  Or anything which does runtime
>>> checks for valid UTF-8.
>>
>> If that's a problem at all, it's already a problem for strings. Why
>> would it be an /extra/ problem for substrings?
>>
> The compiler can and usually will prevent string from being created with unaligned
> first addresses, on platforms where unaligned accesses are cheaper or easier to
> integrate with other code. It can't do anything if you take a suffix.

Then you can't use strtol, strtoul, strtod. Or strchr. Or strstr. Or 
strtok. Or heaven knows what else.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101651

On Friday, January 13, 2017 at 12:48:29 PM UTC-6, Richard Heathfield wrote:
> Then you can't use strtol, strtoul, strtod. Or strchr. Or strstr. Or 
> strtok. Or heaven knows what else.

In that list, only strchr, strstr, and strtok would pose any issue, and even
those could be handled by having the compiler generate less-efficient code
when processing pointers that are returned from those functions than it would
generate when processing things it *knows* to be word-aligned.

[toc] | [prev] | [next] | [standalone]

#101652

On 13/01/17 19:02, supercat@casperkitty.com wrote:
> On Friday, January 13, 2017 at 12:48:29 PM UTC-6, Richard Heathfield wrote:
>> Then you can't use strtol, strtoul, strtod. Or strchr. Or strstr. Or
>> strtok. Or heaven knows what else.
>
> In that list, only strchr, strstr, and strtok would pose any issue, and even
> those could be handled by having the compiler generate less-efficient code
> when processing pointers that are returned from those functions than it would
> generate when processing things it *knows* to be word-aligned.

Why not strtol, for example? After all, after this call:

s = "12345zulu";

strtol(s, &t, 10);

t will be pointing into a substring of s.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#101656

On Friday, January 13, 2017 at 1:15:15 PM UTC-6, Richard Heathfield wrote:
> On 13/01/17 19:02, supercat wrote:
> > In that list, only strchr, strstr, and strtok would pose any issue, and even
> > those could be handled by having the compiler generate less-efficient code
> > when processing pointers that are returned from those functions than it would
> > generate when processing things it *knows* to be word-aligned.
> 
> Why not strtol, for example? After all, after this call:
> 
> s = "12345zulu";
> 
> strtol(s, &t, 10);
> 
> t will be pointing into a substring of s.

Sorry--I'd forgotten about that aspect of those functions, since code which
doesn't care about the address of the first invalid character can simply
pass NULL.  If the address of a char* is passed and that char* is used for
some purpose beyond checking that the char* points to a zero byte, then
those functions may impose the same issue as the others, i.e. the need for
the implementation to cancel some optimizations it would otherwise have been
able to perform.

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web