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

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

Pointer to structure

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

Contents

  Pointer to structure Dexterr <dejangru@gmail.com> - 2014-12-21 03:16 -0800
    Re: Pointer to structure BartC <bc@freeuk.com> - 2014-12-21 12:09 +0000
      Re: Pointer to structure Siri Crews <chine.bleu@yahoo.com> - 2014-12-21 04:39 -0800
        Re: Pointer to structure BartC <bc@freeuk.com> - 2014-12-21 12:59 +0000
          Re: Pointer to structure Siri Crews <chine.bleu@yahoo.com> - 2014-12-21 05:05 -0800
            Re: Pointer to structure BartC <bc@freeuk.com> - 2014-12-21 13:12 +0000
              Re: Pointer to structure Siri Crews <chine.bleu@yahoo.com> - 2014-12-21 05:55 -0800
                Re: Pointer to structure BartC <bc@freeuk.com> - 2014-12-21 14:31 +0000
                  Re: Pointer to structure Siri Crews <chine.bleu@yahoo.com> - 2014-12-21 06:47 -0800
                    Re: Pointer to structure BartC <bc@freeuk.com> - 2014-12-21 20:10 +0000
                  Re: Pointer to structure Geoff <geoff@invalid.invalid> - 2014-12-21 10:00 -0800
                    Re: Pointer to structure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-21 22:44 +0000
                  Re: Pointer to structure raltbos@xs4all.nl (Richard Bos) - 2014-12-21 18:01 +0000
                    Re: Pointer to structure BartC <bc@freeuk.com> - 2014-12-21 21:21 +0000
                      Re: Pointer to structure raltbos@xs4all.nl (Richard Bos) - 2014-12-22 12:11 +0000
                    Re: Pointer to structure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-21 22:36 +0000
                Re: Pointer to structure Stephen Sprunk <stephen@sprunk.org> - 2014-12-27 17:56 -0600
                  Re: Pointer to structure Siri Crews <chine.bleu@yahoo.com> - 2014-12-27 16:33 -0800
                    Re: Pointer to structure Stephen Sprunk <stephen@sprunk.org> - 2015-01-15 12:29 -0600
              Re: Pointer to structure glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-22 00:50 +0000
                Re: Pointer to structure Richard Damon <Richard@Damon-Family.org> - 2014-12-21 20:19 -0500
                  Re: Pointer to structure glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-22 06:23 +0000
                    Re: Pointer to structure gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-22 12:03 +0000
            Re: Pointer to structure gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-21 13:20 +0000
              Re: Pointer to structure Siri Crews <chine.bleu@yahoo.com> - 2014-12-21 05:40 -0800
    Re: Pointer to structure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-21 13:16 +0000
    Re: Pointer to structure Barry Schwarz <schwarzb@dqel.com> - 2014-12-21 10:02 -0800
    Re: Pointer to structure Keith Thompson <kst-u@mib.org> - 2014-12-21 12:25 -0800
      Re: Pointer to structure Dexterr <dejangru@gmail.com> - 2014-12-21 15:07 -0800

Page 1 of 2  [1] 2  Next page →

#55178 — Pointer to structure

typedef struct _PascalString_
{
  int size;
  char* string;
}PString;

int main()
{
  PString* str = malloc(sizeof(struct _PascalString_));
    
  str = malloc(sizeof(struct _PascalString_));
  
 
  str->string = malloc(sizeof(char) * str->size);
  
  
  str->size = 9;
  str->string = malloc(sizeof(char) * str->size);
  str->string = "Tennessee";
  
  
  printf("%s\n", str->string);
    
  return 0;
}

I have a problem with understanding a structures. For instance, this code works, but usually we sholud write something like this:

 PString some_str; 

 PString *str;

 str = &some_str;

 str->string = "Tennessee";

Why is that ?

[toc] | [next] | [standalone]

#55180

On 21/12/2014 11:16, Dexterr wrote:
> typedef struct _PascalString_
> {
>    int size;
>    char* string;
> }PString;

Not quite a Pascal string then (which apparently uses a single-byte 
count followed immediately by space for 255 characters, no matter what 
the actual length of the string. See post by Geoff.)

This is just a simple form of counted string object.

