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

Groups > comp.lang.c++ > #86564 > unrolled thread

How do C -programmers do reliable string handling?

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

Contents

  How do C -programmers do reliable string handling? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-24 20:22 +0300
    Re: How do C -programmers do reliable string handling? Bo Persson <bo@bo-persson.se> - 2022-09-24 21:00 +0200
    Re: How do C -programmers do reliable string handling? Gawr Gura <gawrgura@mail.hololive.com> - 2022-09-24 12:29 -0700
      Re: How do C -programmers do reliable string handling? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-25 00:47 +0300
        Re: How do C -programmers do reliable string handling? Muttley@dastardlyhq.com - 2022-09-25 08:50 +0000
          Re: How do C -programmers do reliable string handling? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-25 13:37 +0300
          Re: How do C -programmers do reliable string handling? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-25 13:38 +0300
          Re: How do C -programmers do reliable string handling? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-25 13:34 +0200
            Re: How do C -programmers do reliable string handling? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-25 17:00 +0200
            Re: How do C -programmers do reliable string handling? Muttley@dastardlyhq.com - 2022-09-25 15:14 +0000
        Re: How do C -programmers do reliable string handling? Gawr Gura <gawrgura@mail.hololive.com> - 2022-09-25 09:22 -0700
          Re: How do C -programmers do reliable string handling? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-26 01:01 +0300
            Re: How do C -programmers do reliable string handling? Richard Damon <Richard@Damon-Family.org> - 2022-09-25 19:02 -0400
              Re: How do C -programmers do reliable string handling? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-26 07:27 +0300
                Re: How do C -programmers do reliable string handling? Muttley@dastardlyhq.com - 2022-09-26 15:19 +0000
                  Re: How do C -programmers do reliable string handling? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-26 21:53 +0300
                    Re: How do C -programmers do reliable string handling? Richard Damon <Richard@Damon-Family.org> - 2022-09-26 20:42 -0400
                      Re: How do C -programmers do reliable string handling? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-26 17:54 -0700
                        Re: How do C -programmers do reliable string handling? Muttley@dastardlyhq.com - 2022-09-27 09:36 +0000
                        Re: How do C -programmers do reliable string handling? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-27 15:28 +0100
            Re: How do C -programmers do reliable string handling? Gawr Gura <gawrgura@mail.hololive.com> - 2022-09-25 16:34 -0700
              Re: How do C -programmers do reliable string handling? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-26 07:32 +0300
      Re: How do C -programmers do reliable string handling? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:33 +0000
        Re: How do C -programmers do reliable string handling? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-26 12:18 +0300
          Re: How do C -programmers do reliable string handling? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 09:47 +0000
        Re: How do C -programmers do reliable string handling? Gawr Gura <gawrgura@mail.hololive.com> - 2022-09-26 07:40 -0700
    Re: How do C -programmers do reliable string handling? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-24 23:04 +0300
      Re: How do C -programmers do reliable string handling? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-09-25 00:44 +0300
    Re: How do C -programmers do reliable string handling? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-09-26 02:03 -0700

Page 1 of 2  [1] 2  Next page →

#86564 — How do C -programmers do reliable string handling?

I have done C++ since 1997. I personally do not understand why use C if 
C++ is extented C and has more in it (and thats why I immediately 
swiched from C to C++ when I found C++).

But language-fight aside :) .. I have a serious/honest question:
What is the best way to represend a string in C language? How do best C 
programmers represend a string?

Because I am worried that that the length of the string is not 
"protected" as there is no private in C language.

In C++ it is well protected and safe something like this:

class String {
// all access functions

private:
int m_lenght;
};

So, it is basically impossible to have a wrong lenght value for a string.
Am I right that C programmers do it something like:

struct String {
char* data;
int lenght;
};

but obviously somebody might put: lenght = 99999999999, and then its 
going bad....

How do C programmers make string safe that the above problem does not 
occur (that the lenght of the string goes wrong)?

[toc] | [next] | [standalone]

#86568

On 2022-09-24 at 19:22, JiiPee wrote:
> I have done C++ since 1997. I personally do not understand why use C if 
> C++ is extented C and has more in it (and thats why I immediately 
> swiched from C to C++ when I found C++).
> 
> But language-fight aside :) .. I have a serious/honest question:
> What is the best way to represend a string in C language? How do best C 
> programmers represend a string?
> 
> Because I am worried that that the length of the string is not 
> "protected" as there is no private in C language.
> 
> In C++ it is well protected and safe something like this:
> 
> class String {
> // all access functions
> 
> private:
> int m_lenght;
> };
> 
> So, it is basically impossible to have a wrong lenght value for a string.
> Am I right that C programmers do it something like:
> 
> struct String {
> char* data;
> int lenght;
> };
> 
> but obviously somebody might put: lenght = 99999999999, and then its 
> going bad....
> 
> How do C programmers make string safe that the above problem does not 
> occur (that the lenght of the string goes wrong)?

