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

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

Compatibility question

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

Contents

  Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-20 03:08 +0000
    Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-20 16:20 +1300
      Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-20 11:50 +0100
        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-20 11:41 -0700
          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 23:04 +0000
            Re: Compatibility question Barry Schwarz <schwarzb@dqel.com> - 2012-10-21 20:27 -0700
      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-20 04:01 +0000
        Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-21 09:26 +1300
          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 22:54 +0000
            Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-22 12:29 +1300
              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 23:50 +0000
                Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 02:27 +0100
                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 02:28 +0000
                    Re: Compatibility question Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-22 11:18 -0400
                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 16:19 +0000
                      Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:37 +0100
                        Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:40 +0100
                    Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:30 +0100
                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 17:23 +0000
                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 10:52 -0700
                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 18:42 +0000
                            Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 21:06 +0100
                              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 22:52 +0000
                                Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 03:33 +0100
                                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:28 +0000
                                    Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 16:45 +0100
                                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 17:53 +0000
                                      Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 12:41 -0700
                                        Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 21:28 +0100
                                      Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 20:57 +0100
                                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 12:26 -0700
                                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 20:39 +0000
                                    Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 15:53 -0700
                                      Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 00:57 +0100
                                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 20:06 -0700
                                          Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 11:18 +0100
                                            Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 12:04 -0700
                                              Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 23:10 +0100
                                                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:58 -0700
                                                  Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-25 01:46 +0100
                                                    Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 19:40 -0700
                                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-24 20:20 +0000
                                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 14:38 -0700
                                          Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-24 17:55 -0400
                                            Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:29 -0700
                                        Re: Compatibility question Greg Martin <greg@softsprocket.com> - 2012-10-24 15:21 -0700
                                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-26 03:30 +0000
                                            Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-26 13:02 +0100
                                              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-27 00:04 +0000
                                                Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-27 20:15 +0100
                                                Re: Compatibility question Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-10-27 16:36 -0600
                                                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-28 17:36 +0000
                                          Re: Compatibility question Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-10-27 22:42 +0300
                                            Re: Compatibility question Greg Martin <greg@softsprocket.com> - 2012-10-27 14:30 -0700
                                              Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-27 22:57 +0100
                                                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 17:04 -0700
                                                  Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 17:14 -0700
                                                    Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 18:04 -0700
                                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:46 -0700
                                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-25 01:18 +0000
                                    Re: Compatibility question Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-10-27 21:08 +0300
                                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-28 17:38 +0000
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:38 +0100
                            Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 16:50 -0700
                              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:33 +0000
                        Re: Compatibility question Öö Tiib <ootiib@hot.ee> - 2012-10-22 14:23 -0700
                          Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-22 17:26 -0400
                          Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-23 10:55 +1300
                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 23:27 +0000
                        Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-22 22:44 +0100
                          Re: Compatibility question Les Cargill <lcargill99@comcast.com> - 2012-10-22 17:15 -0500
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:13 +0100
                          Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-22 18:35 -0400
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:14 +0100
                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 23:42 +0000
                            Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-23 13:35 +1300
                          Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 17:01 -0700
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 01:47 +0100
                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-21 19:27 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#27400 — Compatibility question

I have been using structures containing zero-length arrays as a means
of combining descriptors and array data in a single allocation unit.
Something like the following is a common idiom:

struct foo {
   int     a, b;
   size_t  len;
   char    p[0];
};

struct foo *q;


For the noobs, q->p[x] is obviously convenient, however before gcc
supported zero-length arrays, the arrangement would be something like
this:

struct foo {
   int     a, b;
   size_t  len;
};

struct foo *q;
char *x;

In this instance, assuming that the array of char is intended to be
available immediately following struct foo, the access is done as
follows:

*((char *)(q + 1)) = ' ';

So far, so good.  My questions regards the availability of zero-length
arrays in common systems.  That is, if I wish my code to be compatible
with most C compilers in use today, should I worry about avoiding
zero-length arrays, or is the feature old enough, with sufficient
prevalence to make it's use reasonable in portable code?



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

[toc] | [next] | [standalone]

#27401

On 10/20/12 16:08, Steve Thompson wrote:
> I have been using structures containing zero-length arrays as a means
> of combining descriptors and array data in a single allocation unit.
> Something like the following is a common idiom:
>
> struct foo {
>     int     a, b;
>     size_t  len;
>     char    p[0];
> };

That should really be

     char    p[];

Which is the standardised (as of C99) form of the struct hack.

> So far, so good.  My questions regards the availability of zero-length
> arrays in common systems.  That is, if I wish my code to be compatible
> with most C compilers in use today, should I worry about avoiding
> zero-length arrays, or is the feature old enough, with sufficient
> prevalence to make it's use reasonable in portable code?

Most compilers should support the standard form, or the zero length 
array form of the struct hack.

-- 
Ian Collins

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

#27407

Ian Collins <ian-news@hotmail.com> writes:

> On 10/20/12 16:08, Steve Thompson wrote:
>> I have been using structures containing zero-length arrays as a means
>> of combining descriptors and array data in a single allocation unit.
>> Something like the following is a common idiom:
>>
>> struct foo {
>>     int     a, b;
>>     size_t  len;
>>     char    p[0];
>> };
>
> That should really be
>
>     char    p[];
>
> Which is the standardised (as of C99) form of the struct hack.
>
>> So far, so good.  My questions regards the availability of zero-length
>> arrays in common systems.  That is, if I wish my code to be compatible
>> with most C compilers in use today, should I worry about avoiding
>> zero-length arrays, or is the feature old enough, with sufficient
>> prevalence to make it's use reasonable in portable code?
>
> Most compilers should support the standard form, or the zero length
> array form of the struct hack.

Before C99, the usual form was a one-element array -- a small amount of
waste, but guaranteed to compile everywhere.  A zero-length array is a
constraint violation so, of the three options (p[], p[1] and p[0]) it is
the most likely to give a compiler stomach ache.

Lots of part of C99 (such as // comments) are nearly ubiquitous, even in
the Microsoft world, but I don't know how wide-spread p[] is.

-- 
Ben.

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

#27418

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Ian Collins <ian-news@hotmail.com> writes:
>> On 10/20/12 16:08, Steve Thompson wrote:
>>> I have been using structures containing zero-length arrays as a means
>>> of combining descriptors and array data in a single allocation unit.
>>> Something like the following is a common idiom:
>>>
>>> struct foo {
>>>     int     a, b;
>>>     size_t  len;
>>>     char    p[0];
>>> };
>>
>> That should really be
>>
>>     char    p[];
>>
>> Which is the standardised (as of C99) form of the struct hack.
>>
>>> So far, so good.  My questions regards the availability of zero-length
>>> arrays in common systems.  That is, if I wish my code to be compatible
>>> with most C compilers in use today, should I worry about avoiding
>>> zero-length arrays, or is the feature old enough, with sufficient
>>> prevalence to make it's use reasonable in portable code?
>>
>> Most compilers should support the standard form, or the zero length
>> array form of the struct hack.
>
> Before C99, the usual form was a one-element array -- a small amount of
> waste, but guaranteed to compile everywhere.  A zero-length array is a
> constraint violation so, of the three options (p[], p[1] and p[0]) it is
> the most likely to give a compiler stomach ache.
>
> Lots of part of C99 (such as // comments) are nearly ubiquitous, even in
> the Microsoft world, but I don't know how wide-spread p[] is.

Microsoft's C compiler, which is notorious for its lack of C99 support,
does support flexible array members -- but only if you enable "language
extensions".  (I'm using Microsoft Visual C++ 2010 Express.)

So my advice is to go ahead and use the C99 feature p[] in preference to
either p[0] (which is a constraint violation in C90, C99, and C11) or
p[1] (which is a valid declaration, but accessing elements past p[0],
strictly speaking, has undefined behavior.)

If you're concerned about C90 compatility, you'll need to decide which
form is more portable *to the compilers you're using*.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#27479

On Sat, Oct 20, 2012 at 11:41:09AM -0700, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> > Ian Collins <ian-news@hotmail.com> writes:
> >> On 10/20/12 16:08, Steve Thompson wrote:
> >>> I have been using structures containing zero-length arrays as a means
> >>> of combining descriptors and array data in a single allocation unit.
> >>> Something like the following is a common idiom:
> >>>
> >>> struct foo {
> >>>     int     a, b;
> >>>     size_t  len;
> >>>     char    p[0];
> >>> };
> >>
> >> That should really be
> >>
> >>     char    p[];
> >>
> >> Which is the standardised (as of C99) form of the struct hack.
> >>
> >>> So far, so good.  My questions regards the availability of zero-length
> >>> arrays in common systems.  That is, if I wish my code to be compatible
> >>> with most C compilers in use today, should I worry about avoiding
> >>> zero-length arrays, or is the feature old enough, with sufficient
> >>> prevalence to make it's use reasonable in portable code?
> >>
> >> Most compilers should support the standard form, or the zero length
> >> array form of the struct hack.
> >
> > Before C99, the usual form was a one-element array -- a small amount of
> > waste, but guaranteed to compile everywhere.  A zero-length array is a
> > constraint violation so, of the three options (p[], p[1] and p[0]) it is
> > the most likely to give a compiler stomach ache.
> >
> > Lots of part of C99 (such as // comments) are nearly ubiquitous, even in
> > the Microsoft world, but I don't know how wide-spread p[] is.
> 
> Microsoft's C compiler, which is notorious for its lack of C99 support,
> does support flexible array members -- but only if you enable "language
> extensions".  (I'm using Microsoft Visual C++ 2010 Express.)
> 
> So my advice is to go ahead and use the C99 feature p[] in preference to
> either p[0] (which is a constraint violation in C90, C99, and C11) or
> p[1] (which is a valid declaration, but accessing elements past p[0],
> strictly speaking, has undefined behavior.)

The p[1] form is a bit of an eyesore since the actual structure I am
using may have its "data area" appended to the structure, or it may be
somewhere else.
 
> If you're concerned about C90 compatility, you'll need to decide which
> form is more portable *to the compilers you're using*.

I would have preferred to maintain compatibility with older compilers,
but I am finding that some modern features are necessary for my
application.  Nothing is yet carved in stone; my application might be
able to function without POSIX threads in a hypothetical lobotomized
version, but I won't know until I'm further along.  Part of it is a
library, and of course many of the functions have nothing to do with
thread operations, so there may be a case for maintaining a certain
degree of compatibility.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27483

On Sun, 21 Oct 2012 23:04:16 +0000, Steve Thompson
<stevet810@gmail.com> wrote:

>On Sat, Oct 20, 2012 at 11:41:09AM -0700, Keith Thompson wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> > Ian Collins <ian-news@hotmail.com> writes:
>> >> On 10/20/12 16:08, Steve Thompson wrote:
>> >>> I have been using structures containing zero-length arrays as a means
>> >>> of combining descriptors and array data in a single allocation unit.
>> >>> Something like the following is a common idiom:
>> >>>
>> >>> struct foo {
>> >>>     int     a, b;
>> >>>     size_t  len;
>> >>>     char    p[0];
>> >>> };
>> >>
>> >> That should really be
>> >>
>> >>     char    p[];
>> >>
>> >> Which is the standardised (as of C99) form of the struct hack.
>> >>
>> >>> So far, so good.  My questions regards the availability of zero-length
>> >>> arrays in common systems.  That is, if I wish my code to be compatible
>> >>> with most C compilers in use today, should I worry about avoiding
>> >>> zero-length arrays, or is the feature old enough, with sufficient
>> >>> prevalence to make it's use reasonable in portable code?
>> >>
>> >> Most compilers should support the standard form, or the zero length
>> >> array form of the struct hack.
>> >
>> > Before C99, the usual form was a one-element array -- a small amount of
>> > waste, but guaranteed to compile everywhere.  A zero-length array is a
>> > constraint violation so, of the three options (p[], p[1] and p[0]) it is
>> > the most likely to give a compiler stomach ache.
>> >
>> > Lots of part of C99 (such as // comments) are nearly ubiquitous, even in
>> > the Microsoft world, but I don't know how wide-spread p[] is.
>> 
>> Microsoft's C compiler, which is notorious for its lack of C99 support,
>> does support flexible array members -- but only if you enable "language
>> extensions".  (I'm using Microsoft Visual C++ 2010 Express.)
>> 
>> So my advice is to go ahead and use the C99 feature p[] in preference to
>> either p[0] (which is a constraint violation in C90, C99, and C11) or
>> p[1] (which is a valid declaration, but accessing elements past p[0],
>> strictly speaking, has undefined behavior.)
>
>The p[1] form is a bit of an eyesore since the actual structure I am
>using may have its "data area" appended to the structure, or it may be
>somewhere else.

How could p[1] be any more of an eyesore than p[0] or p[]?

How does p[0] allow you to put the data area somewhere else?

-- 
Remove del for email

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

#27410

On Sat, Oct 20, 2012 at 04:20:53PM +1300, Ian Collins wrote:
> On 10/20/12 16:08, Steve Thompson wrote:
> >I have been using structures containing zero-length arrays as a means
> >of combining descriptors and array data in a single allocation unit.
> >Something like the following is a common idiom:
> >
> >struct foo {
> >    int     a, b;
> >    size_t  len;
> >    char    p[0];
> >};
> 
> That should really be
> 
>     char    p[];
> 
> Which is the standardised (as of C99) form of the struct hack.
> 
> >So far, so good.  My questions regards the availability of zero-length
> >arrays in common systems.  That is, if I wish my code to be compatible
> >with most C compilers in use today, should I worry about avoiding
> >zero-length arrays, or is the feature old enough, with sufficient
> >prevalence to make it's use reasonable in portable code?
> 
> Most compilers should support the standard form, or the zero length 
> array form of the struct hack.

I was mainly wondering what the cutoff date was for this feature.  If
C compilers deployed within the last ten years or so support the p[0]
idiom, I won't feel as if I'm excluding platforms that might otherwise
be expected to run my code.  The workaround is not a huge problem
since the accesses will be insulated from the user by my functions,
but it is less trouble to write if I don't have to cast everything.




Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27426

On 10/20/12 17:01, Steve Thompson wrote:
> On Sat, Oct 20, 2012 at 04:20:53PM +1300, Ian Collins wrote:
>> On 10/20/12 16:08, Steve Thompson wrote:
>>> I have been using structures containing zero-length arrays as a means
>>> of combining descriptors and array data in a single allocation unit.
>>> Something like the following is a common idiom:
>>>
>>> struct foo {
>>>     int     a, b;
>>>     size_t  len;
>>>     char    p[0];
>>> };
>>
>> That should really be
>>
>>      char    p[];
>>
>> Which is the standardised (as of C99) form of the struct hack.
>>
>>> So far, so good.  My questions regards the availability of zero-length
>>> arrays in common systems.  That is, if I wish my code to be compatible
>>> with most C compilers in use today, should I worry about avoiding
>>> zero-length arrays, or is the feature old enough, with sufficient
>>> prevalence to make it's use reasonable in portable code?
>>
>> Most compilers should support the standard form, or the zero length
>> array form of the struct hack.
>
> I was mainly wondering what the cutoff date was for this feature.  If
> C compilers deployed within the last ten years or so support the p[0]
> idiom, I won't feel as if I'm excluding platforms that might otherwise
> be expected to run my code.  The workaround is not a huge problem
> since the accesses will be insulated from the user by my functions,
> but it is less trouble to write if I don't have to cast everything.

As Ben pointed out, the pre-C99 form was a single element array.  I 
think the zero element array is a gcc extension.  So if you really want 
to support every possible compiler, use p[1] and document what you are 
doing.  Otherwise use the standard form.

-- 
Ian Collins

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

#27477

On Sun, Oct 21, 2012 at 09:26:54AM +1300, Ian Collins wrote:
> On 10/20/12 17:01, Steve Thompson wrote:
> >On Sat, Oct 20, 2012 at 04:20:53PM +1300, Ian Collins wrote:
> >>On 10/20/12 16:08, Steve Thompson wrote:
> >>>I have been using structures containing zero-length arrays as a means
> >>>of combining descriptors and array data in a single allocation unit.
> >>>Something like the following is a common idiom:
> >>>
> >>>struct foo {
> >>>    int     a, b;
> >>>    size_t  len;
> >>>    char    p[0];
> >>>};
> >>
> >>That should really be
> >>
> >>     char    p[];
> >>
> >>Which is the standardised (as of C99) form of the struct hack.
> >>
> >>>So far, so good.  My questions regards the availability of zero-length
> >>>arrays in common systems.  That is, if I wish my code to be compatible
> >>>with most C compilers in use today, should I worry about avoiding
> >>>zero-length arrays, or is the feature old enough, with sufficient
> >>>prevalence to make it's use reasonable in portable code?
> >>
> >>Most compilers should support the standard form, or the zero length
> >>array form of the struct hack.
> >
> >I was mainly wondering what the cutoff date was for this feature.  If
> >C compilers deployed within the last ten years or so support the p[0]
> >idiom, I won't feel as if I'm excluding platforms that might otherwise
> >be expected to run my code.  The workaround is not a huge problem
> >since the accesses will be insulated from the user by my functions,
> >but it is less trouble to write if I don't have to cast everything.
> 
> As Ben pointed out, the pre-C99 form was a single element array.  I 
> think the zero element array is a gcc extension.  So if you really want 
> to support every possible compiler, use p[1] and document what you are 
> doing.  Otherwise use the standard form.

Working on another part of the software I'm writing, I learned today
that I must use TLS.  There is no point trying to get around that
constraint, so the list of potential targets is going to shrink quite
a lot.

Now that I've noticed that the GCC documentation has been updated (I
may not have read that section for ten years, now that I think of it),
it does indeed say that the C99 standard includes support for flexible
arrays, with similar semantics to the old gcc zero subscript hack, so
I will use that.




Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27478

On 10/22/12 11:54, Steve Thompson wrote:
> On Sun, Oct 21, 2012 at 09:26:54AM +1300, Ian Collins wrote:
>> On 10/20/12 17:01, Steve Thompson wrote:
>>> On Sat, Oct 20, 2012 at 04:20:53PM +1300, Ian Collins wrote:
>>>> On 10/20/12 16:08, Steve Thompson wrote:
>>>>> I have been using structures containing zero-length arrays as a means
>>>>> of combining descriptors and array data in a single allocation unit.
>>>>> Something like the following is a common idiom:
>>>>>
>>>>> struct foo {
>>>>>     int     a, b;
>>>>>     size_t  len;
>>>>>     char    p[0];
>>>>> };
>>>>
>>>> That should really be
>>>>
>>>>      char    p[];
>>>>
>>>> Which is the standardised (as of C99) form of the struct hack.
>>>>
>>>>> So far, so good.  My questions regards the availability of zero-length
>>>>> arrays in common systems.  That is, if I wish my code to be compatible
>>>>> with most C compilers in use today, should I worry about avoiding
>>>>> zero-length arrays, or is the feature old enough, with sufficient
>>>>> prevalence to make it's use reasonable in portable code?
>>>>
>>>> Most compilers should support the standard form, or the zero length
>>>> array form of the struct hack.
>>>
>>> I was mainly wondering what the cutoff date was for this feature.  If
>>> C compilers deployed within the last ten years or so support the p[0]
>>> idiom, I won't feel as if I'm excluding platforms that might otherwise
>>> be expected to run my code.  The workaround is not a huge problem
>>> since the accesses will be insulated from the user by my functions,
>>> but it is less trouble to write if I don't have to cast everything.
>>
>> As Ben pointed out, the pre-C99 form was a single element array.  I
>> think the zero element array is a gcc extension.  So if you really want
>> to support every possible compiler, use p[1] and document what you are
>> doing.  Otherwise use the standard form.
>
> Working on another part of the software I'm writing, I learned today
> that I must use TLS.  There is no point trying to get around that
> constraint, so the list of potential targets is going to shrink quite
> a lot.

Times Literary Supplement?

> Now that I've noticed that the GCC documentation has been updated (I
> may not have read that section for ten years, now that I think of it),
> it does indeed say that the C99 standard includes support for flexible
> arrays, with similar semantics to the old gcc zero subscript hack, so
> I will use that.

You can't use a VLA as a structure member (how would you declare it?).

-- 
Ian Collins

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

#27480

On Mon, Oct 22, 2012 at 12:29:08PM +1300, Ian Collins wrote:
> On 10/22/12 11:54, Steve Thompson wrote:
> >On Sun, Oct 21, 2012 at 09:26:54AM +1300, Ian Collins wrote:
> >>On 10/20/12 17:01, Steve Thompson wrote:
> >>>On Sat, Oct 20, 2012 at 04:20:53PM +1300, Ian Collins wrote:
> >>>>On 10/20/12 16:08, Steve Thompson wrote:
> >>>>>I have been using structures containing zero-length arrays as a means
> >>>>>of combining descriptors and array data in a single allocation unit.
> >>>>>Something like the following is a common idiom:
> >>>>>
> >>>>>struct foo {
> >>>>>    int     a, b;
> >>>>>    size_t  len;
> >>>>>    char    p[0];
> >>>>>};
> >>>>
> >>>>That should really be
> >>>>
> >>>>     char    p[];
> >>>>
> >>>>Which is the standardised (as of C99) form of the struct hack.
> >>>>
> >>>>>So far, so good.  My questions regards the availability of zero-length
> >>>>>arrays in common systems.  That is, if I wish my code to be compatible
> >>>>>with most C compilers in use today, should I worry about avoiding
> >>>>>zero-length arrays, or is the feature old enough, with sufficient
> >>>>>prevalence to make it's use reasonable in portable code?
> >>>>
> >>>>Most compilers should support the standard form, or the zero length
> >>>>array form of the struct hack.
> >>>
> >>>I was mainly wondering what the cutoff date was for this feature.  If
> >>>C compilers deployed within the last ten years or so support the p[0]
> >>>idiom, I won't feel as if I'm excluding platforms that might otherwise
> >>>be expected to run my code.  The workaround is not a huge problem
> >>>since the accesses will be insulated from the user by my functions,
> >>>but it is less trouble to write if I don't have to cast everything.
> >>
> >>As Ben pointed out, the pre-C99 form was a single element array.  I
> >>think the zero element array is a gcc extension.  So if you really want
> >>to support every possible compiler, use p[1] and document what you are
> >>doing.  Otherwise use the standard form.
> >
> >Working on another part of the software I'm writing, I learned today
> >that I must use TLS.  There is no point trying to get around that
> >constraint, so the list of potential targets is going to shrink quite
> >a lot.
> 
> Times Literary Supplement?

Thread Local Storage; variables declared with the __thread qualifier
so they are specific to a thread instance.  My zero-overhead allocator
requires a thread-specific descriptor, so I'm committed.
 
> >Now that I've noticed that the GCC documentation has been updated (I
> >may not have read that section for ten years, now that I think of it),
> >it does indeed say that the C99 standard includes support for flexible
> >arrays, with similar semantics to the old gcc zero subscript hack, so
> >I will use that.
> 
> You can't use a VLA as a structure member (how would you declare it?).

>From the GCC info pages:

  In ISO C99, you would use a "flexible array member", which is slightly
different in syntax and semantics:

   * Flexible array members are written as `contents[]' without the `0'.

   * Flexible array members have incomplete type, and so the `sizeof'
     operator may not be applied.  As a quirk of the original
     implementation of zero-length arrays, `sizeof' evaluates to zero.

   * Flexible array members may only appear as the last member of a
     `struct' that is otherwise non-empty.

   * A structure containing a flexible array member, or a union
     containing such a structure (possibly recursively), may not be a
     member of a structure or an element of an array.  (However, these
     uses are permitted by GCC as extensions.)

So I'm free and clear.  My VLAs will be in structures which are not
encapsulated in other structures.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27481

Steve Thompson <stevet810@gmail.com> writes:

> On Mon, Oct 22, 2012 at 12:29:08PM +1300, Ian Collins wrote:
>> On 10/22/12 11:54, Steve Thompson wrote:
<snip>
>> >Now that I've noticed that the GCC documentation has been updated (I
>> >may not have read that section for ten years, now that I think of it),
>> >it does indeed say that the C99 standard includes support for flexible
>> >arrays, with similar semantics to the old gcc zero subscript hack, so
>> >I will use that.
>> 
>> You can't use a VLA as a structure member (how would you declare it?).
>
>>From the GCC info pages:
>
>   In ISO C99, you would use a "flexible array member", which is slightly
> different in syntax and semantics:
>
>    * Flexible array members are written as `contents[]' without the `0'.
>
>    * Flexible array members have incomplete type, and so the `sizeof'
>      operator may not be applied.  As a quirk of the original
>      implementation of zero-length arrays, `sizeof' evaluates to zero.
>
>    * Flexible array members may only appear as the last member of a
>      `struct' that is otherwise non-empty.
>
>    * A structure containing a flexible array member, or a union
>      containing such a structure (possibly recursively), may not be a
>      member of a structure or an element of an array.  (However, these
>      uses are permitted by GCC as extensions.)
>
> So I'm free and clear.  My VLAs will be in structures which are not
> encapsulated in other structures.

There's a terminology confusion here.  Your flexible array member is
just that, it's not a VLA.  Variable length arrays are not permitted in
structs and flexible array members can only appear, unsurprisingly, in a
struct.

-- 
Ben.

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

#27508

On Mon, Oct 22, 2012 at 02:27:01AM +0100, Ben Bacarisse wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> 
> > On Mon, Oct 22, 2012 at 12:29:08PM +1300, Ian Collins wrote:
> >> On 10/22/12 11:54, Steve Thompson wrote:
> <snip>
> >> >Now that I've noticed that the GCC documentation has been updated (I
> >> >may not have read that section for ten years, now that I think of it),
> >> >it does indeed say that the C99 standard includes support for flexible
> >> >arrays, with similar semantics to the old gcc zero subscript hack, so
> >> >I will use that.
> >> 
> >> You can't use a VLA as a structure member (how would you declare it?).
> >
> >>From the GCC info pages:
> >
> >   In ISO C99, you would use a "flexible array member", which is slightly
> > different in syntax and semantics:
> >
> >    * Flexible array members are written as `contents[]' without the `0'.
> >
> >    * Flexible array members have incomplete type, and so the `sizeof'
> >      operator may not be applied.  As a quirk of the original
> >      implementation of zero-length arrays, `sizeof' evaluates to zero.
> >
> >    * Flexible array members may only appear as the last member of a
> >      `struct' that is otherwise non-empty.
> >
> >    * A structure containing a flexible array member, or a union
> >      containing such a structure (possibly recursively), may not be a
> >      member of a structure or an element of an array.  (However, these
> >      uses are permitted by GCC as extensions.)
> >
> > So I'm free and clear.  My VLAs will be in structures which are not
> > encapsulated in other structures.
> 
> There's a terminology confusion here.  Your flexible array member is
> just that, it's not a VLA.  Variable length arrays are not permitted in
> structs and flexible array members can only appear, unsurprisingly, in a
> struct.

I suppose so.  Simply stated, anytime I use "something foo[]", it will
usually be at the end of a struct.  Good enough?

Really, you ought to have read what I meant, rather than reading what I
wrote.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27510

On 10/21/2012 10:28 PM, Steve Thompson wrote:
> On Mon, Oct 22, 2012 at 02:27:01AM +0100, Ben Bacarisse wrote:
>>
>> There's a terminology confusion here.  Your flexible array member is
>> just that, it's not a VLA.  Variable length arrays are not permitted in
>> structs and flexible array members can only appear, unsurprisingly, in a
>> struct.
>
> I suppose so.  Simply stated, anytime I use "something foo[]", it will
> usually be at the end of a struct.  Good enough?

     No, not unless you delete "usually."

> Really, you ought to have read what I meant, rather than reading what I
> wrote.

     If only the compiler would do so ...

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#27513

On Mon, Oct 22, 2012 at 11:18:31AM -0400, Eric Sosman wrote:
> On 10/21/2012 10:28 PM, Steve Thompson wrote:
> >On Mon, Oct 22, 2012 at 02:27:01AM +0100, Ben Bacarisse wrote:
> >>
> >>There's a terminology confusion here.  Your flexible array member is
> >>just that, it's not a VLA.  Variable length arrays are not permitted in
> >>structs and flexible array members can only appear, unsurprisingly, in a
> >>struct.
> >
> >I suppose so.  Simply stated, anytime I use "something foo[]", it will
> >usually be at the end of a struct.  Good enough?
> 
>     No, not unless you delete "usually."

I can declare automatic variables that way:

char str[] = "Stop being so wrong.";
 
> >Really, you ought to have read what I meant, rather than reading what I
> >wrote.
> 
>     If only the compiler would do so ...

It's the first feature I will ask for when the first AI C compiler is
released.  "Make a copy of yourself, but better and faster.  And be
quick about it."



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27516

Eric Sosman <esosman@comcast-dot-net.invalid> writes:

> On 10/21/2012 10:28 PM, Steve Thompson wrote:
>> On Mon, Oct 22, 2012 at 02:27:01AM +0100, Ben Bacarisse wrote:
>>>
>>> There's a terminology confusion here.  Your flexible array member is
>>> just that, it's not a VLA.  Variable length arrays are not permitted in
>>> structs and flexible array members can only appear, unsurprisingly, in a
>>> struct.
>>
>> I suppose so.  Simply stated, anytime I use "something foo[]", it will
>> usually be at the end of a struct.  Good enough?
>
>     No, not unless you delete "usually."

That's overly restrictive, isn't it?  something foo[] can legally appear
in places other than at the end of a struct.

He should, perhaps, have said "Simply stated, anytime I use 'something
foo[]' in a struct, it will be at the end" but what he said is fine by
me.

>> Really, you ought to have read what I meant, rather than reading what I
>> wrote.
>
>     If only the compiler would do so ...

-- 
Ben.

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

#27518

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>
>> On 10/21/2012 10:28 PM, Steve Thompson wrote:
<snip>
>>> [...]  Simply stated, anytime I use "something foo[]", it will
>>> usually be at the end of a struct.  Good enough?
>>
>>     No, not unless you delete "usually."
>
> That's overly restrictive, isn't it?  something foo[] can legally appear
> in places other than at the end of a struct.

That's point's been made.  I should have read to the end of the thread.
Sorry for the noise...

<snip>
-- 
Ben.

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

#27515

Steve Thompson <stevet810@gmail.com> writes:

> On Mon, Oct 22, 2012 at 02:27:01AM +0100, Ben Bacarisse wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>> 
>> > On Mon, Oct 22, 2012 at 12:29:08PM +1300, Ian Collins wrote:
>> >> On 10/22/12 11:54, Steve Thompson wrote:
>> <snip>
>> >> >Now that I've noticed that the GCC documentation has been updated (I
>> >> >may not have read that section for ten years, now that I think of it),
>> >> >it does indeed say that the C99 standard includes support for flexible
>> >> >arrays, with similar semantics to the old gcc zero subscript hack, so
>> >> >I will use that.
>> >> 
>> >> You can't use a VLA as a structure member (how would you declare it?).
>> >
>> >>From the GCC info pages:
>> >
>> >   In ISO C99, you would use a "flexible array member", which is slightly
>> > different in syntax and semantics:
>> >
>> >    * Flexible array members are written as `contents[]' without the `0'.
>> >
>> >    * Flexible array members have incomplete type, and so the `sizeof'
>> >      operator may not be applied.  As a quirk of the original
>> >      implementation of zero-length arrays, `sizeof' evaluates to zero.
>> >
>> >    * Flexible array members may only appear as the last member of a
>> >      `struct' that is otherwise non-empty.
>> >
>> >    * A structure containing a flexible array member, or a union
>> >      containing such a structure (possibly recursively), may not be a
>> >      member of a structure or an element of an array.  (However, these
>> >      uses are permitted by GCC as extensions.)
>> >
>> > So I'm free and clear.  My VLAs will be in structures which are not
>> > encapsulated in other structures.
>> 
>> There's a terminology confusion here.  Your flexible array member is
>> just that, it's not a VLA.  Variable length arrays are not permitted in
>> structs and flexible array members can only appear, unsurprisingly, in a
>> struct.
>
> I suppose so.  Simply stated, anytime I use "something foo[]", it will
> usually be at the end of a struct.  Good enough?

Absolutely.

> Really, you ought to have read what I meant, rather than reading what I
> wrote.

But I did!  I think it's clear from my message that I knew exactly what
you meant; but postings might be read by silent lurkers who could be
confused if this distinction was not made very clear.  Think of it as a
public service announcement.  I'm sorry if it annoyed you.

-- 
Ben.

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

#27520

On Mon, Oct 22, 2012 at 05:30:52PM +0100, Ben Bacarisse wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> 
> > On Mon, Oct 22, 2012 at 02:27:01AM +0100, Ben Bacarisse wrote:
> >> Steve Thompson <stevet810@gmail.com> writes:
> >> 
> >> > On Mon, Oct 22, 2012 at 12:29:08PM +1300, Ian Collins wrote:
> >> >> On 10/22/12 11:54, Steve Thompson wrote:
> >> <snip>
> >> >> >Now that I've noticed that the GCC documentation has been updated (I
> >> >> >may not have read that section for ten years, now that I think of it),
> >> >> >it does indeed say that the C99 standard includes support for flexible
> >> >> >arrays, with similar semantics to the old gcc zero subscript hack, so
> >> >> >I will use that.
> >> >> 
> >> >> You can't use a VLA as a structure member (how would you declare it?).
> >> >
> >> >>From the GCC info pages:
> >> >
> >> >   In ISO C99, you would use a "flexible array member", which is slightly
> >> > different in syntax and semantics:
> >> >
> >> >    * Flexible array members are written as `contents[]' without the `0'.
> >> >
> >> >    * Flexible array members have incomplete type, and so the `sizeof'
> >> >      operator may not be applied.  As a quirk of the original
> >> >      implementation of zero-length arrays, `sizeof' evaluates to zero.
> >> >
> >> >    * Flexible array members may only appear as the last member of a
> >> >      `struct' that is otherwise non-empty.
> >> >
> >> >    * A structure containing a flexible array member, or a union
> >> >      containing such a structure (possibly recursively), may not be a
> >> >      member of a structure or an element of an array.  (However, these
> >> >      uses are permitted by GCC as extensions.)
> >> >
> >> > So I'm free and clear.  My VLAs will be in structures which are not
> >> > encapsulated in other structures.
> >> 
> >> There's a terminology confusion here.  Your flexible array member is
> >> just that, it's not a VLA.  Variable length arrays are not permitted in
> >> structs and flexible array members can only appear, unsurprisingly, in a
> >> struct.
> >
> > I suppose so.  Simply stated, anytime I use "something foo[]", it will
> > usually be at the end of a struct.  Good enough?
> 
> Absolutely.
> 
> > Really, you ought to have read what I meant, rather than reading what I
> > wrote.
> 
> But I did!  I think it's clear from my message that I knew exactly what
> you meant; but postings might be read by silent lurkers who could be
> confused if this distinction was not made very clear.  Think of it as a
> public service announcement.  I'm sorry if it annoyed you.

No annoyance taken, although now that I think of it it does show an
instance of overloaded semantics, which can be confusing.  When I was
less experienced with C, I was confused by the fact that variables
defined as structures were not pointers:

struct point {
	int x, y, z;
};

struct point a;


One cannot reference 'a' (as such) in an expression even though it is
a pointer in the implementation because C allows one to use structures
as arguments to a function.  I'd never do that in my own code, but
some people may like the fact that they can pass complex data
structures around as if they were simple variables.  I think it wastes
resources, but of course that is less of an issue today than it was
when C was first developed.

These days I'm thinking more and more about cache-line usage, so I am
concerned with preserving the 'hotness' of my data.  Copying
structures around a whole lot is hostile to this paradigm, so that is
one language feature I am happy to avoid.

One place where it might be helpful is in the case where a single
structure is used by several functions that destructively modify its
contents.  In that case, the original structure is preserved by
passing it directly as an argument to said functions, but I don't know
how useful that would be in practice.  Long ago it may have been
considered good practice to insulate the different layers of a program
by making it impossible for a function to modify the data held by the
caller, but I cannot see that as a practical benefit.  Such structures
are always accessible on the stack.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27523

Steve Thompson <stevet810@gmail.com> writes:
[...]
> No annoyance taken, although now that I think of it it does show an
> instance of overloaded semantics, which can be confusing.  When I was
> less experienced with C, I was confused by the fact that variables
> defined as structures were not pointers:
>
> struct point {
> 	int x, y, z;
> };
>
> struct point a;
>
>
> One cannot reference 'a' (as such) in an expression even though it is
> a pointer in the implementation because C allows one to use structures
> as arguments to a function.  I'd never do that in my own code, but
> some people may like the fact that they can pass complex data
> structures around as if they were simple variables.  I think it wastes
> resources, but of course that is less of an issue today than it was
> when C was first developed.

I'm not sure what you mean when you say `a` "is a pointer in
the implementation", especially after you mention "the fact that
variables defined as structures were not pointers".

Whatever you meant, the fact it that `a` *isn't* a pointer; it's
the name of an object of type `struct point`, and the name `a`
certainly can be used in an expression: as the LHS or RHS of an
assignment, as a function argument, as an argument to `sizeof` or
`&`, as the left operand of `.`, and probably in other ways that
I haven't thought of.  Of course `&a` is a pointer (not a pointer
object, but an expression of pointer type).

> These days I'm thinking more and more about cache-line usage, so I am
> concerned with preserving the 'hotness' of my data.  Copying
> structures around a whole lot is hostile to this paradigm, so that is
> one language feature I am happy to avoid.

If a structure is smaller than a pointer, or not much bigger, it makes
perfect sense to pass it around by value.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web