> int main()
> {
>    PString* str = malloc(sizeof(struct _PascalString_));
>
>    str = malloc(sizeof(struct _PascalString_));
>
>
>    str->string = malloc(sizeof(char) * str->size);
>
>
>    str->size = 9;
>    str->string = malloc(sizeof(char) * str->size);
>    str->string = "Tennessee";
>
>
>    printf("%s\n", str->string);
>
>    return 0;
> }
>
> I have a problem with understanding a structures. For instance, this code works, but usually we sholud write something like this:
>
>   PString some_str;
>
>   PString *str;
>
>   str = &some_str;
>
>   str->string = "Tennessee";
>
> Why is that ?

Since Pstring only contains two short elements (probably totalling 8 
bytes), it's pointless allocating memory for it on the heap.

Just use:

   Pstring str;

   str.string = "Tenessee"
   str.size = strlen(str.string);

But:

* You wouldn't normally use it like this; create instead a function 
which takes a normal C string and returns a Pstring object

* It's problematic just assigning a string constant like this, if you 
will also sometimes have strings allocated using malloc(). You won't 
know which is which when you have to free, extend or replace the 
contents of the string. So perhaps have all strings allocated via 
malloc() or have a flag indicating if this was malloc-allocated.

-- 
Bartc

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

#55181

In article <%Lylw.534246$CW3.84569@fx07.am4>, BartC <bc@freeuk.com> wrote:

> On 21/12/2014 11:16, Dexterr wrote:
> > typedef struct _PascalString_
> > {
> >    int size;
> >    char* string;
> > }PString;
> 
> Not quite a Pascal string then (which apparently uses a single-byte 
> count followed immediately by space for 255 characters, no matter what 
> the actual length of the string. See post by Geoff.)

That was the usual limit back when 65536 bytes of ram were a huge expanse nobody 
in their right programming could ever exhaust.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
Be sure not to operate heavy machinery whilst on usenet.

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

#55182

On 21/12/2014 12:39, Siri Crews wrote:
> In article <%Lylw.534246$CW3.84569@fx07.am4>, BartC <bc@freeuk.com> wrote:
>
>> On 21/12/2014 11:16, Dexterr wrote:
>>> typedef struct _PascalString_
>>> {
>>>     int size;
>>>     char* string;
>>> }PString;
>>
>> Not quite a Pascal string then (which apparently uses a single-byte
>> count followed immediately by space for 255 characters, no matter what
>> the actual length of the string. See post by Geoff.)
>
> That was the usual limit back when 65536 bytes of ram were a huge expanse nobody
> in their right programming could ever exhaust.

Odd then to use a whole 256 bytes for *every* string!

-- 
Bartc

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

#55184

In article <Iuzlw.227520$p95.10761@fx38.am4>, BartC <bc@freeuk.com> wrote:

> On 21/12/2014 12:39, Siri Crews wrote:
> > In article <%Lylw.534246$CW3.84569@fx07.am4>, BartC <bc@freeuk.com> wrote:
> >
> >> On 21/12/2014 11:16, Dexterr wrote:
> >>> typedef struct _PascalString_
> >>> {
> >>>     int size;
> >>>     char* string;
> >>> }PString;
> >>
> >> Not quite a Pascal string then (which apparently uses a single-byte
> >> count followed immediately by space for 255 characters, no matter what
> >> the actual length of the string. See post by Geoff.)
> >
> > That was the usual limit back when 65536 bytes of ram were a huge expanse 
> > nobody
> > in their right programming could ever exhaust.
> 
> Odd then to use a whole 256 bytes for *every* string!

We didn't. The byte count could be up to 255 but the actual string size 
depending on need. 80 was a common size.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
Be sure not to operate heavy machinery whilst on usenet.

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

#55185