By not storing the length separately? You just have to call strlen each 
time you need to know the length.

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

#86570

On 9/24/22 10:22, JiiPee wrote:
> I have done C++ since 1997. I personally do not understand why use C if 
> C++ is extented C and has more in it (and thats why I immediately 
> swiched from C to C++ when I found C++).
> 
> But language-fight aside :) .. I have a serious/honest question:
> What is the best way to represend a string in C language? How do best C 
> programmers represend a string?
> 
> Because I am worried that that the length of the string is not 
> "protected" as there is no private in C language.
> 
> In C++ it is well protected and safe something like this:
> 
> class String {
> // all access functions
> 
> private:
> int m_lenght;
> };
> 
> So, it is basically impossible to have a wrong lenght value for a string.
> Am I right that C programmers do it something like:
> 
> struct String {
> char* data;
> int lenght;
> };
> 
> but obviously somebody might put: lenght = 99999999999, and then its 
> going bad....
> 
> How do C programmers make string safe that the above problem does not 
> occur (that the lenght of the string goes wrong)?

In C, if you really want to protect data from someone else mishandling
it then you can use an opaque type. In a header you would write:

struct string;

struct string* create_string(const char *const data);
void destroy_string(struct string *const str);
size_t get_string_length(const struct string *const str);
/* etc. */

In the corresponding source file you would define struct string.
Consumers of the header file don't know the structure of struct string
so they are required to access it through the provided procedures rather
than directly manipulating it.

I think that this kind of protection is often unnecessary though. Access
modifiers in C++ help keep things sane but they don't provide any real
guarantee against outside manipulation. If someone really wants to
modify your object they can always convert it to a char array and fiddle
with it.

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

#86574

On 24/09/2022 22:29, Gawr Gura wrote:
> but they don't provide any real
> guarantee against outside manipulation. 


If someone really wants to
> modify your object they can always convert it to a char array and fiddle
> with it.

Sure, although in my 30 years C++ I don't remember ever facing this 
problem. It is quite difficult to accidentally do this.

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

#86576

On Sun, 25 Sep 2022 00:47:13 +0300
JiiPee <kerrttuPoistaTama11@gmail.com> wrote:
>On 24/09/2022 22:29, Gawr Gura wrote:
>> but they don't provide any real
>> guarantee against outside manipulation. 
>
>
>If someone really wants to
>> modify your object they can always convert it to a char array and fiddle
>> with it.
>
>Sure, although in my 30 years C++ I don't remember ever facing this 
>problem. It is quite difficult to accidentally do this.

Many years ago faced with needing to access a private variable in a class
that didn't have a getter method written by a team that refused to provide one 
for reasons I never understood, so I simply took the address of the first
public variable following it, counted back and derefrenced the pointer. Very
dodgy but it worked (until they changed the class layout obv).

eg:

#include <stdio.h>

class myclass
{
        int i;
public:
        int j;
        myclass(): i(123) { }
};


int main()
{
        myclass mc;
        int *p = &mc.j;
        --p;
        printf("%d\n",*p);
        return 0;
}

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

#86577

On 25/09/2022 11:50, Muttley@dastardlyhq.com wrote:
> int main()
> {
>          myclass mc;
>          int *p = &mc.j;
>          --p;
>          printf("%d\n",*p);
>          return 0;
> }

Right, but it would never really come to my mind doing such things ... 
unless I purposely did that for reasons like yours.

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

#86578

On 25/09/2022 11:50, Muttley@dastardlyhq.com wrote:
> int main()
> {
>          myclass mc;
>          int *p = &mc.j;
>          --p;
>          printf("%d\n",*p);
>          return 0;
> }
> 
> 

I guess the power and the weakness also of the pointers

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

#86579

