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 2 of 2 — ← Prev page 1 [2]

#55258

On 12/21/14 7:50 PM, glen herrmannsfeldt wrote:
> 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
>

Actually, C99 codified something almost like this.


struct ps {
   unsigned char length;
   char data[]; // Note, empty brackets
};


struct ps *x = malloc(sizeof(*x) + n);
*x->length = n;

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

#55268

Richard Damon <Richard@damon-family.org> wrote:

(snip, I wrote)
>> 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);

(snip)

> Actually, C99 codified something almost like this.

Last time I used it was before 1999. 

Some years ago, I was using the Metagraphics package, which had
many structs that worked this way.
 
> struct ps {
>   unsigned char length;
>   char data[]; // Note, empty brackets
> };
 
> struct ps *x = malloc(sizeof(*x) + n);
> *x->length = n;

And it nicely avoids the -1 that is needed the other way.

-- glen

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

#55272

In article <m78dd2$dvn$1@speranza.aioe.org>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>Richard Damon <Richard@damon-family.org> wrote:
>
>(snip, I wrote)
>>> 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.

BTW, this is commonly known as "the struct hack".

I mentioned it (by that name) in my recent seminal post on this thread.

No thanks are needed.  Cash is always welcome.

-- 

    "This ain't my first time at the rodeo"

is a line from the movie, Mommie Dearest, said by Joan Crawford at a board meeting.

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

#55187

In article <chine.bleu-CBB10B.05052221122014@news.eternal-september.org>,
Siri Crews  <chine.bleu@yahoo.com> 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.

The point is that if you implement it the way that's being bandied about in
this thread, i.e.:

    struct pstring { char length;char str[255]; }

then you do - you use 256 bytes for every such object.

If you do it the other way, i.e.:

    struct pstring { char length;char *str; }

which is the normal C way of doing things, you don't get the same
representation as a true "Pascal string".

What you need is a variation of the first method with some version of the
"struct hack" (or its "standardized" equivalent(s)).  This allows you to
malloc (and subsequent realloc) just what you need.

-- 
    Nov 4, 2008 - the day when everything went
    from being Clinton's fault to being Obama's fault.

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

#55189

> The point is that if you implement it the way that's being bandied about in
> this thread, i.e.:
> 
>     struct pstring { char length;char str[255]; }
> 
> then you do - you use 256 bytes for every such object.
> 
> If you do it the other way, i.e.:
> 
>     struct pstring { char length;char *str; }

Actually it was implemented as unsigned char[]

with
    pstrlen(pstring s) {return *s;}
    pstrcpy(pstring dd, pstring ss) {memcpy(dd, ss, *ss+1);}

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

#55186

Dexterr <dejangru@gmail.com> writes:

> typedef struct _PascalString_

That's a reserved identifier (basically the implementation may decide
what it means in a way that messes with your meaning).  It's best to
avoid all names that start with an _ (though not all such names are
reserved).

> {
>   int size;
>   char* string;
> }PString;

There's a big unstated problem here.  'Pascal string' is not a
well-defined term.  String variables did not really exist in the
original Pascal where all you had were packed arrays of char, and this
definition persisted into ISO standard Pascal.  Then there are a large
number of Pascal-like languages, almost all of which introduced some
more useful form of string type.

UCSD Pascal was one of the first and may well have been the model for
all the others.  The system included a well-defined virtual machine
(p-code) that does specify the representation of a string.  It's
possible that with the exception of standard Pascal, all variations that
include a string type use the same representation but, if not, there may
be other good meanings for the term.

Anyway, a UCSD Pascal string looks like this is C:

  typedef struct {
      unsigned char length;
      char string_data[];
  } UCSD_P_String;

and a function to allocate one from a C string would look like this:

  UCSD_P_String *make_p_string(const char *str)
  {
       size_t len = strlen(str);
       UCSD_P_String *pstr = 0;
       if (len < 256 && (pstr = malloc(sizeof *pstr + len)) != NULL) {
            pstr->length = len;
            memcpy(pstr->string_data, str, len);
       }
       return pstr;
  }

though I would be tempted to allocate one more byte and copy the null
byte across.  Otherwise, you must remember to use the length properly
all the time.  For example, to print one, you need to say

  printf("%.*s", (int)pstr->length, pstr->string_data);

> int main()
> {
>   PString* str = malloc(sizeof(struct _PascalString_));
>     
>   str = malloc(sizeof(struct _PascalString_));

A neater (and less error-prone) syntax is:

   str = malloc(sizeof *str);
  
>   str->string = malloc(sizeof(char) * str->size);
>   
>   
>   str->size = 9;
>   str->string = malloc(sizeof(char) * str->size);
>   str->string = "Tennessee";

You allocate things multiple times, and then you overwrite the pointer
to the space you've allocated with a pointer to a statically allocated
string.

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

No, that's not usual, it's just a rather odd alternative.  If you can
(for reasons that relate to the overall design of the program) declare,
rather than allocate, your string objects, then there is no need to use
a pointer to them:

  PString some_str; 
  some_str.length = sizeof "Tennessee" - 1;
  some_str.string = "Tennessee";

or even

  PString some_str = { sizeof "Tennessee" - 1, "Tennessee" };

-- 
Ben.

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

#55220

On Sun, 21 Dec 2014 03:16:08 -0800 (PST), Dexterr <dejangru@gmail.com>
wrote:

>typedef struct _PascalString_
>{
>  int size;
>  char* string;
>}PString;
>
>int main()
>{
>  PString* str = malloc(sizeof(struct _PascalString_));
>    
>  str = malloc(sizeof(struct _PascalString_));

The allocation performed as part of initializing str is now a memory
leak.
 
>  str->string = malloc(sizeof(char) * str->size);

str->size contains an indeterminate value.
  
>  str->size = 9;
>  str->string = malloc(sizeof(char) * str->size);

The previous allocation of indeterminate size for str->string is now a
memory leak.

>  str->string = "Tennessee";

The previous allocation of 9 char is now a memory leak.
  
>  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:

One instance of undefined behavior and three memory leaks is not a
good definition of "this code works."

> PString some_str; 
>
> PString *str;
>
> str = &some_str;
>
> str->string = "Tennessee";

While all legal, you could just as easily use
     some_str.string = "Tennessee";
and discard the pointer completely.

>Why is that ?

Because you should avoid code that creates memory leaks and reject
outright any undefined behavior.

-- 
Remove del for email

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

#55231

Dexterr <dejangru@gmail.com> writes:
[code snipped]
>
> 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 ?

I'm glad to see that you've decided to show some effort this time.
Ordinarily I'd read your question and probably offer some advice.

But give your earlier rudeness, you'll get no help from me.

Insulting people you're asking for help is, shall we say, a
suboptimal strategy.  Actions have consequences.  Bye.

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

#55241

On Sunday, December 21, 2014 9:25:15 PM UTC+1, Keith Thompson wrote:
> Dexterr <dejangru@gmail.com> writes:
> [code snipped]
> >
> > 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 ?
> 
> I'm glad to see that you've decided to show some effort this time.
> Ordinarily I'd read your question and probably offer some advice.
> 
> But give your earlier rudeness, you'll get no help from me.
> 
> Insulting people you're asking for help is, shall we say, a
> suboptimal strategy.  Actions have consequences.  Bye.
> 
> -- 
> 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"

Bye.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web