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 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#101655

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 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.

Any string copy function that requires the string to be strictly aligned
does not work correctly on C strings.

>> >                                  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.

If I define an array object containing a string:

    const char arr[] = "hello";

then there's no guarantee that arr is strictly aligned.  It likely is,
but nothing in C requires it, and if you're writing code that assumes it
is, your code is broken.

> 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).

Suppose you have a string "foobar.txt", and you want just the "txt"
suffix as a string:

    const char *filename = "foobar.txt";
    const char *suffix = filename + 7; // simplified for this example

`filename` *might* be strictly aligned.  If it is, `suffix` certainly
is not.

What's your solution?  Allocate another strictly aligned array
object, and copy the suffix to it -- using a copy that has to deal
with unaligned memory anyway?  In the name of efficiency?

If you need a string to be aligned for some reason, sure, you'll
have to do that kind of thing.  But most of the time, you don't,
and imposing a general rule to allow for the rare cases where you
might need extra alignment is nonsense.

-- 
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]

#101659

On Friday, January 13, 2017 at 2:13:01 PM UTC-6, Keith Thompson wrote:
> Any string copy function that requires the string to be strictly aligned
> does not work correctly on C strings.

True, but a conforming implementation may replace calls to strcpy with
calls to an __aligned_strcpy function which imposes stronger requirements
than strcpy in cases where it can be certain that the pointers in
question will satisfy that function's requirements.  Further, a conforming
implementation's may process some functions in a way that executes much more
efficiently when given an aligned pointer than an unaligned one, even if
both would work.

> If I define an array object containing a string:
> 
>     const char arr[] = "hello";
> 
> then there's no guarantee that arr is strictly aligned.  It likely is,
> but nothing in C requires it, and if you're writing code that assumes it
> is, your code is broken.

True, but an implementation which ensures that the strings are word-aligned
would be able to take advantage of that in its own generated code, and an
implementation where operations on aligned strings are much faster than on
unaligned could achieve a speed boost by having the compiler ensure that
strings were aligned when practical.

> > 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).
> 
> Suppose you have a string "foobar.txt", and you want just the "txt"
> suffix as a string:
> 
>     const char *filename = "foobar.txt";
>     const char *suffix = filename + 7; // simplified for this example
> 
> `filename` *might* be strictly aligned.  If it is, `suffix` certainly
> is not.
> 
> What's your solution?  Allocate another strictly aligned array
> object, and copy the suffix to it -- using a copy that has to deal
> with unaligned memory anyway?  In the name of efficiency?

If the suffix isn't used much, simply tolerate the inefficiency of using an
unaligned string.  If it's used enough that the inefficiency would matter,
copy it to an aligned string.  If the speed penalty for using an unaligned
string is half the cost of copying the string, and code will need to use the
unaligned string ten times, then the speed penalty for those five uses would
total 5x the cost of copying the string, so copying the string once and then
using that copy 10 times would offer a big speed improvement.

> If you need a string to be aligned for some reason, sure, you'll
> have to do that kind of thing.  But most of the time, you don't,
> and imposing a general rule to allow for the rare cases where you
> might need extra alignment is nonsense.

Using separate base pointers and offsets will allow more versatility with
regard to string implementations than would be possible if code expects to
be able to take a tail substring of a string merely by adding an offset
to the pointer.  Whether or not code would plausibly need to use other
kinds of string implementations would vary depending upon the implementation
and the kinds of applications it runs.

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

#101666

