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

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

Help on this typedef

Started byfl <rxjwg98@gmail.com>
First post2017-05-10 19:12 -0700
Last post2017-05-27 06:15 -0700
Articles 8 on this page of 68 — 16 participants

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

Contents

  Help on this typedef fl <rxjwg98@gmail.com> - 2017-05-10 19:12 -0700
    Re: Help on this typedef Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-05-10 21:06 -0600
    Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-10 20:11 -0700
      Re: Help on this typedef David Brown <david.brown@hesbynett.no> - 2017-05-11 10:03 +0200
        Re: Help on this typedef supercat@casperkitty.com - 2017-05-11 08:35 -0700
          Re: Help on this typedef David Brown <david.brown@hesbynett.no> - 2017-05-12 10:34 +0200
            Re: Help on this typedef joel.rees@gmail.com - 2017-05-12 06:01 -0700
            Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-12 09:38 -0700
          Re: Help on this typedef joel.rees@gmail.com - 2017-05-12 05:08 -0700
            Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 14:25 -0700
              Re: Help on this typedef joel.rees@gmail.com - 2017-05-14 23:36 -0700
                Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 07:23 -0700
                  Re: Help on this typedef joel.rees@gmail.com - 2017-05-18 07:40 -0700
                    Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-18 09:35 -0700
                      Re: Help on this typedef supercat@casperkitty.com - 2017-05-18 10:59 -0700
                      Re: Help on this typedef joel.rees@gmail.com - 2017-05-18 23:40 -0700
                        Re: Help on this typedef jadill33@gmail.com - 2017-05-19 08:12 -0700
                          Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 08:41 -0700
                            Re: Help on this typedef jadill33@gmail.com - 2017-05-19 09:41 -0700
                        Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-19 09:34 -0700
                          Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 10:18 -0700
                          Re: Help on this typedef Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 21:35 +0100
                            Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 14:16 -0700
                            Re: Help on this typedef Ike Naar <ike@iceland.freeshell.org> - 2017-05-19 21:15 +0000
                              Re: Help on this typedef Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 23:54 +0100
                            Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-19 14:25 -0700
                              Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 15:18 -0700
                              Re: Help on this typedef Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 23:52 +0100
                                Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-19 16:42 -0700
                                  Re: Help on this typedef Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-20 01:16 +0100
                            Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-20 01:58 -0700
                              Re: Help on this typedef joel.rees@gmail.com - 2017-05-20 02:25 -0700
                          Re: Help on this typedef joel.rees@gmail.com - 2017-05-19 22:09 -0700
                            Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 23:23 -0700
                        Re: Help on this typedef "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-19 13:33 -0400
                          Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 13:44 -0700
                            Re: Help on this typedef jameskuyper@verizon.net - 2017-05-19 19:20 -0700
                              Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 23:30 -0700
                                Re: Help on this typedef jameskuyper@verizon.net - 2017-05-20 07:20 -0700
                                Re: Help on this typedef jameskuyper@verizon.net - 2017-05-20 07:46 -0700
                                  Re: Help on this typedef supercat@casperkitty.com - 2017-05-22 10:50 -0700
                    Re: Help on this typedef "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-18 12:37 -0400
                    Re: Help on this typedef Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-18 20:02 +0100
                      Re: Help on this typedef joel.rees@gmail.com - 2017-05-19 00:20 -0700
                        Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-19 09:51 -0700
                          Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 10:31 -0700
                    Re: Help on this typedef Ike Naar <ike@iceland.freeshell.org> - 2017-05-19 19:48 +0000
                    Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-20 08:47 -0700
          Re: Help on this typedef "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-27 18:50 +0200
    Re: Help on this typedef joel.rees@gmail.com - 2017-05-12 06:17 -0700
      Re: Help on this typedef supercat@casperkitty.com - 2017-05-12 08:46 -0700
        Re: Help on this typedef joel.rees@gmail.com - 2017-05-12 18:11 -0700
          Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-12 18:37 -0700
            Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:44 -0700
              Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-13 13:47 -0700
                Re: Help on this typedef Robert Wessel <robertwessel2@yahoo.com> - 2017-05-14 00:28 -0500
                Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 13:39 -0700
                  Re: Help on this typedef raltbos@xs4all.nl (Richard Bos) - 2017-05-15 13:02 +0000
                    Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 07:30 -0700
          Re: Help on this typedef supercat@casperkitty.com - 2017-05-12 20:45 -0700
          Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:57 -0700
          Re: Help on this typedef Philip Lantz <prl@canterey.us> - 2017-05-13 12:07 -0700
          Re: Help on this typedef David Brown <david.brown@hesbynett.no> - 2017-05-14 15:34 +0200
        Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 12:48 -0700
          Re: Help on this typedef supercat@casperkitty.com - 2017-05-15 07:39 -0700
            Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-24 08:23 -0700
              Re: Help on this typedef supercat@casperkitty.com - 2017-05-24 09:17 -0700
                Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-27 06:15 -0700

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