On 21/12/2014 13:05, Siri Crews wrote:
> In article <Iuzlw.227520$p95.10761@fx38.am4>, BartC <bc@freeuk.com> wrote:
>
>> On 21/12/2014 12:39, Siri Crews wrote:
>>> In article <%Lylw.534246$CW3.84569@fx07.am4>, BartC <bc@freeuk.com> wrote:
>>>
>>>> On 21/12/2014 11:16, Dexterr wrote:
>>>>> typedef struct _PascalString_
>>>>> {
>>>>>      int size;
>>>>>      char* string;
>>>>> }PString;
>>>>
>>>> Not quite a Pascal string then (which apparently uses a single-byte
>>>> count followed immediately by space for 255 characters, no matter what
>>>> the actual length of the string. See post by Geoff.)
>>>
>>> That was the usual limit back when 65536 bytes of ram were a huge expanse
>>> nobody
>>> in their right programming could ever exhaust.
>>
>> Odd then to use a whole 256 bytes for *every* string!
>
> We didn't. The byte count could be up to 255 but the actual string size
> depending on need. 80 was a common size.

In that case what *would* be an equivalent C data structure? Would it 
need to be different for every possible string length?

(The last time I used Pascal, we also used 80-character strings (but had 
more than 64KB). I don't remember anything about a length field. Using 
different sizes didn't work as Pascal's type system, although admirable 
in some ways, would ensure that a 70-character string was incompatible 
with an 80-character one!)

-- 
Bartc

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

#55191

In article <lHzlw.145625$c73.56007@fx27.am4>, BartC <bc@freeuk.com> wrote:

> On 21/12/2014 13:05, Siri Crews wrote:
> > In article <Iuzlw.227520$p95.10761@fx38.am4>, BartC <bc@freeuk.com> wrote:
> >
> >> On 21/12/2014 12:39, Siri Crews wrote:
> >>> In article <%Lylw.534246$CW3.84569@fx07.am4>, BartC <bc@freeuk.com> wrote:
> >>>
> >>>> On 21/12/2014 11:16, Dexterr wrote:
> >>>>> typedef struct _PascalString_
> >>>>> {
> >>>>>      int size;
> >>>>>      char* string;
> >>>>> }PString;
> >>>>
> >>>> Not quite a Pascal string then (which apparently uses a single-byte
> >>>> count followed immediately by space for 255 characters, no matter what
> >>>> the actual length of the string. See post by Geoff.)
> >>>
> >>> That was the usual limit back when 65536 bytes of ram were a huge expanse
> >>> nobody
> >>> in their right programming could ever exhaust.
> >>
> >> Odd then to use a whole 256 bytes for *every* string!
> >
> > We didn't. The byte count could be up to 255 but the actual string size
> > depending on need. 80 was a common size.
> 
> In that case what *would* be an equivalent C data structure? Would it 
> need to be different for every possible string length?

    unsigned char pstring[];

Free clue: the maximum string length of 255 is exactly the same as the maximum 
value of an eight bit unsigned char. Instead of using the last character+1 as an 
end of string mark (0), the first character-1 was the current length.

It's really not that complicated. You can even do the same trick today.

> (The last time I used Pascal, we also used 80-character strings (but had 
> more than 64KB). I don't remember anything about a length field. Using 
> different sizes didn't work as Pascal's type system, although admirable 
> in some ways, would ensure that a 70-character string was incompatible 
> with an 80-character one!)

It depends on the Pascal. UCSD and Borland Pascal had a generic string type 
STRING(N) with N from 1 to 255, N was the maximum string length the variable 
could hold; by itself STRING was indefinite size but assumed large enough for 
whatever was assigned to it. The current actual length of the string was stored 
in the first byte.

You could do that today. Or the first byte is the maximum length and the second 
byte the current length. Or even multiple byte lengths. You could require all 
strings be UTF-8 encoded, and store 0x80+n in the first byte, where n is the 
number of length bytes, maximum length, current length, and UTF-8 characters. 
And a string that starts with a zero byte is an empty string; a string that 
starts with any other valid UTF-8 byte is a zero terminated string. And all pass 
around as char*. That would let you use legacy ASCII and UTF-8 strings and new 
counted length strings transparently.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
Be sure not to operate heavy machinery whilst on usenet.

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

#55196

On 21/12/2014 13:55, Siri Crews wrote:
> In article <lHzlw.145625$c73.56007@fx27.am4>, BartC <bc@freeuk.com> wrote:
>
>> On 21/12/2014 13:05, Siri Crews wrote:
>>> In article <Iuzlw.227520$p95.10761@fx38.am4>, BartC <bc@freeuk.com> wrote:
>>>