W dniu piątek, 13 stycznia 2017 21:49:53 UTC+1 użytkownik supe...@casperkitty.com napisał:
> On Friday, January 13, 2017 at 2:13:01 PM UTC-6, Keith Thompson wrote:
> > Any string copy function that requires the string to be strictly aligned
> > does not work correctly on C strings.
> 
> True, but a conforming implementation may replace calls to strcpy with
> calls to an __aligned_strcpy function which imposes stronger requirements
> than strcpy in cases where it can be certain that the pointers in
> question will satisfy that function's requirements.  Further, a conforming
> implementation's may process some functions in a way that executes much more
> efficiently when given an aligned pointer than an unaligned one, even if
> both would work.
> 
> > If I define an array object containing a string:
> > 
> >     const char arr[] = "hello";
> > 
> > then there's no guarantee that arr is strictly aligned.  It likely is,
> > but nothing in C requires it, and if you're writing code that assumes it
> > is, your code is broken.
> 
> True, but an implementation which ensures that the strings are word-aligned
> would be able to take advantage of that in its own generated code, and an
> implementation where operations on aligned strings are much faster than on
> unaligned could achieve a speed boost by having the compiler ensure that
> strings were aligned when practical.
> 
> > > 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).
> > 
> > Suppose you have a string "foobar.txt", and you want just the "txt"
> > suffix as a string:
> > 
> >     const char *filename = "foobar.txt";
> >     const char *suffix = filename + 7; // simplified for this example
> > 
> > `filename` *might* be strictly aligned.  If it is, `suffix` certainly
> > is not.
> > 
> > What's your solution?  Allocate another strictly aligned array
> > object, and copy the suffix to it -- using a copy that has to deal
> > with unaligned memory anyway?  In the name of efficiency?
> 
> If the suffix isn't used much, simply tolerate the inefficiency of using an
> unaligned string.  If it's used enough that the inefficiency would matter,
> copy it to an aligned string.  If the speed penalty for using an unaligned
> string is half the cost of copying the string, and code will need to use the
> unaligned string ten times, then the speed penalty for those five uses would
> total 5x the cost of copying the string, so copying the string once and then
> using that copy 10 times would offer a big speed improvement.
> 
> > If you need a string to be aligned for some reason, sure, you'll
> > have to do that kind of thing.  But most of the time, you don't,
> > and imposing a general rule to allow for the rare cases where you
> > might need extra alignment is nonsense.
> 
> Using separate base pointers and offsets will allow more versatility with
> regard to string implementations than would be possible if code expects to
> be able to take a tail substring of a string merely by adding an offset
> to the pointer.  Whether or not code would plausibly need to use other
> kinds of string implementations would vary depending upon the implementation
> and the kinds of applications it runs.