#109898

FromTim Rentsch <txr@alumni.caltech.edu>
Date2017-05-13 09:57 -0700
Message-ID<kfnh90osnhz.fsf@x-alumni2.alumni.caltech.edu>
In reply to#109863
joel.rees@gmail.com writes:

> On Saturday, May 13, 2017 at 12:46:56 AM UTC+9, supe...@casperkitty.com wrote:
>> On Friday, May 12, 2017 at 8:17:46 AM UTC-5, joel...@gmail.com wrote:
>>> Anyway, an array of one is most commonly a signal that you are
>>> allocating and using variable length arrays.
>>
>> IMHO, the struct hack would have been cleaner in many ways had the authors
>> of the Standard not opted to disallow arrays of size zero.  The only good
>> reason I can see for disallowing such arrays would have been to ensure the
>> correct "behavior" of a existing code that uses constructs like
>>
>>     struct dummyName { int x[sizeof foo == 50]; };
>
> #error was not good enough?
>
> Fortunately, I think I have never seen code like that.
>
> No, wait, I probably have, now that I think about it.  But I'm going to
> admit to bias here and assert my opinion that code like that doesn't
> really deserve to be supported by the standard.

How the Standard supports that declaration now is to say that it
will be accepted if 'sizeof foo' is a compile-time constant and
equal to 50, but otherwise requires a diagnostic.  In what way
do you think that specification should be changed?  IMCO it is
fine just as it is.

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

#109903

FromPhilip Lantz <prl@canterey.us>
Date2017-05-13 12:07 -0700
Message-ID<MPG.3380f94ed759fce7139@news.eternal-september.org>
In reply to#109863
joel.rees@gmail.com wrote:
> 
> supercat@casperkitty.com wrote:
> > IMHO, the struct hack would have been cleaner in many ways had the authors
> > of the Standard not opted to disallow arrays of size zero.  The only good
> > reason I can see for disallowing such arrays would have been to ensure the
> > correct "behavior" of a existing code that uses constructs like
> > 
> >     struct dummyName { int x[sizeof foo == 50]; };
> 
> #error was not good enough?
> 
> Fortunately, I think I have never seen code like that.
> 
> No, wait, I probably have, now that I think about it. But I'm going to 
> admit to bias here and assert my opinion that code like that doesn't 
> really deserve to be supported by the standard.

Prior to the addition of _Static_assert, this was a way to obtain a
similar capability. #error cannot be used to do the same thing. (Clearly
_Static_assert is a huge improvement, which is why it was added.)

There is probably still lots of code around that uses this method, and it
would be inappropriate for the standard to change in a way that would make
that code no longer work as intended.

Philip

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

#109945

FromDavid Brown <david.brown@hesbynett.no>
Date2017-05-14 15:34 +0200
Message-ID<of9m6u$g6h$1@dont-email.me>
In reply to#109863
On 13/05/17 03:11, joel.rees@gmail.com wrote:
> On Saturday, May 13, 2017 at 12:46:56 AM UTC+9, supe...@casperkitty.com wrote:
>> On Friday, May 12, 2017 at 8:17:46 AM UTC-5, joel...@gmail.com wrote:
>>> Anyway, an array of one is most commonly a signal that you are
>>> allocating and using variable length arrays.
>>
>> IMHO, the struct hack would have been cleaner in many ways had the authors
>> of the Standard not opted to disallow arrays of size zero.  The only good
>> reason I can see for disallowing such arrays would have been to ensure the
>> correct "behavior" of a existing code that uses constructs like
>>
>>     struct dummyName { int x[sizeof foo == 50]; };
>
> #error was not good enough?
>
> Fortunately, I think I have never seen code like that.
>
> No, wait, I probably have, now that I think about it. But I'm going to
> admit to bias here and assert my opinion that code like that doesn't
> really deserve to be supported by the standard.
>

Code like that is perfectly reasonable - /if/ it is hidden within an 
appropriate macro:


#define STATIC_ASSERT_NAME_(line)       STATIC_ASSERT_NAME2_(line)
#define STATIC_ASSERT_NAME2_(line)      assertion_failed_at_line_##line
#define STATIC_ASSERT(claim, warning) \
   typedef struct { \
     char STATIC_ASSERT_NAME_(__COUNTER__) [(claim) ? 1 : -1]; \
   } STATIC_ASSERT_NAME_(__COUNTER__)


(__COUNTER__ is available on some compilers - replace it with __LINE__ 
for standard compliance.)


With C11, you have _Static_assert instead - but this macro works with 
previous C standards to give you a compile-time error when the static 
assertion fails.

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

#109971

FromTim Rentsch <txr@alumni.caltech.edu>
Date2017-05-14 12:48 -0700
Message-ID<kfnvap3qkwk.fsf@x-alumni2.alumni.caltech.edu>
In reply to#109842
supercat@casperkitty.com writes:

> On Friday, May 12, 2017 at 8:17:46 AM UTC-5, joel...@gmail.com wrote:
>> Anyway, an array of one is most commonly a signal that you are
>> allocating and using variable length arrays.
>
> IMHO, the struct hack would have been cleaner in many ways had the authors
> of the Standard not opted to disallow arrays of size zero.  The only good
> reason I can see for disallowing such arrays would have been to ensure the
> correct "behavior" of a existing code that uses constructs like
>
>     struct dummyName { int x[sizeof foo == 50]; };
>
> as a form of compile-time assertion.  [...]

This sounds like hyperbole.  If it isn't then you aren't thinking
hard enough.

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

#110037

Fromsupercat@casperkitty.com
Date2017-05-15 07:39 -0700
Message-ID<e81896cd-613e-4bbd-ad8c-4425beb9a7a2@googlegroups.com>
In reply to#109971
On Sunday, May 14, 2017 at 2:49:06 PM UTC-5, Tim Rentsch wrote:
> supercat writes:
> 
> > On Friday, May 12, 2017 at 8:17:46 AM UTC-5, joel...@gmail.com wrote:
> >> Anyway, an array of one is most commonly a signal that you are
> >> allocating and using variable length arrays.
> >
> > IMHO, the struct hack would have been cleaner in many ways had the authors
> > of the Standard not opted to disallow arrays of size zero.  The only good
> > reason I can see for disallowing such arrays would have been to ensure the
> > correct "behavior" of a existing code that uses constructs like
> >
> >     struct dummyName { int x[sizeof foo == 50]; };
> >
> > as a form of compile-time assertion.  [...]
> 
> This sounds like hyperbole.  If it isn't then you aren't thinking
> hard enough.

I said the only good reason I could see.  Since I could see no other good
reasons, the statement was accurate.  You presumably see other ways in which
disallowing zero-size arrays improves the language.  Care to enlighten me?

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

#110549

FromTim Rentsch <txr@alumni.caltech.edu>
Date2017-05-24 08:23 -0700
Message-ID<kfna862i8ix.fsf@x-alumni2.alumni.caltech.edu>
In reply to#110037
supercat@casperkitty.com writes:

> On Sunday, May 14, 2017 at 2:49:06 PM UTC-5, Tim Rentsch wrote:
>> supercat writes:
>>
>>> On Friday, May 12, 2017 at 8:17:46 AM UTC-5, joel...@gmail.com wrote:
>>>> Anyway, an array of one is most commonly a signal that you are
>>>> allocating and using variable length arrays.
>>>
>>> IMHO, the struct hack would have been cleaner in many ways had the authors
>>> of the Standard not opted to disallow arrays of size zero.  The only good
>>> reason I can see for disallowing such arrays would have been to ensure the
>>> correct "behavior" of a existing code that uses constructs like
>>>
>>>     struct dummyName { int x[sizeof foo == 50]; };
>>>
>>> as a form of compile-time assertion.  [...]
>>
>> This sounds like hyperbole.  If it isn't then you aren't thinking
>> hard enough.
>
> I said the only good reason I could see.  Since I could see no
> other good reasons, the statement was accurate.

Yes, and I said that sounds like hyperbole, which is also an
accurate statement.

> You presumably see other ways in which disallowing zero-size
> arrays improves the language.  Care to enlighten me?

Based on past experience I have to think that what you're looking
for is not an answer but an argument.  I have no interest in
getting into an argument.  But if you want to stop by I might be
willing to try hitting you over the head with a stick until
you become enlightened. :)

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

#110558