>>>> Odd then to use a whole 256 bytes for *every* string!
>>>
>>> We didn't. The byte count could be up to 255 but the actual string size
>>> depending on need. 80 was a common size.
>>
>> In that case what *would* be an equivalent C data structure? Would it
>> need to be different for every possible string length?
>
>      unsigned char pstring[];
>
> Free clue: the maximum string length of 255 is exactly the same as the maximum
> value of an eight bit unsigned char. Instead of using the last character+1 as an
> end of string mark (0), the first character-1 was the current length.
>
> It's really not that complicated. You can even do the same trick today.

It might be that complicated!

How do you copy one pstring to another? The first byte will give the 
current length, but not the maximum that has been allocated; how will it 
know how much to copy? Or are we back to allocating 256 bytes every time?

As I understand it, it would need to be something like this:

typedef struct {
   unsigned char length;
   char str[80];
} p_string80;

Which also inherits some of the same problems (not compatible with a 
p_string70 for example). But at least you can now do:

p_string80 s,t;

  s = t;

-- 
Bartc

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

#55198

In article <rRAlw.160024$812.50144@fx20.am4>, BartC <bc@freeuk.com> wrote:

Bloody 'eck.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
Be sure not to operate heavy machinery whilst on usenet.

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

#55229

On 21/12/2014 14:47, Siri Crews wrote:
> In article <rRAlw.160024$812.50144@fx20.am4>, BartC <bc@freeuk.com> wrote:
>
> Bloody 'eck.

OK, so you strongly disagreed with something I wrote.

I wonder what it was? (Whatever it was, it must have been offensive too 
for it to be obliterated like that!)


-- 
Bartc

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

#55218

On Sun, 21 Dec 2014 14:31:50 +0000, BartC <bc@freeuk.com> wrote:

>On 21/12/2014 13:55, Siri Crews wrote:
>> In article <lHzlw.145625$c73.56007@fx27.am4>, BartC <bc@freeuk.com> wrote:
>>
>>> On 21/12/2014 13:05, Siri Crews wrote:
>>>> In article <Iuzlw.227520$p95.10761@fx38.am4>, BartC <bc@freeuk.com> wrote:
>>>>
>
>>>>> Odd then to use a whole 256 bytes for *every* string!
>>>>
>>>> We didn't. The byte count could be up to 255 but the actual string size
>>>> depending on need. 80 was a common size.
>>>
>>> In that case what *would* be an equivalent C data structure? Would it
>>> need to be different for every possible string length?
>>
>>      unsigned char pstring[];
>>
>> Free clue: the maximum string length of 255 is exactly the same as the maximum
>> value of an eight bit unsigned char. Instead of using the last character+1 as an
>> end of string mark (0), the first character-1 was the current length.
>>
>> It's really not that complicated. You can even do the same trick today.
>
>It might be that complicated!
>
>How do you copy one pstring to another? The first byte will give the 
>current length, but not the maximum that has been allocated; how will it 
>know how much to copy? Or are we back to allocating 256 bytes every time?
>
>As I understand it, it would need to be something like this:
>
>typedef struct {
>   unsigned char length;
>   char str[80];
>} p_string80;
>
>Which also inherits some of the same problems (not compatible with a 
>p_string70 for example). But at least you can now do:
>
>p_string80 s,t;
>
>  s = t;

From the UCSD sources:


;***** String vars

; A String is...
;   The first byte contains the current number of characters
;     in the string.  (0..declared_size)
;   The next bytes are those characters, with garbage fill
;     out to the declared_size of the string.
;
;   Declared_size (<= 255) is in the instruction stream
;     for instructions that need to know.




In UCSD Pascal a string was declared before use and the declared size
was the limit of the length of that string. If the number of
characters was less than the declared length of the string the
remainder of the array contained garbage. Concatenation involved
appending chars to the destination up to the declared size of the
destination. In no case could a string exceed 255 characters.
Declaring a string size greater than 255 was an error and
concatenation past this limit was an error. The length of an empty
string was 1 character; the string[0] member containing a 0.

Yes, it was wasteful of memory considering the machines of the day.

program Demo (Input, Output)

var
	Str : String(100)

begin
	Str := 'This is less than 100 chars';
	WriteLn(Str);
	Str := Str + 'adding some more';
	WriteLn(Str);
end.