some generations of cpu (i mean x86 here as i readed on this) improve the unaligned acceses.. (it was slower, than in next generation faster (they like to show any speedup in charts so they at least can improve unaligned to show something ;c (though i hear kerby lake recently shipped was maybe first that not improved it), - i dont know what it looks like now

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

#101644

On Friday, January 13, 2017 at 12:17:56 PM UTC-6, Richard Heathfield wrote:
> 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.

In most languages other than C, a function which was supposed to operate on
part of an array would be passed a pointer to the entire array along with a
starting index and--if it was supposed to operate upon a variable number of
items, either an ending index, a past-one index, or a length.  C allowed
code which was using strings to pass a single pointer rather than having to
pass a pointer and two integers.  Further, on many historical platforms it
was faster to access memory at the address identified by a pointer, than at
an address identified by a pointer and an offset.  These facts made C's
design a good fit for string handling on such platforms.

Today, many platforms can perform base+displacement addressing just as fast
as they can perform "simple" pointer addressing, and optimizers would be
able to benefit from knowing that it would be impossible for p[x] to alias
q[y] unless p==q and x==y.  Consequently, C strings are not as good a fit
for today's machines and compilers as they were for the machines and
compilers of the 1980s and 1990s.  Today, a lot of operations that work on
substrings could be handled more cleanly by passing strings as
[base,offset,length] triplets than by trying to pass strings as bare
pointers, but 20 years ago the reverse would have been true.

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

#101654

W dniu piątek, 13 stycznia 2017 19:46:52 UTC+1 użytkownik supe...@casperkitty.com napisał:
> On Friday, January 13, 2017 at 12:17:56 PM UTC-6, Richard Heathfield wrote:
> > 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.
> 
> In most languages other than C, a function which was supposed to operate on
> part of an array would be passed a pointer to the entire array along with a
> starting index and--if it was supposed to operate upon a variable number of
> items, either an ending index, a past-one index, or a length.  C allowed
> code which was using strings to pass a single pointer rather than having to
> pass a pointer and two integers.  Further, on many historical platforms it
> was faster to access memory at the address identified by a pointer, than at
> an address identified by a pointer and an offset.  These facts made C's
> design a good fit for string handling on such platforms.
> 

you mean that " while(++p!=0) {} " worked faster than 
 " while(++p<=q) {} " or something like that?


 
> Today, many platforms can perform base+displacement addressing just as fast
> as they can perform "simple" pointer addressing, and optimizers would be
> able to benefit from knowing that it would be impossible for p[x] to alias
> q[y] unless p==q and x==y.  Consequently, C strings are not as good a fit
> for today's machines and compilers as they were for the machines and
> compilers of the 1980s and 1990s.  Today, a lot of operations that work on
> substrings could be handled more cleanly by passing strings as
> [base,offset,length] triplets than by trying to pass strings as bare
> pointers, but 20 years ago the reverse would have been true.

yes, in general i agree with that, 

(with some corrections/notes: not triplets but pairs (begin/end), (speaking on strings not substrings but is more important; substrings also a pairs btw )

also probably, in reality pairs was even back then 
better than zero ended strings .. but they didnt knew
it then  *

* (it is btw not pasing begin pointer wrong but 
zero ending is wrong, when passing string to function 
one can quite legally pas both "foo(char* begin, char* end)" but the definition

char* str = "ala ma kota";

wont fit in this (present) scenerio becouse you 
got no info on end char [though it could be extended,
like ok in various ways like

1) ok if str is char* (begin pointer ) then acces to last char (which compiler also knows ) could be by some syntax
(like str[end], str.end, str:end  sorta like this (not sayin this is good as it looks like function on str where str is begin pointer when in reality it is not function on str but other pointer, though attached))
2) str can be treated as 2-pointer (like 2-pointer structure), or like semantically higher level string 
but with option to obtain the pointers

char[] str = "ala ma kota"; 

//str.begin, str.end accesible

(the second seem more reasonable though some details
would need to be decided yet maybe)


\fir\

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

#101641

W dniu piątek, 13 stycznia 2017 18:45:47 UTC+1 użytkownik Malcolm McLean napisał:
> 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.

cant agree with that, that could mean you want just simple substring printing function (like print(char* str, unsigned begin, unsigned end)) illegal unles they make copy 
this substring (where indeed even a copy function need to acces this substring - that could eventually mean that 
substrings acces is illegal at all ;C )

i could agree in reusing old pointer like

char* str = "c:\\aaaa\\bbb\\ccc\\file.txt";

void print_name()
{
  str+=16;
  print(str);
}

but simple

void print_name()
{
  print(str+16);
}

or

void print_name()
{
  char* name = str+16;
  print(name);
}

is ok to me 

to those people liking copies im not sure if i mentioned
it (i remember once i was to mention it) that in reality copies of data rarely exist (and if they exist it may mean the program is wrong as you just need input and output

/fir/

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

#101649

On Friday, January 13, 2017 at 12:41:55 PM UTC-6, fir wrote:
> cant agree with that, that could mean you want just simple substring printing function (like print(char* str, unsigned begin, unsigned end)) illegal unles they make copy 
> this substring (where indeed even a copy function need to acces this substring - that could eventually mean that 
> substrings acces is illegal at all ;C )

Would one want code to launch nasal demons if an attempt is made to print
the 16th and subsequent characters of a 12-character string, or would one
want more predictable behavior [perhaps printing nothing, or perhaps forcing
an abnormal program termination, but keeping demons in check regardless]?
If such a function receives a pointer to the start of a string along with the
desired offset, it will be able to behave in controlled fashion even if the
offset is greater than the string length.  If the function only receives a
pre-adjusted pointer, however, it will be unable to offer such protection.

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

#101657

W dniu piątek, 13 stycznia 2017 19:41:55 UTC+1 użytkownik fir napisał:

i meant 

> i could agree in reusing old pointer like
> 
> char* str = "c:\\aaaa\\bbb\\ccc\\file.txt";
> 
> void print_name()
> {
>   str+=16;
>   print(str);
> }
> is wrong

(is wrong was skipped)
this i could consider wrong as information is lost (though
on the odter side maybe this kind of risky/stunt-c could be some fun) 

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

#101664

W dniu piątek, 13 stycznia 2017 21:28:29 UTC+1 użytkownik fir napisał:
> W dniu piątek, 13 stycznia 2017 19:41:55 UTC+1 użytkownik fir napisał:
> 
> i meant 
> 
> > i could agree in reusing old pointer like
> > 
> > char* str = "c:\\aaaa\\bbb\\ccc\\file.txt";
> > 
> > void print_name()
> > {
> >   str+=16;
> >   print(str);
> > }
> > is wrong
> 
> (is wrong was skipped)
> this i could consider wrong as information is lost (though
> on the odter side maybe this kind of risky/stunt-c could be some fun)

i may also repeat some thing about some unique unknown c 
flaw i discovered once

(this is related becouse this faw makes function that 
return allocked memory less usable or at least worse 
lookin)

c lacks of some kind of "in-place reallock" or "allock that is tied to place" (dont know how to call it) consider such examples

i just want a function that will create n chars long 
string 

char* create_string(int n);

such i could use (maybe simplyfying codes a it but for ilustration)

void foo()
{
  char* str_10   = create_string( 10 );
  char* str_rand = create_string( rand()%25 );

  //use them
  
  // i dont wanna nor populate memory nor i wont care 
  //  of 'releasing' them - i just wanna them be like 
  // locals or static normal variables but "flexible"
  // it effectively means resizable/ reallocable 

}
 
char* create_string(int n)
{
  char* a = mallock(n);
  return a;
}

wont work (populates consumed memory)

char* create_string(int n)
{
  static char* str = NULL;
  str = realloc(str, n);
  return str;
}

wont also work (becouse this static is one shared by all calls and will be overwritten destroing the prevoius data)

you could do that with realooc by
 
char* create_string(char* str, int n)
{
  str = realloc(str, n);
  return str;
}

but it makes caller side less nice 

void foo()
{
  static char* str_10   = NULL;
               str_10 =  create_string(str_10, 10 );
  static char* str_rand = NULL;
               str_rand = create_string(str_rand, rand()%25 );

}

this is uglier / not exactly the same

what c needs is just some syntx/semantics that will allow 
to make it possible (which is technically possible only c
has not mechanism for that) shortest way to do it it would be probable add some other kind of static "caller side static" that will be not tied to body of the function but to the call instance/place (though im not sure it this would be the only option here) [probably not other is to allow to adres output data

(char* out ) create_string( int n)
{
  out = realloc(out, n);
  return out;
}
]
also one could consider if this 

void foo()
{
  char* s   = create_string( rand()%20 );
}
 
should work in both cases i mean as a local string 
(that is cleared by exit) and as a static one which is not
cleared only reallocked on next entry (the case i was describing above was for static case) - how it could work as a locals i was yet not considering (in the local case it probably could be done by manipulating stack pointer (thus very quick, though sokme rules of usage would have to be defined (im not sure as to this (but hopefully it could be done by manipulating stackpointer, it would be probably nice ) and it  needs more carefull consideration)

/fir/

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

#101667

On Friday, January 13, 2017 at 3:07:39 PM UTC-6, fir wrote:
> c lacks of some kind of "in-place reallock" or "allock that is tied to place" (dont know how to call it) consider such examples

The realloc() function could have been much better designed, and fails to
efficiently accommodate some major usage case that should be easy to handle
with an option to adjust the size of an allocation *if that can be done
without invalidating any pointers to it*, or else indicate that the request
could not be honored.  This would help in cases where code starts by over-
allocating space for an object and then adjusting it to the proper size, or
in cases where an object that will need to be expanded was the last one to
be allocated, and where code could regenerate pointers to the object if it
moved but would benefit from not having to do so if the object stayed put.

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

#101669

On 13/01/2017 21:29, supercat@casperkitty.com wrote:
> On Friday, January 13, 2017 at 3:07:39 PM UTC-6, fir wrote:
>> c lacks of some kind of "in-place reallock" or "allock that is tied to place" (dont know how to call it) consider such examples
>
> The realloc() function could have been much better designed, and fails to
> efficiently accommodate some major usage case that should be easy to handle
> with an option to adjust the size of an allocation *if that can be done
> without invalidating any pointers to it*, or else indicate that the request
> could not be honored.  This would help in cases where code starts by over-
> allocating space for an object and then adjusting it to the proper size, or
> in cases where an object that will need to be expanded was the last one to
> be allocated, and where code could regenerate pointers to the object if it
> moved but would benefit from not having to do so if the object stayed put.

In-place re-allocation is difficult with a flat address space.

It can be emulated, but would require language support to do it 
properly, and might mean implementing pointers as (handle, offset).

Or it can be done with an API, but that would be messy to use. 
(Something along the lines of Win16's GlobalLock and other such 
functions.) Essentially, the program can't directly use normal pointers 
as they can become invalidated.

-- 
bartc

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

#101672

W dniu piątek, 13 stycznia 2017 22:45:26 UTC+1 użytkownik Bart napisał:
> On 13/01/2017 21:29, supercat@casperkitty.com wrote:
> > On Friday, January 13, 2017 at 3:07:39 PM UTC-6, fir wrote:
> >> c lacks of some kind of "in-place reallock" or "allock that is tied to place" (dont know how to call it) consider such examples
> >
> > The realloc() function could have been much better designed, and fails to
> > efficiently accommodate some major usage case that should be easy to handle
> > with an option to adjust the size of an allocation *if that can be done
> > without invalidating any pointers to it*, or else indicate that the request
> > could not be honored.  This would help in cases where code starts by over-
> > allocating space for an object and then adjusting it to the proper size, or
> > in cases where an object that will need to be expanded was the last one to
> > be allocated, and where code could regenerate pointers to the object if it
> > moved but would benefit from not having to do so if the object stayed put.
> 
> In-place re-allocation is difficult with a flat address space.
> 
> It can be emulated, but would require language support to do it 
> properly, and might mean implementing pointers as (handle, offset).
> 
> Or it can be done with an API, but that would be messy to use. 
> (Something along the lines of Win16's GlobalLock and other such 
> functions.) Essentially, the program can't directly use normal pointers 
> as they can become invalidated.
> 

depending what you mean bu in-place 
i personally by in-place mean not that it cant be rallocked to different place byt that i can use  realloc without passing pointer by arg

sorta 

for(int size=1; size<30; size++)
{
 char* p =  realock(size);
}

simplifying a bit (ore was in previous post)

as to those pointer changes i dont see a problem
you could use rigt value you jast cant do fixed
adressing (you cant do some optimistation, speaking 
maybe a bit to short, as some subtle things may be here, 
but i think it will work just ok anyway) (i wast talkin on this more than once, imagine you have

int table[100]; //realocable one

all the code reaching to table values will just treat 
table as a pointer located comewhere say 0x43fce2 
instead of immediate adres (say 0x470900))

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

#101677

W dniu piątek, 13 stycznia 2017 22:59:45 UTC+1 użytkownik fir napisał:
> 
> sorta 
> 
> for(int size=1; size<30; size++)
> {
>  char* p =  realock(size);
> }
> 

in summary i wanted to say if c would have that one above
then returning allocked values would have much more
sense (coz you will dont have to clean nor youre afraid that yopu will have memory leaks nor you will be afraid that next call wil erase data)

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

#101674

On Friday, January 13, 2017 at 3:45:26 PM UTC-6, Bart wrote:
> On 13/01/2017 21:29, supercat wrote:
> > The realloc() function could have been much better designed, and fails to
> > efficiently accommodate some major usage case that should be easy to handle
> > with an option to adjust the size of an allocation *if that can be done
> > without invalidating any pointers to it*, or else indicate that the request
> > could not be honored.  This would help in cases where code starts by over-
> > allocating space for an object and then adjusting it to the proper size, or
> > in cases where an object that will need to be expanded was the last one to
> > be allocated, and where code could regenerate pointers to the object if it
> > moved but would benefit from not having to do so if the object stayed put.
> 
> In-place re-allocation is difficult with a flat address space.

If the storage following an allocation has been set aside for some other
purpose, it won't be able to expand that allocation in-place.  Shrinking
allocations in place should usually be possible, however, and expanding
the most recent allocation should often be possible.  

> It can be emulated, but would require language support to do it 
> properly, and might mean implementing pointers as (handle, offset).

No emulation needed.  If the semantics of the function are "perform the
re-allocation if possible, or else indicate that it was impossible", any
implementation could satisfy that requirement by simply reporting
unconditionally that it wasn't possible.  On the other hand, having an
implementation honor the requests whenever the storage layout allows would
allow code to be more efficient than it could otherwise.

> Or it can be done with an API, but that would be messy to use. 
> (Something along the lines of Win16's GlobalLock and other such 
> functions.) Essentially, the program can't directly use normal pointers 
> as they can become invalidated.

Handle-based approaches avoid the need for programs to worry about
fragmentation, and they can be rather pleasant in single-threaded
or cooperatively-multithreaded systems.  The biggest problem with them
is that they do not work well in pre-emptive multi-threading systems.
In any case, though, they're not what I was talking about.

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

#101670

W dniu piątek, 13 stycznia 2017 22:29:54 UTC+1 użytkownik supe...@casperkitty.com napisał:
> On Friday, January 13, 2017 at 3:07:39 PM UTC-6, fir wrote:
> > c lacks of some kind of "in-place reallock" or "allock that is tied to place" (dont know how to call it) consider such examples
> 
> The realloc() function could have been much better designed, and fails to
> efficiently accommodate some major usage case that should be easy to handle
> with an option to adjust the size of an allocation *if that can be done
> without invalidating any pointers to it*, or else indicate that the request
> could not be honored.  This would help in cases where code starts by over-
> allocating space for an object and then adjusting it to the proper size, or
> in cases where an object that will need to be expanded was the last one to
> be allocated, and where code could regenerate pointers to the object if it
> moved but would benefit from not having to do so if the object stayed put.

im not sure if some specalised platform dependant version of reallock do not allow you to controll more od the reallocking behaviour - i was not reading on it to much
- i agree though that overal this is probably important 
(as reallocking is handy and being able to controll it may be maybe impotrant for efficiency.. i was never thinking on much details here ) 
(the above what i say before is on other topic, more like extending c paradigm on quite usefull thing)

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

#101611

W dniu piątek, 13 stycznia 2017 01:50:44 UTC+1 użytkownik Malcolm McLean napisał:
> 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.

 dont seem to be also general in right meaning of this word (where general means "rule that is generally ok") it may be more like private rule or sergeant rule ;<

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

#101527

On Thursday, January 12, 2017 at 2:08:46 AM UTC-6, Barry Schwarz wrote:
> On Wed, 11 Jan 2017 15:11:43 -0800 (PST), "Fernando D. Bozzo"
> >        return NULL; // Would like to throw an error or exception, but don't know how to yet.
> 
> Why would you do that?  This is a service function.  If it fails, let
> the calling function decide what is appropriate.  Consider malloc.
> When it fails, it returns NULL.  This lets the calling function decide
> if there still some useful work that can be accomplished.

For many kinds of programs, especially non-interactive ones, it is better to
fail fast if something unexpected happens than to try to muddle through it.
If a function guarantees that it will either succeed or else raise a signal,
for an abnormal program termination, latch an "error occurred" status, etc.
that may save code at every call site.

While no single approach to error handling will be proper for every
application, that doesn't mean that requiring that every single call site
include error handling code is the best approach either.  A nicer approach
is sometimes to have a parameter that specifies something about what should
happen in case of error, e.g. an int* with the semantics that:

    1. If it is non-null and points to a non-zero value, the function should
       abort without doing anything.

    2. If an error occurs and the parameter is null, force a controlled
       abnormal program termination.

    3. Otherwise set the variable to reflect the error status.

If calling code doesn't want to handle error conditions, it can simply pass
null and accept the default handling (which will terminate the program, but
will keep any nasal demons in check).  If the calling code wants to perform
a sequence of operations, it can set up a variable at the start and then
pass it to all of them.  The code will need to check the variable at some
key points, but not at every function call.

A nice and simple approach, but it adds an extra parameter to every function
call.  Probably not as bad as requiring a check after every function call,
but if every caller would end up passing null for the parameter it would be
more efficient to omit it.

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

#101529

Barry Schwarz <schwarzb@dqel.com> writes:
> On Wed, 11 Jan 2017 15:11:43 -0800 (PST), "Fernando D. Bozzo"
> <fdbozzo@gmail.com> wrote:
>
>>I've read all of the recommendations and suggestions and ended with
>>two possible working (and a little tested) solutions for this method:
>>
>>
>>SOLUTION 1: Returning malloc'ed string
>>- In this case the caller is responsible for free()ing the pointer.
>>----------------------------------------------------------------------------
>>char *justfname(const char *text_in)
>>{
>>    if (text_in == NULL)
>>    {
>>        return NULL; // Would like to throw an error or exception, but don't know how to yet.
>
> Why would you do that?  This is a service function.  If it fails, let
> the calling function decide what is appropriate.  Consider malloc.
> When it fails, it returns NULL.  This lets the calling function decide
> if there still some useful work that can be accomplished.

[...]

Throwing an exception would also let the caller deal with an error in
any way it likes.  The only drawback for C is that exceptions don't
exist, so we have to return error indications in some other way.
(I'm assuming that by "exception", Fernando means something like
a C++ or Ada exception, not an immediately fatal run-time error.)

-- 
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]

#101533

El jueves, 12 de enero de 2017, 17:37:35 (UTC+1), Keith Thompson  escribió:
> 
> Throwing an exception would also let the caller deal with an error in
> any way it likes.  The only drawback for C is that exceptions don't
> exist, so we have to return error indications in some other way.
> (I'm assuming that by "exception", Fernando means something like
> a C++ or Ada exception, not an immediately fatal run-time error.)
> 


Exactly! I mean that use. I did use this kind of error traping in FoxPro.

In C I think that I can do something "similar", dont know, cames to my mind passing an error handler of same type into the function so in case of error that handler is executed (if possible). Anyway, I have a lot to read and test

Something like this I think could be great:
http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html

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

#101706

"Fernando D. Bozzo" <fdbozzo@gmail.com> writes:

> I've read all of the recommendations and suggestions and ended with
> two possible working (and a little tested) solutions for this method:
> [...]

You've pretty much gotten your questions answered but I thought
you might like to see one more way of handling the problem.

Using the method of returning a pointer to somewhere in the
argument string, this functionality can be written rather crisply
as follows:

    #include <string.h>

    static const char *
    post_directories_tail( const char *start, const char *s ){
        return
          s == start  ||  s[-1]==':' || s[-1]=='\\' || s[-1]=='/'
            ?  s
            :  post_directories_tail( start, s-1 );
    }

    const char *
    just_filename( const char *path ){
        return  post_directories_tail( path, path + strlen( path ) );
    }

See if you can work through how the post_directories_tail()
function determines the appropriate return value.  Note that it
is called with one pointer to the start of the string, and (for
the first call) the second pointer pointing at the null character
at the end of the string.

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

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

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

csiph-web