Fromsupercat@casperkitty.com
Date2017-05-24 09:17 -0700
Message-ID<9e0525fb-6852-4f0b-a8a8-6271e07eeb7a@googlegroups.com>
In reply to#110549
On Wednesday, May 24, 2017 at 10:23:13 AM UTC-5, Tim Rentsch wrote:
> supercat writes:
> 
> > On Sunday, May 14, 2017 at 2:49:06 PM UTC-5, Tim Rentsch wrote:
> >> supercat writes:
> >>
> >>> On Friday, May 12, 2017 at 8:17:46 AM UTC-5, joel...@gmail.com wrote:
> >>>> Anyway, an array of one is most commonly a signal that you are
> >>>> allocating and using variable length arrays.
> >>>
> >>> IMHO, the struct hack would have been cleaner in many ways had the authors
> >>> of the Standard not opted to disallow arrays of size zero.  The only good
> >>> reason I can see for disallowing such arrays would have been to ensure the
> >>> correct "behavior" of a existing code that uses constructs like
> >>>
> >>>     struct dummyName { int x[sizeof foo == 50]; };
> >>>
> >>> as a form of compile-time assertion.  [...]
> >>
> >> This sounds like hyperbole.  If it isn't then you aren't thinking
> >> hard enough.
> >
> > I said the only good reason I could see.  Since I could see no
> > other good reasons, the statement was accurate.
> 
> Yes, and I said that sounds like hyperbole, which is also an
> accurate statement.
> 
> > You presumably see other ways in which disallowing zero-size
> > arrays improves the language.  Care to enlighten me?
> 
> Based on past experience I have to think that what you're looking
> for is not an answer but an argument.  I have no interest in
> getting into an argument.  But if you want to stop by I might be
> willing to try hitting you over the head with a stick until
> you become enlightened. :)

I stated that the only good reason I could see was to facilitate an
assertion construct.  You stated I wasn't thinking hard enough.
That would suggest that there are other reasons which you regard as
obvious and should presumably have no trouble stating, and yet you
continually refuse to state them.  And I'm the one being needlessly
argumentative!?

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

#110792

FromTim Rentsch <txr@alumni.caltech.edu>
Date2017-05-27 06:15 -0700
Message-ID<kfnd1aufnkv.fsf@x-alumni2.alumni.caltech.edu>
In reply to#110558
supercat@casperkitty.com writes:

> On Wednesday, May 24, 2017 at 10:23:13 AM UTC-5, Tim Rentsch wrote:
>> supercat writes:
>>
>>> On Sunday, May 14, 2017 at 2:49:06 PM UTC-5, Tim Rentsch wrote:
>>>> supercat writes:
>>>>
>>>>> On Friday, May 12, 2017 at 8:17:46 AM UTC-5, joel...@gmail.com wrote:
>>>>>> Anyway, an array of one is most commonly a signal that you are
>>>>>> allocating and using variable length arrays.
>>>>>
>>>>> IMHO, the struct hack would have been cleaner in many ways had the authors
>>>>> of the Standard not opted to disallow arrays of size zero.  The only good
>>>>> reason I can see for disallowing such arrays would have been to ensure the
>>>>> correct "behavior" of a existing code that uses constructs like
>>>>>
>>>>>     struct dummyName { int x[sizeof foo == 50]; };
>>>>>
>>>>> as a form of compile-time assertion.  [...]
>>>>
>>>> This sounds like hyperbole.  If it isn't then you aren't thinking
>>>> hard enough.
>>>
>>> I said the only good reason I could see.  Since I could see no
>>> other good reasons, the statement was accurate.
>>
>> Yes, and I said that sounds like hyperbole, which is also an
>> accurate statement.
>>
>>> You presumably see other ways in which disallowing zero-size
>>> arrays improves the language.  Care to enlighten me?
>>
>> Based on past experience I have to think that what you're looking
>> for is not an answer but an argument.  I have no interest in
>> getting into an argument.  But if you want to stop by I might be
>> willing to try hitting you over the head with a stick until
>> you become enlightened. :)
>
> I stated that the only good reason I could see was to facilitate an
> assertion construct.  You stated I wasn't thinking hard enough.
> That would suggest that there are other reasons which you regard as
> obvious [...]

That isn't what I said and is not what I meant.  Which should
be obvious from the "hard enough" part of "you aren't thinking
_hard enough_".  Or is it that you think of any thinking at all
as too hard?

[toc] | [prev] | [standalone]

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

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

csiph-web