I believe some modern Pascals no longer have this 255 character
limitation but this would mean the structure of a "Pascal string" is
no longer a pure array of char with the length being the first char of
the array.

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

#55260

Geoff <geoff@invalid.invalid> writes:
<snip>
> In UCSD Pascal a string was [...]
<snip>
> [...]  The length of an empty
> string was 1 character; the string[0] member containing a 0.
>
> Yes, it was wasteful of memory considering the machines of the day.

It was worse than that because p-code (the UCSD compilation target) used
words so an empty string used two bytes!

<snip>
-- 
Ben.

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

#55219

BartC <bc@freeuk.com> wrote:

> How do you copy one pstring to another? The first byte will give the 
> current length, but not the maximum that has been allocated; how will it 
> know how much to copy?

You don't. _It_ does, underneath the hood. Remember that this is not a
Standard Pascal feature; it's a common but not completely standardised
extension. (It may have made it into Pascal Extended; I never looked
enough into that /contradictio in terminis/ to know or care.) Some
implementations may have had yet a third member; some may have just
crashed if you cross the borders. In any case, length-indicated strings
are a Wrong Idea all 'round.

Richard

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

#55235

On 21/12/2014 18:01, Richard Bos wrote:
> BartC <bc@freeuk.com> wrote:
>
>> How do you copy one pstring to another? The first byte will give the
>> current length, but not the maximum that has been allocated; how will it
>> know how much to copy?
>
> You don't. _It_ does, underneath the hood. Remember that this is not a
> Standard Pascal feature; it's a common but not completely standardised
> extension.

I was commenting about this:

  unsigned char pstring[];

which looks nearer C than Pascal! The original Pascal will know the 
maximum length as it's part of the type (so is implicit in the 
underlying data structure). The C version won't have that, so can only 
work if the maximum length is a constant value throughout the program, 
or is added as part of the code that works with these arrays.

> (It may have made it into Pascal Extended; I never looked
> enough into that /contradictio in terminis/ to know or care.) Some
> implementations may have had yet a third member; some may have just
> crashed if you cross the borders. In any case, length-indicated strings
> are a Wrong Idea all 'round.

(No, they're a good idea in the right language, with several advantages. 
But I admit they are a bit of a pain in C.)

-- 
Bartc

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

#55273

BartC <bc@freeuk.com> wrote:

> On 21/12/2014 18:01, Richard Bos wrote:
> > BartC <bc@freeuk.com> wrote:
> >
> >> How do you copy one pstring to another? The first byte will give the
> >> current length, but not the maximum that has been allocated; how will it
> >> know how much to copy?
> >
> > You don't. _It_ does, underneath the hood. Remember that this is not a
> > Standard Pascal feature; it's a common but not completely standardised
> > extension.
> 
> I was commenting about this:
> 
>   unsigned char pstring[];
> 
> which looks nearer C than Pascal! The original Pascal will know the 
> maximum length as it's part of the type (so is implicit in the 
> underlying data structure). The C version won't have that, so can only 
> work if the maximum length is a constant value throughout the program, 
> or is added as part of the code that works with these arrays.

Exactly. So this is an inferior solution, and the OP should learn to
work with real C strings already.

> > (It may have made it into Pascal Extended; I never looked
> > enough into that /contradictio in terminis/ to know or care.) Some
> > implementations may have had yet a third member; some may have just
> > crashed if you cross the borders. In any case, length-indicated strings
> > are a Wrong Idea all 'round.
> 
> (No, they're a good idea in the right language, with several advantages. 
> But I admit they are a bit of a pain in C.)

They have a built-in limit to the string length, and require extra
behind-the-scenes bookkeeping from the compiler _even though_ you're
expected to do the other half of it yourself. That's not a good idea in
any language.

Richard

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

#55262

raltbos@xs4all.nl (Richard Bos) writes:

> BartC <bc@freeuk.com> wrote:
>
>> How do you copy one pstring to another? The first byte will give the 
>> current length, but not the maximum that has been allocated; how will it 
>> know how much to copy?
>
> You don't. _It_ does, underneath the hood. Remember that this is not a
> Standard Pascal feature; it's a common but not completely standardised
> extension. (It may have made it into Pascal Extended; I never looked
> enough into that /contradictio in terminis/ to know or care.)