Am 25.09.2022 um 10:50 schrieb Muttley@dastardlyhq.com:
> On Sun, 25 Sep 2022 00:47:13 +0300
> JiiPee <kerrttuPoistaTama11@gmail.com> wrote:
>> On 24/09/2022 22:29, Gawr Gura wrote:
>>> but they don't provide any real
>>> guarantee against outside manipulation.
>>
>>
>> If someone really wants to
>>> modify your object they can always convert it to a char array and fiddle
>>> with it.
>>
>> Sure, although in my 30 years C++ I don't remember ever facing this
>> problem. It is quite difficult to accidentally do this.
> 
> Many years ago faced with needing to access a private variable in a class
> that didn't have a getter method written by a team that refused to provide one
> for reasons I never understood, so I simply took the address of the first
> public variable following it, counted back and derefrenced the pointer. Very
> dodgy but it worked (until they changed the class layout obv).
> 
> eg:
> 
> #include <stdio.h>
> 
> class myclass
> {
>          int i;
> public:
>          int j;
>          myclass(): i(123) { }
> };
> 
> 
> int main()
> {
>          myclass mc;
>          int *p = &mc.j;
>          --p;
>          printf("%d\n",*p);
>          return 0;
> }

Why not (&mc.j)[-1] ?

> 
> 
> 

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

#86580

Am 25.09.2022 um 13:34 schrieb Bonita Montero:
> Am 25.09.2022 um 10:50 schrieb Muttley@dastardlyhq.com:
>> On Sun, 25 Sep 2022 00:47:13 +0300
>> JiiPee <kerrttuPoistaTama11@gmail.com> wrote:
>>> On 24/09/2022 22:29, Gawr Gura wrote:
>>>> but they don't provide any real
>>>> guarantee against outside manipulation.
>>>
>>>
>>> If someone really wants to
>>>> modify your object they can always convert it to a char array and 
>>>> fiddle
>>>> with it.
>>>
>>> Sure, although in my 30 years C++ I don't remember ever facing this
>>> problem. It is quite difficult to accidentally do this.
>>
>> Many years ago faced with needing to access a private variable in a class
>> that didn't have a getter method written by a team that refused to 
>> provide one
>> for reasons I never understood, so I simply took the address of the first
>> public variable following it, counted back and derefrenced the 
>> pointer. Very
>> dodgy but it worked (until they changed the class layout obv).
>>
>> eg:
>>
>> #include <stdio.h>
>>
>> class myclass
>> {
>>          int i;
>> public:
>>          int j;
>>          myclass(): i(123) { }
>> };
>>
>>
>> int main()
>> {
>>          myclass mc;
>>          int *p = &mc.j;
>>          --p;
>>          printf("%d\n",*p);
>>          return 0;
>> }
> 
> Why not (&mc.j)[-1] ?
> 
>>
>>
>>
> 
> 

I'm asking myself if this and Mutterly's code is an
illegal aliasing which the compiler musn't notice.

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

#86581

On Sun, 25 Sep 2022 13:34:59 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 25.09.2022 um 10:50 schrieb Muttley@dastardlyhq.com:
>> On Sun, 25 Sep 2022 00:47:13 +0300
>> JiiPee <kerrttuPoistaTama11@gmail.com> wrote:
>>> On 24/09/2022 22:29, Gawr Gura wrote:
>>>> but they don't provide any real
>>>> guarantee against outside manipulation.
>>>
>>>
>>> If someone really wants to
>>>> modify your object they can always convert it to a char array and fiddle
>>>> with it.
>>>
>>> Sure, although in my 30 years C++ I don't remember ever facing this
>>> problem. It is quite difficult to accidentally do this.
>> 
>> Many years ago faced with needing to access a private variable in a class
>> that didn't have a getter method written by a team that refused to provide
>one
>> for reasons I never understood, so I simply took the address of the first
>> public variable following it, counted back and derefrenced the pointer. Very
>> dodgy but it worked (until they changed the class layout obv).
>> 
>> eg:
>> 
>> #include <stdio.h>
>> 
>> class myclass
>> {
>>          int i;
>> public:
>>          int j;
>>          myclass(): i(123) { }
>> };
>> 
>> 
>> int main()
>> {
>>          myclass mc;
>>          int *p = &mc.j;
>>          --p;
>>          printf("%d\n",*p);
>>          return 0;
>> }
>
>Why not (&mc.j)[-1] ?

Never thought of that. Useful to remember if I need to do something similar 
again.

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

#86582

> Sure, although in my 30 years C++ I don't remember ever facing this 
> problem. It is quite difficult to accidentally do this.

That being the case, why worry about someone mishandling a struct in C?
It's also quite difficult to accidentally write

str->length = 65535

when you meant to write

str->length

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

#86584

