Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #73976 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2015-10-27 09:52 -0700 |
| Last post | 2015-10-31 01:14 -0700 |
| Articles | 14 on this page of 174 — 20 participants |
Back to article view | Back to comp.lang.c
Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 09:52 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:06 -0700
Re: Problem with the function that should display new letter John Gordon <gordon@panix.com> - 2015-10-27 17:16 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:28 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:09 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:12 -0700
Re: Problem with the function that should display new letter Barry Schwarz <schwarzb@dqel.com> - 2015-10-27 13:12 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-27 13:23 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-27 13:49 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-27 21:27 +0000
Re: Problem with the function that should display new letter Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-27 18:00 -0400
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 02:53 +0000
Re: Problem with the function that should display new letter Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 00:43 -0500
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 06:08 +0000
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 08:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 09:26 +0100
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 08:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 10:40 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-28 06:44 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-28 06:35 -0700
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 13:40 -0400
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 13:47 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:38 -0700
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 16:46 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:39 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 18:20 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:36 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 12:09 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:51 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-27 19:25 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 12:27 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-28 10:07 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-28 00:50 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-28 21:04 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-28 01:13 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 10:40 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:02 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-28 11:28 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 11:57 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 12:53 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-28 13:33 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 08:35 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 10:59 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:04 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 11:38 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:43 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 12:10 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 12:58 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 13:55 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 14:02 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 15:01 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 15:44 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:22 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 16:26 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:44 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 18:45 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 19:26 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 20:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 22:59 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 22:48 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 01:14 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 01:07 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 14:07 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 13:57 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 16:22 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-29 08:38 -0700
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 17:25 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-29 12:46 -0700
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:03 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 19:19 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:54 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-30 12:20 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 21:36 +0000
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-30 10:47 +1300
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 22:25 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:59 +0100
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 10:07 +0100
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 16:25 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:01 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-28 09:50 -0700
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 21:57 +0000
Re: Problem with the function that should display new letter Geoff <geoff@invalid.invalid> - 2015-10-28 18:25 -0700
Re: Problem with the function that should display new letter Geoff <geoff@invalid.invalid> - 2015-10-28 18:23 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 01:44 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-28 07:07 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 07:07 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 09:08 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 14:29 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 16:10 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 20:27 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-31 12:40 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 02:16 -0800
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 03:36 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 10:46 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 03:56 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:00 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:02 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:05 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:14 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:14 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 11:26 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:26 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 05:29 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 09:23 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 07:44 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 11:39 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 09:52 -0700
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-29 16:02 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 09:56 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 13:41 -0400
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 17:46 +0000
Re: Problem with the function that should display new letter Udyant Wig <udyantw@gmail.com> - 2015-10-30 00:14 +0530
Re: Problem with the function that should display new letter raltbos@xs4all.nl (Richard Bos) - 2015-10-29 19:30 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 22:08 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 22:28 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:10 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-30 08:56 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 13:18 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-30 09:11 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:21 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:04 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:11 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:19 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:24 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 05:26 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-29 08:31 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 09:42 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 08:31 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 10:17 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 17:36 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:18 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 08:36 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 08:38 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 02:26 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:32 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 13:39 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 03:59 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 11:18 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:24 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-30 14:18 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:34 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 13:39 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:57 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 09:06 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 08:49 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 10:18 -0700
Re: Problem with the function that should display new letter Barry Schwarz <schwarzb@dqel.com> - 2015-10-29 11:48 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:23 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:42 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:13 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 10:17 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 10:23 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:39 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:45 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 13:55 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 07:05 -0700
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-30 23:29 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 01:14 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:02 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 18:05 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 23:46 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-11-01 08:46 -0800
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 23:43 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-11-01 16:05 -0800
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 21:41 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 22:46 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-31 18:22 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 23:57 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:20 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-31 13:38 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-31 11:28 -0700
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 00:06 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:58 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-31 01:14 -0700
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-10-31 23:46 +0000 |
| Message-ID | <A9M0V5.Xls.JNkah@gmail.com> |
| In reply to | #74463 |
On Sat, Oct 31, 2015 at 06:05:59PM +0000, Ben Bacarisse wrote:
> Steve Thompson <stevet810@gmail.com> writes:
>
> > On Sat, Oct 31, 2015 at 01:14:13AM +0000, Ben Bacarisse wrote:
> >> Steve Thompson <stevet810@gmail.com> writes:
> >> <snip>
> >> > First, I have found a few cases where the ability to use GCC macros as
> >> > expressions is unavoidable. These are macros encapsulated with ({ ...
> >> > }). This appears to be a GCC-ism and while I am not strident about
> >> > requiring the standard to change to accommodate this extension, I am
> >> > curious to know how widespread this feature is among non-GCC
> >> > compilers. If I find that the feature is mainly restricted to GCC I
> >> > may decide to refactor affected code as avoiding dependency on GCC is
> >> > something of a priority for me.
> >>
> >> Inline functions are generally a better idea but they don't always fit
> >> of course. Do you have an example of when you are forced to use
> >> ({...})? In some cases there are portable alternatives.
> >
> > How about this:
> >
> > #define ARITH_SATURATE(Var, OP, Amt) \
> > ({ \
> > int result = 1; \
> > typeof(Amt) amt = Amt; \
> > typeof(Var) *ptr = &Var; \
> > typeof(Var) tmp = *ptr; \
> > typeof(Var) min = ~0; \
> > typeof(Var) max = ~0; \
> > \
> > if(min > 0) \
> > min = 0; \
> > \
> > if(max < 0) \
> > max = ((1 << (sizeof(*ptr) * 8 - 2)) - 1) - 1 + \
> > ((1 << (sizeof(*ptr) * 8 - 2)) - 1); \
> > \
> > *ptr = *ptr OP _amt; \
> > \
> > if(unlikely((amt > 0) && (*ptr < tmp))) { \
> > result = 0; \
> > *ptr = max; \
> > } \
> > \
> > if(unlikely((amt < 0) && (*ptr > tmp))) { \
> > result = 0; \
> > *ptr = min; \
> > } \
> > \
> > arith_assert(result); \
> > arith_warn(result); \
> > \
> > result; \
> > })
> >
> > #define ADDS(a, b) ARITH_SATURATE(a, +, b)
> > ... etc.
> >
> > Please note that this is not tested; I wrote it for the purpose of
> > seeing how it 'looks'. The idea is obviously to be type agnostic
>
> Yes, if you need to be type agnostic your options are very limited.
> There is some help in the form of _Generic but it does not scale well to
> lots of types and lots of type combinations.
I will investigate _Generic as I've not encountered it before.
> If you need the code to be portable (by avoiding ({})) your simplest
> option is to remove the return value and have it put somewhere instead
> (i.e. the macro is given the name of a result variable) and the macro
> changed to expand to a statement rather than an expression. Not nice,
> but that may be all you can do.
I have used that idiom before, in particular with inline assembly
macros which are expected to be used in expressions. I know I cannot
expect inline assembly syntax to be portable, but the reason for the
aforementioned question is to help me reduce the amount of platform-
specific code in the associated project. With my limited exposure to
C compilers I have no easy way to judge the prevalence of the ({ ...
}) idiom. I presume it is not exclusive to GCC but I may be in error.
As with the above it should be apparent that a considerable amount of
code could end up using saturating arithmetic. I further understand
that C++ provides a solution but that necessarily will make the code
reliant on it and I am not prepared to make the switch.
> > might do saturating arithmetic on signed/unsigned integer types of
> > arbitrary size, up to the __int128_t type if available. For that
> > reason it cannot be implemented as an inline function, and I suppose I
> > am also dependent on the typeof() keyword. Consequently I am
> > interested to learn whether these (two) idioms are commonplace enough
> > to rely on them. I do not care so much about odd embedded system
> > compilers, but the HPC market is another matter entirely. I would
> > hate to have to generate macros/functions for eight or more different
> > integer types.
> >
> >> > The second missing feature is more important. As I am attempting to
> >> > do some program introspection it has occurred to me that a preprocessor
> >> > directive to take the name of an identifier as a char * array would be
> >> > extremely valuable. Something like nameof(function) and
> >> > nameof(variable) would be invaluable for my purposes. Seeing as how
> >> > such a feature would be trivial to implement and would not materially
> >> > affect the language syntax I am vaguely astounded to discover that it
> >> > does not exist.
> >>
> >> Again an example would help because it looks like the # operator is what
> >> you want.
> >
> > I am aware of the string concatenation operator and it is not fit to
> > purpose.
>
> No, it did seem unlikely, but there was very little to go on.
>
> > Let us say I have a globally scoped variable which
> > establishes some important value to the program, perhaps a loop
> > counter which defines the number of times a mutex acquisition will
> > spin before calling shed_yield(). This is a parameter which might be
> > run-time tuneable. To make it easier to manage such parameters, I
> > would like to have a macro which builds a list of marked variables
> > which might then be fed to a configuration menu at run-time. Therefore
> > a function with the following invocation pattern would be helpful.
> >
> > add_instr_var(&var, sizeof(var), VAR_UINT, nameof(var));
> >
> > This is perhaps a minor nit, but preprocessor substitution adds
> > additional complexity, and with a macro add_instr_var() can be
> > theoretically simplified in the code to ADD_INSTR_VAR(var), which
> > would greatly improve readability. To get around the lack generally
> > requires two entries in the code for each symbol of interest; one
> > quoted and one that is not. An alternate solution would involve
> > digging into the debugging sections (assuming the code is compiled
> > with debugging info) and would be exceedingly complex in comparison
> > to the simplicity of a minor language extension.
> >
> > If you have an alternate strategy I would love to hear it.
>
> I can't follow the requirement. There seem to be other reasons why
> ADD_INSTR_VAR(var) can't expand to the call you gave (for example I
> don't know the relationship between "var" and "VAR_UINT") but turning
> the variable name into a string does not seem to be it. Obviously since
> you know about # I must simply be getting the wrong end of this
> example. Sorry.
My explanation was perhaps too sparse in detail. The goal of the
preceeding is to expose variables to programmed introspection. As
such, there must be (a) a pointer to the variable contents, (b) an
indication of its type and size, and (c) a string identifier to use as
a search key. Hence it would be useful to have a macro which can be
simply passed a symbol, and from that extract the relevant
information. So if I have
int counter;
i would like to have a macro that allows me to generate a char *
string from the 'counter' symbol -- which would be "counter". From
there I might use the '#' preprocessor directive to concatenate a
prefix, as in "sys.foo." # counter", but that is by the by.
Additionally it would be nice to use typeof(counter) in conjunction
with conditional compilation to qualify the introspection DS so that
it is understood that the counter symbol is a signed integer of
such-and-such size.
I suppose you might consider this as an attempt to jam debugger
features into a program, hence my comment regarding debugging
sections. But as I explained, I do not want to go to the trouble of
parsing ELF sections or debug formats. Again, I suspect C++ may be
bent to this purpose. :(
The core of this issue is language extensions which make programmatic
introspection possible, something which would be used by relatively
few programmers, but which are indispensable for certain applications.
I will further venture the opinion that such features -- in whatever
final form they might take -- are essential tools to complete a
programming language and that the C standards committee ought to visit
this subject for potential inclusion in a future revision of the
standard. Ideally, the feature set at issue should extend the
language without materially affecting existing syntax. On this last
point I do not feel strongly enough on this issue to make a formal
submission to the committee, and in any case I am likely part of a
very small minority who would even consider doing programmatic
introspection of C programs. Very likely there are readers in this
group who are thinking to themselves that I should be using Java,
which appears to have well-established methods for doing this sort of
thing.
Regards,
Steve Thompson
--
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-01 08:46 -0800 |
| Message-ID | <ebe0b0bf-bfae-434b-a28d-754f394e2055@googlegroups.com> |
| In reply to | #74542 |
On Sunday, November 1, 2015 at 8:01:03 AM UTC-6, Steve Thompson wrote:
> As with the above it should be apparent that a considerable amount of
> code could end up using saturating arithmetic. I further understand
> that C++ provides a solution but that necessarily will make the code
> reliant on it and I am not prepared to make the switch.
IMHO, the value of C for portable code would be enhanced if the Standard
would define ways of distinguishing storage formats, rvalue types, and means
of converting rvalues to and from storage formats, such that platforms would
not be required to accommodate all types defined by the standard, but would
be required to either operate with types as specified in the code *or reject
code whose specifications they could not satisfy*. Some processors have
built-in support for saturating arithmetic, and many others could support
compiler emulation of saturating arithmetic more efficiently than user-code
emulation of same. If there were types which were storage-compatible with
ordinary integers, but behaved with saturating-integer semantics then code
which was written for compilers supporting that feature would be portable to
any other compilers likewise supporting it.
As to whether very many compilers would bother supporting saturating
arithmetic if the Standard were to define it, that's hard to say, but if
the Standard were to say that
__int_extended(mss, sf, pa, mrvs, rbeh, sbeh)
mss = Minimum storage size in bits
sf = Storage format
(u=unsigned, s=two's-comp, oc=one's-complement, sm=sign-mag,
sn=native signed)
pa = Padding/Alignment
(not sure what forms to list)
mrvs = Minimum size in bits of signed rvalue
rbeh = Overflow behavior or rvalue
(u=Undefined Behavior; wm=wrap to minimum size; wcv=wrap to any size
which behaves as consistent value; piv=partial-indeterminate value,
sat=saturate, err=indicate error via implementation-defined means,
etc.)
sbeh = Out-of-range behavior when storing value
(u=Undefined Behavior; wm=wrap to minimum size; wcv=wrap to any size
which behaves as consistent value; piv=partial-indeterminate value,
sat=saturate, err=indicate error via implementation-defined means,
etc.)
with additional shorthand forms for cases where default values for many of
those parameters would be acceptable, then it would be possible for existing
compilers to accept declarations for types they naturally support merely by
including a suitable header file, but compilers would be able to support
both tighter and looser semantics as well. For example, under current rules
a compiler with 16-bit "int" given a loop:
for (int32_t i=start; i<=end; i++)
could not assume that it will loop exactly (end-start) times since behavior
would be defined as doing otherwise if end==INT32_MAX. If, however, the
variable "i" were defined as not requiring numerical wraparound on storage,
an optimizer may not need to honor such an obligation depending upon how
"i" was defined.
While the preprocessor macros necessary to convert declarations of such
forms to pre-existing types would be a bit gnarly, I think they should be
workable. Further, a lot of numerical code could be written to be both
more efficient and easier to read if compilers could support some more
integer behaviors.
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-11-01 23:43 +0000 |
| Message-ID | <ngHyPC.MtK.pUJn3@gmail.com> |
| In reply to | #74570 |
On Sun, Nov 01, 2015 at 08:46:32AM -0800, supercat@casperkitty.com wrote:
> On Sunday, November 1, 2015 at 8:01:03 AM UTC-6, Steve Thompson wrote:
> > As with the above it should be apparent that a considerable amount of
> > code could end up using saturating arithmetic. I further understand
> > that C++ provides a solution but that necessarily will make the code
> > reliant on it and I am not prepared to make the switch.
>
> IMHO, the value of C for portable code would be enhanced if the Standard
> would define ways of distinguishing storage formats, rvalue types, and means
> of converting rvalues to and from storage formats, such that platforms would
> not be required to accommodate all types defined by the standard, but would
> be required to either operate with types as specified in the code *or reject
> code whose specifications they could not satisfy*. Some processors have
> built-in support for saturating arithmetic, and many others could support
> compiler emulation of saturating arithmetic more efficiently than user-code
> emulation of same. If there were types which were storage-compatible with
> ordinary integers, but behaved with saturating-integer semantics then code
> which was written for compilers supporting that feature would be portable to
> any other compilers likewise supporting it.
> As to whether very many compilers would bother supporting saturating
> arithmetic if the Standard were to define it, that's hard to say, but if
> the Standard were to say that
> __int_extended(mss, sf, pa, mrvs, rbeh, sbeh)
> mss = Minimum storage size in bits
> sf = Storage format
> (u=unsigned, s=two's-comp, oc=one's-complement, sm=sign-mag,
> sn=native signed)
> pa = Padding/Alignment
> (not sure what forms to list)
> mrvs = Minimum size in bits of signed rvalue
> rbeh = Overflow behavior or rvalue
> (u=Undefined Behavior; wm=wrap to minimum size; wcv=wrap to any size
> which behaves as consistent value; piv=partial-indeterminate value,
> sat=saturate, err=indicate error via implementation-defined means,
> etc.)
> sbeh = Out-of-range behavior when storing value
> (u=Undefined Behavior; wm=wrap to minimum size; wcv=wrap to any size
> which behaves as consistent value; piv=partial-indeterminate value,
> sat=saturate, err=indicate error via implementation-defined means,
> etc.)
> with additional shorthand forms for cases where default values for many of
> those parameters would be acceptable, then it would be possible for existing
> compilers to accept declarations for types they naturally support merely by
> including a suitable header file, but compilers would be able to support
> both tighter and looser semantics as well. For example, under current rules
> a compiler with 16-bit "int" given a loop:
> for (int32_t i=start; i<=end; i++)
> could not assume that it will loop exactly (end-start) times since behavior
> would be defined as doing otherwise if end==INT32_MAX. If, however, the
> variable "i" were defined as not requiring numerical wraparound on storage,
> an optimizer may not need to honor such an obligation depending upon how
> "i" was defined.
> While the preprocessor macros necessary to convert declarations of such
> forms to pre-existing types would be a bit gnarly, I think they should be
> workable. Further, a lot of numerical code could be written to be both
> more efficient and easier to read if compilers could support some more
> integer behaviors.
GCC has the "__attribute__((...))" syntax, which I suppose might be
bent to this purpose, I presume other compilers have similar
mechanisms. I mainly decided saturating arithmetic was important for
program correctness in certain cases, and of course for process
control applications it could be highly critical to trap or otherwise
avoid wrapping from INT_MAX to INT_MIN.
Your proposal is interesting, and goes far beyond what I have so far
realized in the affected source module -- with only one exception. I
have sketched out macros which establish a range of values acceptable
for the result of an arithmetic operation. (Probably I will end up
writing a data structure to encapsulate the relevant information) In
any event I would extend your scheme as above to include a range of
accepted values; so one might do saturating arithmetic on a 16-bit
signed integer for which the allowable range of values is -500 through
500. The range should be arbitrary whereas you propose only to
specify the bit-width of the integer type. Obviously none of this
should affect the naive use case we all know and love today.
The problem with this (or your scheme as above) is that it implies
major surgery to the language; going by common wisdom in this
newsgroup I doubt many would accept it as a desirable feature. A
valid criticism is that it would make code more difficult to read.
Currently there is only one set of behaviors for integer operations.
Your proposal introduces an entirely new dimension to arithmetic
operations, and the only indication of behavior would be at the point
of variable definition. The way C is shaped your scheme might need to
be further extended such that constraints could be applied to
expressions as well as to variable definitions -- just to remain
consistent with the overall structure of the language. A cast on
steroids as it were.
There is nevertheless a strong case for strengthening the handling of
arithmetic operations in C. GCC has a complex number data type, so
why not stronger integers? There is no substitute for applications
which require the additional precision, and I personally do not wish
to use C++ as the solution.
Regards,
Steve Thompson
--
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-01 16:05 -0800 |
| Message-ID | <02b69c79-9f3a-4a0d-ab64-e622a81c09df@googlegroups.com> |
| In reply to | #74600 |
On Sunday, November 1, 2015 at 5:47:22 PM UTC-6, Steve Thompson wrote:
> The problem with this (or your scheme as above) is that it implies
> major surgery to the language; going by common wisdom in this
> newsgroup I doubt many would accept it as a desirable feature. A
> valid criticism is that it would make code more difficult to read.
Most likely programmers would define a few types using typedefs in a few
small places within their code, and then use those, so the nasty syntax
for declaring values would be confined to a few small places.
The reason the syntax is nasty would be to allow **existing** compilers to
support type declarations using the new syntax for their own pre-existing
types.
> Currently there is only one set of behaviors for integer operations.
Actually, there are quite a few. For any given size of integer a programmer
only gets to select two (signed or unsigned) but those two are taken from a
much larger pool of behaviors. Unfortunately, at present different compilers
are often required to interpret the same code in different ways. For example:
int compare_diff(uint16_t a, uint16_t b, uint16_t c)
{ return a-b > c; }
Further, on some platforms setting a int16_t to an odd value greater than
one and repeatedly squaring it will eventually yield Undefined Behavior,
and on others it will consistently yield defined behavior. The same is
true about uint16_t, but many platforms which yielded Undefined Behavior for
int16_t would yield defined behavior for uint16_t, and vice versa.
I would suggest that rather than having many different kinds of integer
behavior, but only letting each platform expose two to the programmer for
each size of integer, it would be much more helpful to recognize the
different kinds of behavior that already exist on various platforms and
allow programmers to specify what they actually need in platform-independent
fashion.
> Your proposal introduces an entirely new dimension to arithmetic
> operations, and the only indication of behavior would be at the point
> of variable definition. The way C is shaped your scheme might need to
> be further extended such that constraints could be applied to
> expressions as well as to variable definitions -- just to remain
> consistent with the overall structure of the language. A cast on
> steroids as it were.
I would figure a common usage pattern would be to use casting expressions,
but typically with typedef shortcuts.
> There is nevertheless a strong case for strengthening the handling of
> arithmetic operations in C. GCC has a complex number data type, so
> why not stronger integers? There is no substitute for applications
> which require the additional precision, and I personally do not wish
> to use C++ as the solution.
I agree.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-01 21:41 +0000 |
| Message-ID | <87wpu15rei.fsf@bsb.me.uk> |
| In reply to | #74542 |
Steve Thompson <stevet810@gmail.com> writes: > On Sat, Oct 31, 2015 at 06:05:59PM +0000, Ben Bacarisse wrote: <snip> >> I can't follow the requirement. There seem to be other reasons why >> ADD_INSTR_VAR(var) can't expand to the call you gave (for example I >> don't know the relationship between "var" and "VAR_UINT") but turning >> the variable name into a string does not seem to be it. Obviously since >> you know about # I must simply be getting the wrong end of this >> example. Sorry. > > My explanation was perhaps too sparse in detail. The goal of the > preceeding is to expose variables to programmed introspection. As > such, there must be (a) a pointer to the variable contents, (b) an > indication of its type and size, and (c) a string identifier to use as > a search key. Hence it would be useful to have a macro which can be > simply passed a symbol, and from that extract the relevant > information. So if I have > > int counter; > > i would like to have a macro that allows me to generate a char * > string from the 'counter' symbol -- which would be "counter". That *still* looks exactly like what # is for! > From > there I might use the '#' preprocessor directive to concatenate a > prefix, as in "sys.foo." # counter", but that is by the by. I'm not following this. Have you confused # and ##? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-11-01 22:46 +0000 |
| Message-ID | <kV4X3M.C5r.yH89q@gmail.com> |
| In reply to | #74586 |
On Sun, Nov 01, 2015 at 09:41:25PM +0000, Ben Bacarisse wrote:
> Steve Thompson <stevet810@gmail.com> writes:
>
> > On Sat, Oct 31, 2015 at 06:05:59PM +0000, Ben Bacarisse wrote:
> <snip>
> >> I can't follow the requirement. There seem to be other reasons why
> >> ADD_INSTR_VAR(var) can't expand to the call you gave (for example I
> >> don't know the relationship between "var" and "VAR_UINT") but turning
> >> the variable name into a string does not seem to be it. Obviously since
> >> you know about # I must simply be getting the wrong end of this
> >> example. Sorry.
> >
> > My explanation was perhaps too sparse in detail. The goal of the
> > preceeding is to expose variables to programmed introspection. As
> > such, there must be (a) a pointer to the variable contents, (b) an
> > indication of its type and size, and (c) a string identifier to use as
> > a search key. Hence it would be useful to have a macro which can be
> > simply passed a symbol, and from that extract the relevant
> > information. So if I have
> >
> > int counter;
> >
> > i would like to have a macro that allows me to generate a char *
> > string from the 'counter' symbol -- which would be "counter".
>
> That *still* looks exactly like what # is for!
>
> > From
> > there I might use the '#' preprocessor directive to concatenate a
> > prefix, as in "sys.foo." # counter", but that is by the by.
>
> I'm not following this. Have you confused # and ##?
Bloody hell. My brain ignored the the fact that the '#' operator was
missing from my C lexicon and automatically substituted '##' as a
convenience. I wish I knew how to turn off that feature option.
It did not take me long to figure out how the # operator works once I
knew it existed:
#include <stdio.h>
#include <stdlib.h>
#define FOO(bar) #bar
int main(int argc, char ** argv)
{
char * s = FOO(argc);
fprintf(stdout, "str: %s\n", s);
exit(0);
}
[20/22:31] d0:pts/13 user /tmp: gcc -o oper oper.c
[21/22:34] d0:pts/13 user /tmp: ./oper
str: argc
[22/22:34] d0:pts/13 user /tmp:
Way back in the first half of the Eighties when I was first exposed to
C I read a book on it; one of the QUE publications if I recall
correctly. It did not cover the '#' operator. I probably have a
draft of the C standard buried in my files somewhere, but reading it
is still on my todo list, obviously a major oversight on my part.
Sorry for the confusion.
I will now spend the evening revisiting the affected instrumentation
macros.
Regards,
Steve Thompson
--
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-31 18:22 +0000 |
| Message-ID | <n130oi$ob3$2@dont-email.me> |
| In reply to | #74449 |
On 31/10/2015 17:02, Steve Thompson wrote: > add_instr_var(&var, sizeof(var), VAR_UINT, nameof(var)); So, what's wrong with using "var" instead of nameof(var) ? Or do you want to omit the nameof(var) argument and have the function derive it from &var? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-10-31 23:57 +0000 |
| Message-ID | <LUfi7N.S2Y.Q13lv@gmail.com> |
| In reply to | #74466 |
On Sat, Oct 31, 2015 at 06:22:06PM +0000, Bartc wrote: > On 31/10/2015 17:02, Steve Thompson wrote: > > > add_instr_var(&var, sizeof(var), VAR_UINT, nameof(var)); > > So, what's wrong with using "var" instead of nameof(var) ? > > Or do you want to omit the nameof(var) argument and have the function > derive it from &var? Ideally it would be derived from 'var', the actual symbol in the code identifying the variable. This may seem like a non-issue if it is not clear that the use-case is a macro that fills out a data structure describing the program symbol, and as I explained in another message the ability to extract type information (integer, signedness) would be additionally helpful. However I eventually solve the problem, it is clear there will be a data structure describing variables of interest, all of which will be stored in a run-time dictionary. If I were writing a C interpreter you might imagine that the information I seek would be readily available to the interpreter. I merely wish to compile the same sort of information on conventional C variables. As an aside, it occurs to me that any variables or data structures identified in this way would have to be declared volatile to avoid unexpected data corruption. Regards, Steve Thompson -- "If I had a nickel for every time some idiot called me about a computer problem that turned out to be user error, I would be able to retire and spend the rest of my days cultivating clues in my backyard hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-10-31 17:20 +0000 |
| Message-ID | <GnnJGo.MaQ.baycE@gmail.com> |
| In reply to | #74386 |
On Sat, Oct 31, 2015 at 01:14:13AM +0000, Ben Bacarisse wrote: > Steve Thompson <stevet810@gmail.com> writes: > <snip> I would like to add that I did not mean to hijack this thread. My newsreader has a serious bug that I must work around by replying to an existing thread and manually adjusting the headers, which I forgot to do this time on account of unrelated stress factors. Regards, Steve Thompson -- "If I had a nickel for every time some idiot called me about a computer problem that turned out to be user error, I would be able to retire and spend the rest of my days cultivating clues in my backyard hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-31 13:38 +0000 |
| Message-ID | <n12g5m$nu6$1@dont-email.me> |
| In reply to | #74383 |
On 30/10/2015 23:29, Steve Thompson wrote:
> There seem to be a few individuals on this newsgroup who have a
> variety of features which they feel ought to be added to the C
> standard. I suppose I will have to count myself among their number
> due to this post. My gripe with the language is relatively minor. So
> far I can do most of what I want to do with existing features, but
> there are two things that appear to be missing, one of which appears
> to be a major oversight.
>
> First, I have found a few cases where the ability to use GCC macros as
> expressions is unavoidable. These are macros encapsulated with ({ ...
> }).
(Do you mean being to include any compound statement inside an
expression? If so that's nothing to do with macros.)
> This appears to be a GCC-ism and while I am not strident about
> requiring the standard to change to accommodate this extension, I am
> curious to know how widespread this feature is among non-GCC
> compilers. If I find that the feature is mainly restricted to GCC I
> may decide to refactor affected code as avoiding dependency on GCC is
> something of a priority for me.
gcc-specific features tend to be duplicated with the clang compiler (eg.
I use gcc's label pointers, which only clang will support other than
gcc, that I know of).
> The second missing feature is more important. As I am attempting to
> do some program introspection it has occurred to me that a preprocessor
> directive to take the name of an identifier as a char * array would be
> extremely valuable. Something like nameof(function) and
> nameof(variable) would be invaluable for my purposes.
What do you mean by 'function' or by 'variable'?
Presumably not just the name of a function or variable, since double
quotes around it will take care of that! (And # will do the job for
macro parameters.)
I would guess that 'function' and 'variable' are pointers, but you need
to be more specific.
I agree that some things are easy to add, such as a list of functions or
variables, which can then be accessed at runtime. Then you can create
your own functions to do address-to-name conversion.
(There are the usual things to be aware of: the same name can appear in
many different scopes, and a single auto variable in a function scope
can have many different instances.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-31 11:28 -0700 |
| Message-ID | <f7d58a48-4360-43a5-9591-a0e6c601153c@googlegroups.com> |
| In reply to | #74431 |
On Saturday, October 31, 2015 at 8:39:16 AM UTC-5, Bart wrote:
> On 30/10/2015 23:29, Steve Thompson wrote:
> > First, I have found a few cases where the ability to use GCC macros as
> > expressions is unavoidable. These are macros encapsulated with ({ ...
> > }).
>
> (Do you mean being to include any compound statement inside an
> expression? If so that's nothing to do with macros.)
I think Mr. Thompson probably meant "statements", but it should be noted
that one of the most useful purposes for that syntax is within macros, e.g.
something like [untested]
#define bitswap32(x) \
({ __builtin_const((x)) ? bitswap_const32(x) : bitswap_gen32(x); })
would accept a 32-bit argument and then either invoke a macro which will
yield a constant value if invoked on one, but perform inefficiently if
invoked on a non-constant, or else call a function which will work
efficiently on non-constant values but would waste time if invoked on a
constant and would not return a compile-time constant result in any case.
I don't think there's any way to achieve similar semantics in any form of
standard C.
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-11-01 00:06 +0000 |
| Message-ID | <2yxQ2F.HV1.7nao6@gmail.com> |
| In reply to | #74467 |
On Sat, Oct 31, 2015 at 11:28:21AM -0700, supercat@casperkitty.com wrote:
> On Saturday, October 31, 2015 at 8:39:16 AM UTC-5, Bart wrote:
> > On 30/10/2015 23:29, Steve Thompson wrote:
> > > First, I have found a few cases where the ability to use GCC macros as
> > > expressions is unavoidable. These are macros encapsulated with ({ ...
> > > }).
> >
> > (Do you mean being to include any compound statement inside an
> > expression? If so that's nothing to do with macros.)
>
> I think Mr. Thompson probably meant "statements", but it should be noted
> that one of the most useful purposes for that syntax is within macros, e.g.
> something like [untested]
>
> #define bitswap32(x) \
> ({ __builtin_const((x)) ? bitswap_const32(x) : bitswap_gen32(x); })
>
> would accept a 32-bit argument and then either invoke a macro which will
> yield a constant value if invoked on one, but perform inefficiently if
> invoked on a non-constant, or else call a function which will work
> efficiently on non-constant values but would waste time if invoked on a
> constant and would not return a compile-time constant result in any case.
>
> I don't think there's any way to achieve similar semantics in any form of
> standard C.
If you examine the macro I included in a recent reply to Ben you
should see that I coerce the compiler into doing something similar
with the min/max values, which (ought to, or will if it needs fixing)
resolve to the correct values regardless of the signedness of the
variable types used as arguments to the macro, at least as long as
they are integer types. In that instance I am leveraging the
preprocessor to resolve expressions into constant values which are
context dependent, and the relying on the optimizer to eliminate
redundant code in the macro.
Regards,
Steve Thompson
--
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-10-31 17:58 +0000 |
| Message-ID | <g4rpT2.y8x.xJyCC@gmail.com> |
| In reply to | #74431 |
On Sat, Oct 31, 2015 at 01:38:59PM +0000, Bartc wrote:
> On 30/10/2015 23:29, Steve Thompson wrote:
> >There seem to be a few individuals on this newsgroup who have a
> >variety of features which they feel ought to be added to the C
> >standard. I suppose I will have to count myself among their number
> >due to this post. My gripe with the language is relatively minor. So
> >far I can do most of what I want to do with existing features, but
> >there are two things that appear to be missing, one of which appears
> >to be a major oversight.
> >
> >First, I have found a few cases where the ability to use GCC macros as
> >expressions is unavoidable. These are macros encapsulated with ({ ...
> >}).
>
> (Do you mean being to include any compound statement inside an
> expression? If so that's nothing to do with macros.)
No, the issue is the use of a macro within an arithmetic expression:
if(MACRO(foo)) then whatever;
I have made another post with some code to illustrate my use-case
scenario.
> >This appears to be a GCC-ism and while I am not strident about
> >requiring the standard to change to accommodate this extension, I am
> >curious to know how widespread this feature is among non-GCC
> >compilers. If I find that the feature is mainly restricted to GCC I
> >may decide to refactor affected code as avoiding dependency on GCC is
> >something of a priority for me.
>
> gcc-specific features tend to be duplicated with the clang compiler (eg.
> I use gcc's label pointers, which only clang will support other than
> gcc, that I know of).
I have not yet investigated clang. I am concerned with products such
as the Intel and Sun compilers, as well as compiler products in use
for systems with which I lack exposure. I am essentially self-taught,
first with a C compiler running on the Icon QNX compiler supplied
with the computers at my high-school, later and later with GCC under
Linux. I am attempting to write code which is not tied to one
compiler, but GCC offers extensions, some of which I have 'learned' as
a natural part of C. I do not want to write a major project that is
fundamentally dependent on GCC.
> >The second missing feature is more important. As I am attempting to
> >do some program introspection it has occurred to me that a preprocessor
> >directive to take the name of an identifier as a char * array would be
> >extremely valuable. Something like nameof(function) and
> >nameof(variable) would be invaluable for my purposes.
>
> What do you mean by 'function' or by 'variable'?
>
> Presumably not just the name of a function or variable, since double
> quotes around it will take care of that! (And # will do the job for
> macro parameters.)
>
> I would guess that 'function' and 'variable' are pointers, but you need
> to be more specific.
>
> I agree that some things are easy to add, such as a list of functions or
> variables, which can then be accessed at runtime. Then you can create
> your own functions to do address-to-name conversion.
>
> (There are the usual things to be aware of: the same name can appear in
> many different scopes, and a single auto variable in a function scope
> can have many different instances.)
Please have a look at my reply to Ben for a bit more detail.
Regards,
Steve Thompson
--
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-10-31 01:14 -0700 |
| Message-ID | <f83baad8-2e17-43bc-b56f-8335f1205179@googlegroups.com> |
| In reply to | #73976 |
Although I have another thread on the issue I have raised on last pages of this one, I would like to say here also: Thank you Everyone! The issue with the program is now solved, I have fixed the wrapping-around problem, and the program produces correct outputs.
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.lang.c
csiph-web