It did make it in.

<snip>
-- 
Ben.

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

#55527

On 21-Dec-14 07:55, Siri Crews wrote:
> You could require all strings be UTF-8 encoded, and store 0x80+n in
> the first byte, where n is the number of length bytes, maximum
> length, current length, and UTF-8 characters. And a string that
> starts with a zero byte is an empty string; a string that starts with
> any other valid UTF-8 byte is a zero terminated string. And all pass
> around as char*. That would let you use legacy ASCII and UTF-8
> strings and new counted length strings transparently.

There are only two invalid code units for UTF-8, so how are you supposed
to know by examining the first byte whether the string is NUL-terminated
UTF-8 or "counted length"?

Even ignoring that, there are many other character encodings, and many
of them have _no_ invalid values that you could hijack.  The world is
not all UTF-8, unfortunately, and ASCII is pretty much irrelevant these
days.  (Much of the world is now "UTF-16", though a large fraction of
that is actually UCS-2; even "UTF-8" is often CESU-8, though that's
mostly a result of broken "UTF-16" systems.)

In-band signaling is nearly always a bad idea; if you want to use
counted length strings, just use the struct hack, and then you don't
have to worry about accidentally passing one to a function that is
expecting a NUL-terminated string or vice versa.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#55529

In article <m7ngun$pfa$1@dont-email.me>, Stephen Sprunk <stephen@sprunk.org> 
wrote:

> There are only two invalid code units for UTF-8, so how are you supposed
> to know by examining the first byte whether the string is NUL-terminated
> UTF-8 or "counted length"?

0x80 - 0xBFF are all invalid when not following an byte 0xC0 - 0xFB.

> not all UTF-8, unfortunately, and ASCII is pretty much irrelevant these
> days.  (Much of the world is now "UTF-16", though a large fraction of

Does that mean most C compilers now use 16-bit char?

> In-band signaling is nearly always a bad idea; if you want to use

Do you mean like marking the end of a string with a zero?

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
Be sure not to operate heavy machinery whilst on usenet.

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

#56310

On 27-Dec-14 18:33, Siri Crews wrote:
> Stephen Sprunk <stephen@sprunk.org> wrote:
>> There are only two invalid code units for UTF-8, so how are you
>> supposed to know by examining the first byte whether the string is
>> NUL-terminated UTF-8 or "counted length"?
> 
> 0x80 - 0xBFF are all invalid when not following an byte 0xC0 - 0xFB.

Someone could have passed you a pointer into the middle of a UTF-8
string, which happened to split a character.  Yes, that's invalid, but
most libraries can deal with it since UTF-8 is self-synchronizing.

>> not all UTF-8, unfortunately, and ASCII is pretty much irrelevant
>> these days.  (Much of the world is now "UTF-16", though a large
>> fraction of
> 
> Does that mean most C compilers now use 16-bit char?

Windows and Java use UTF-16.  You can try to use UTF-8 with either, but
it's a mess because the system fights you at every step, resulting in
atrocities like CESU-8.

>> In-band signaling is nearly always a bad idea; if you want to use
> 
> Do you mean like marking the end of a string with a zero?

Yes, but that is so deeply entrenched in C that it'll never change.
Learn from others' mistakes rather than trying to replicate them.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#55248

BartC <bc@freeuk.com> wrote:
> On 21/12/2014 13:05, Siri Crews wrote:

(snip, someone wrote)
>>> Odd then to use a whole 256 bytes for *every* string!

>> We didn't. The byte count could be up to 255 but the actual 
>> string size depending on need. 80 was a common size.
 
> In that case what *would* be an equivalent C data structure? Would it 
> need to be different for every possible string length?

There is a common C trick, likely UB in the standard, but usually
works, to declare an array, usually [1] at the end of the struct,
and then allocate it an apprropriate amount of memory.

struct ps {
   char length;
   char data[1];
   }

int n=80;
struct ps *x=malloc(sizeof(*x)-1+n);
 
> (The last time I used Pascal, we also used 80-character strings (but had 
> more than 64KB). I don't remember anything about a length field. Using 
> different sizes didn't work as Pascal's type system, although admirable 
> in some ways, would ensure that a 70-character string was incompatible 
> with an 80-character one!)

-- glen

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web