On 25/09/2022 19:22, Gawr Gura wrote:
>> Sure, although in my 30 years C++ I don't remember ever facing this 
>> problem. It is quite difficult to accidentally do this.
> 
> That being the case, why worry about someone mishandling a struct in C?
> It's also quite difficult to accidentally write
> 
> str->length = 65535
> 
> when you meant to write
> 
> str->length

But I see other ways it could fail. Like imagine a funktion taking a 
reference:

void foo(int a, int& l)

and then you call: foo(a, str->length);
If foo() changes the variable l, then lenght gets changed. And this 
might be a mistake so that is not seeing the reference.

I mean, it opens much more doors to human mistakes or risks.

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

#86585

On 9/25/22 6:01 PM, JiiPee wrote:
> On 25/09/2022 19:22, Gawr Gura wrote:
>>> Sure, although in my 30 years C++ I don't remember ever facing this 
>>> problem. It is quite difficult to accidentally do this.
>>
>> That being the case, why worry about someone mishandling a struct in C?
>> It's also quite difficult to accidentally write
>>
>> str->length = 65535
>>
>> when you meant to write
>>
>> str->length
> 
> But I see other ways it could fail. Like imagine a funktion taking a 
> reference:
> 
> void foo(int a, int& l)
> 
> and then you call: foo(a, str->length);
> If foo() changes the variable l, then lenght gets changed. And this 
> might be a mistake so that is not seeing the reference.
> 
> I mean, it opens much more doors to human mistakes or risks.
> 

But C doesn't have references, so you can't do that.

In C++, it would be private, so you couldh't do it.

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

#86587

On 26/09/2022 02:02, Richard Damon wrote:
> On 9/25/22 6:01 PM, JiiPee wrote:
>> On 25/09/2022 19:22, Gawr Gura wrote:
>>>> Sure, although in my 30 years C++ I don't remember ever facing this 
>>>> problem. It is quite difficult to accidentally do this.
>>>
>>> That being the case, why worry about someone mishandling a struct in C?
>>> It's also quite difficult to accidentally write
>>>
>>> str->length = 65535
>>>
>>> when you meant to write
>>>
>>> str->length
>>
>> But I see other ways it could fail. Like imagine a funktion taking a 
>> reference:
>>
>> void foo(int a, int& l)
>>
>> and then you call: foo(a, str->length);
>> If foo() changes the variable l, then lenght gets changed. And this 
>> might be a mistake so that is not seeing the reference.
>>
>> I mean, it opens much more doors to human mistakes or risks.
>>
> 
> But C doesn't have references, so you can't do that.
> 
> In C++, it would be private, so you couldh't do it.

oh but could use pointer then. so if it was int* l

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

#86618

On Mon, 26 Sep 2022 07:27:05 +0300
JiiPee <kerrttuPoistaTama11@gmail.com> wrote:
>On 26/09/2022 02:02, Richard Damon wrote:
>> On 9/25/22 6:01 PM, JiiPee wrote:
>>> On 25/09/2022 19:22, Gawr Gura wrote:
>>>>> Sure, although in my 30 years C++ I don't remember ever facing this 
>>>>> problem. It is quite difficult to accidentally do this.
>>>>
>>>> That being the case, why worry about someone mishandling a struct in C?
>>>> It's also quite difficult to accidentally write
>>>>
>>>> str->length = 65535
>>>>
>>>> when you meant to write
>>>>
>>>> str->length
>>>
>>> But I see other ways it could fail. Like imagine a funktion taking a 
>>> reference:
>>>
>>> void foo(int a, int& l)
>>>
>>> and then you call: foo(a, str->length);
>>> If foo() changes the variable l, then lenght gets changed. And this 
>>> might be a mistake so that is not seeing the reference.
>>>
>>> I mean, it opens much more doors to human mistakes or risks.
>>>
>> 
>> But C doesn't have references, so you can't do that.
>> 
>> In C++, it would be private, so you couldh't do it.
>
>oh but could use pointer then. so if it was int* l

Its a bit hard to accidentaly write &(str->length) rather than str->length

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

#86624

On 26/09/2022 18:19, Muttley@dastardlyhq.com wrote:
> Its a bit hard to accidentaly write &(str->length) rather than str->length

no, I mean if the function takes a pointer (not a variable), and we are 
meant to pass a pointer to the lenght. But we dont know its also 
changing it.

Lets *assume* that a calculation is done like this:

float calculate(int round, int* lenght);

And then you call it with your lenght:

calculate(1110, &(str->length));

thinking that its only reading the lenght. but its changing it also.

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

#86629

On 9/26/22 2:53 PM, JiiPee wrote:
> On 26/09/2022 18:19, Muttley@dastardlyhq.com wrote:
>> Its a bit hard to accidentaly write &(str->length) rather than 
>> str->length
> 
> no, I mean if the function takes a pointer (not a variable), and we are 
> meant to pass a pointer to the lenght. But we dont know its also 
> changing it.
> 
> Lets *assume* that a calculation is done like this:
> 
> float calculate(int round, int* lenght);
> 
> And then you call it with your lenght:
> 
> calculate(1110, &(str->length));
> 
> thinking that its only reading the lenght. but its changing it also.

In C, a function taking a pointer is likely going to change it, why else 
use a pointer.

This makes the intent fairly clear.

C++, allowing functions have non-const reference parameters means it is 
harder to tell by looking at a call site, what are outputs.

This is handy at times, but means you need to think of things differently.

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

#86631

Richard Damon <Richard@Damon-Family.org> writes:
> On 9/26/22 2:53 PM, JiiPee wrote:
>> On 26/09/2022 18:19, Muttley@dastardlyhq.com wrote:
>>> Its a bit hard to accidentaly write &(str->length) rather than
>>> str->length
>> no, I mean if the function takes a pointer (not a variable), and we
>> are meant to pass a pointer to the lenght. But we dont know its also 
>> changing it.
>> Lets *assume* that a calculation is done like this:
>> float calculate(int round, int* lenght);
>> And then you call it with your lenght:
>> calculate(1110, &(str->length));
>> thinking that its only reading the lenght. but its changing it also.
>
> In C, a function taking a pointer is likely going to change it, why
> else use a pointer.
>
> This makes the intent fairly clear.

And if the function doesn't intend to change it, it should be a
pointer-to-const (which makes good sense if copying the value would be
unreasonably expensive or would have side effects).

> C++, allowing functions have non-const reference parameters means it
> is harder to tell by looking at a call site, what are outputs.

And again, you can use a const reference if you don't want to change the
value.  If a parameter is a non-const pointer (in C or C++) or a
non-const reference (in C++), you should assume that the referenced
object may be modified.  If it isn't, complain to the person who's
responsible for the function.

> This is handy at times, but means you need to think of things differently.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#86645

On Mon, 26 Sep 2022 17:54:20 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>Richard Damon <Richard@Damon-Family.org> writes:
>> On 9/26/22 2:53 PM, JiiPee wrote:
>>> On 26/09/2022 18:19, Muttley@dastardlyhq.com wrote:
>>>> Its a bit hard to accidentaly write &(str->length) rather than
>>>> str->length
>>> no, I mean if the function takes a pointer (not a variable), and we
>>> are meant to pass a pointer to the lenght. But we dont know its also 
>>> changing it.
>>> Lets *assume* that a calculation is done like this:
>>> float calculate(int round, int* lenght);
>>> And then you call it with your lenght:
>>> calculate(1110, &(str->length));
>>> thinking that its only reading the lenght. but its changing it also.
>>
>> In C, a function taking a pointer is likely going to change it, why
>> else use a pointer.
>>
>> This makes the intent fairly clear.
>
>And if the function doesn't intend to change it, it should be a
>pointer-to-const (which makes good sense if copying the value would be
>unreasonably expensive or would have side effects).

If the function takes a pointer to a struct then you can't really tell if it
will change the contents since its a lot more efficient to pass a pointer than
copy the whole structure onto the stack and for passing arrays you don't have
a choice except pass by reference (unless you embed in a struct) in which case
a pointer to const might be useful.

HOWEVER. If it requires a pointer to a primitive type then the function will
almost certainly be changing it otherwise as someone else wrote, why bother
requiring a pointer as they'll be no efficiency gains.

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

#86649

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Richard Damon <Richard@Damon-Family.org> writes:
<cut>
>> C++, allowing functions have non-const reference parameters means it
>> is harder to tell by looking at a call site, what are outputs.
>
> And again, you can use a const reference if you don't want to change the
> value.  If a parameter is a non-const pointer (in C or C++) or a
> non-const reference (in C++), you should assume that the referenced
> object may be modified.  If it isn't, complain to the person who's
> responsible for the function.

The trouble is you can't tell that you might have to check the function
declaration by looking at the call.  f(a, &b) tells me I might want to
look at f's declaration to see if the second parameter is a pointer to
const or not, but f(a, b) does not.  Either a or b might be modified and
I have to check f's declaration every time.

-- 
Ben.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web