Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #129945 > unrolled thread
| Started by | Real Troll <real.troll@trolls.com> |
|---|---|
| First post | 2018-04-30 02:10 +0000 |
| Last post | 2018-05-01 13:46 +0000 |
| Articles | 20 on this page of 208 — 30 participants |
Back to article view | Back to comp.lang.c
The case AGAINST C Real Troll <real.troll@trolls.com> - 2018-04-30 02:10 +0000
Re: The case AGAINST C cross@spitfire.i.gajendra.net (Dan Cross) - 2018-04-30 03:14 +0000
Re: The case AGAINST C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-30 05:48 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 14:58 +0100
Re: The case AGAINST C Davs <johndemeert0@gmail.com> - 2018-05-07 04:18 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 05:26 -0700
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 11:21 -0400
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 09:21 -0700
Re: The case AGAINST C Robert Wessel <robertwessel2@yahoo.com> - 2018-05-07 12:13 -0500
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 10:24 -0700
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 13:27 -0400
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-07 17:33 +0000
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 13:50 -0400
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 10:56 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 09:26 +0200
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 09:19 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-08 00:42 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 06:54 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-08 07:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 17:15 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 09:31 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 18:48 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 10:33 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:36 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 15:08 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 00:56 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 16:17 -0700
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-08 11:09 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:43 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 15:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 00:58 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-09 08:11 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 08:51 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 11:45 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 13:03 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 23:40 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-09 15:48 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-10 13:48 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-10 08:28 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-11 10:06 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 02:22 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 05:29 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-11 13:31 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-11 15:47 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-11 09:16 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-12 17:43 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-12 14:06 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-10 00:13 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-10 01:31 -0700
Re: The case AGAINST C Wouter Verhelst <w@uter.be> - 2018-05-11 18:01 +0200
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-10 08:30 -0700
Re: The case AGAINST C Wouter Verhelst <w@uter.be> - 2018-05-09 09:29 +0200
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-10 08:41 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 04:43 -0700
Re: The case AGAINST C Richard Damon <Richard@Damon-Family.org> - 2018-05-08 21:24 -0400
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 09:10 +0200
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-08 19:52 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:48 +0200
Re: The case AGAINST C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-29 22:07 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 12:22 +0100
Re: The case AGAINST C Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-30 12:08 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 13:38 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 06:05 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-04-30 07:39 -0700
Re: The case AGAINST C Ed Kellett <e@kellett.im> - 2018-04-30 15:53 +0100
Re: The case AGAINST C supercat@casperkitty.com - 2018-04-30 08:14 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 21:26 -0700
Re: The case AGAINST C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-30 09:00 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-01 04:58 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 18:07 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 05:33 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 05:58 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 06:27 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 14:37 +0100
Re: The case AGAINST C Melzzzzz <Melzzzzz@zzzzz.com> - 2018-05-01 13:41 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 16:48 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-01 10:11 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 11:00 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 19:26 +0100
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 11:40 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 12:53 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 22:03 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-02 09:10 +1200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 14:21 -0700
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-02 09:26 +1200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 15:23 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-02 14:07 +0000
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-03 06:28 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 23:03 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-02 04:52 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-02 05:12 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 05:34 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-02 14:08 +0000
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 07:39 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 17:13 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 11:01 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 21:51 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 08:52 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 22:42 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 09:57 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 23:22 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 10:29 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 00:14 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 03:59 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 04:15 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 12:50 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 13:36 -0700
Of course I get it... (Was: The case AGAINST C) gazelle@shell.xmission.com (Kenny McCormack) - 2018-05-03 08:44 +0000
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 12:42 +0000
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 05:52 -0700
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 12:56 +0000
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 05:58 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 14:36 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-03 13:27 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 22:43 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-03 15:17 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 00:50 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 15:41 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-04 11:36 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 08:52 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-04 17:28 +0000
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 12:06 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-05 18:45 +0200
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-06 18:43 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 23:35 +0200
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-07 13:23 +0000
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 06:30 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-07 16:25 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 07:32 -0700
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 09:09 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 18:12 +0100
Global variables bartc <bc@freeuk.com> - 2018-05-06 14:07 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 20:03 +0200
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 15:21 -0400
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-06 13:07 -0700
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 16:13 -0400
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:39 +0200
Re: Global variables Richard Damon <Richard@Damon-Family.org> - 2018-05-06 17:50 -0400
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:57 +0200
Re: Global variables Richard Damon <Richard@Damon-Family.org> - 2018-05-06 19:56 -0400
Re: Global variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-07 03:21 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-07 09:09 +0200
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-07 08:49 -0700
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 20:55 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:51 +0200
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-06 15:40 -0700
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 23:54 +0100
Re: Global variables Ian Collins <ian-news@hotmail.com> - 2018-05-07 15:12 +1200
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-07 09:03 +0200
Re: Global variables Tim Rentsch <txr@alumni.caltech.edu> - 2018-05-18 20:23 -0700
Re: Global variables Steve Carroll <frelwizzen@gmail.com> - 2018-05-18 20:44 -0700
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-19 17:22 +0200
Re: Global variables supercat@casperkitty.com - 2018-05-19 11:56 -0700
Re: Global variables supercat@casperkitty.com - 2018-05-06 16:28 -0700
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 14:19 -0400
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 20:16 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:09 +0200
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 23:41 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-03 09:13 -0700
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 17:29 +0000
Re: The case AGAINST C gazelle@shell.xmission.com (Kenny McCormack) - 2018-05-03 19:24 +0000
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-04 05:46 +0000
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-04 10:55 +0000
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 04:03 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 12:31 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-04 05:10 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 13:24 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 06:26 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 06:35 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 07:06 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 07:19 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 06:37 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 08:19 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 12:07 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 16:31 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 08:41 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 09:50 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 10:04 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 13:51 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 14:30 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 15:14 -0700
Re: The case AGAINST C Robert Wessel <robertwessel2@yahoo.com> - 2018-05-04 11:18 -0500
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 09:05 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 17:55 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 10:54 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 19:18 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 11:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 16:45 +0200
Re: The case AGAINST C jameskuyper@alumni.caltech.edu - 2018-05-04 11:51 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 12:15 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 21:56 +0100
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 17:01 +0200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-06 17:54 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 13:38 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-06 21:49 +0100
Re: The case AGAINST C Richard Damon <Richard@Damon-Family.org> - 2018-05-06 17:19 -0400
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 15:24 -0700
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 15:16 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-06 23:55 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-06 11:59 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 14:51 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 04:46 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 11:45 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 06:10 -0700
Re: The case AGAINST C C W Rose <cwr@seckford.org> - 2018-05-02 15:23 +0100
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 17:36 +0100
Re: The case AGAINST C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-04-30 22:03 +0800
Re: The case AGAINST C Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-05-01 13:46 +0000
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-05-07 03:21 +0100 |
| Subject | Re: Global variables |
| Message-ID | <87o9hsqk7d.fsf@bsb.me.uk> |
| In reply to | #130297 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 5/6/18 5:57 PM, David Brown wrote:
>> On 06/05/18 23:50, Richard Damon wrote:
>>> On 5/6/18 5:39 PM, David Brown wrote:
>>>> On 06/05/18 21:21, Lew Pitcher wrote:
>>>>> David Brown wrote:
>>>>> [snip]
>>>>>> The C standards don't have anything to say about having multiple
>>>>>> definitions (identical or otherwise) of a variable in a program.
>>>>
>>>> I was not explicit in this, but we were talking about having more than
>>>> one definition of a variable with external linkage, with one definition
>>>> in each translation unit. (That's what you get if you have a header
>>>> file with "int x;" and include it from several C files that are then
>>>> linked together.) The paragraphs you quote are all about multiple
>>>> definitions within the same translation unit.
>>>>
>>>
>>> One item in J.2 is
>>> An identifier with external linkage is used, but in the program there
>>> does not exist exactly one external definition for the identifier, or
>>> the identifier is not used and there exist multiple external definitions
>>> for the identifier (6.9).
>>>
>>
>> Interesting - this does not correspond directly to anything in 6.9 (as
>> the nominative text does not mention the whole program).
6.9 p5 talks about "the entire program".
> Most of 6.9 is defining conditions that the implementation is required
> to diagnose. Most 'whole program' issues are not required to be
> diagnosed.
6.9 paragraphs 1 to 3 (syntax and constraints) do that because
violations of syntax or constraints must be diagnosed, but violations of
anything in paragraphs 4 and 5 (semantics) don't have to be diagnosed.
>>> While Appendex J is Informative, it indicates that the implication that
>>> the lack of a explicit definition of how to handle multiple definitions
>>> (not exactly one definition) of an object with external linkage falls to
>>> the standards definition of undefined behavior.
>>>
>>
>> Even if it were not mentioned explicitly in J.2, I /think/ there is
>> enough in the main text to say that the behaviour of a program with
>> multiple definitions of the same object would be undefined behaviour due
>> to the omission of a definition for it.
>>
>> Linkers and C implementations can, of course, give a definition to the
>> behaviour above and beyond the C standard here - and many do so.
>>
>
> Yes, the normative description is implicitly of a single definition, so
> the lack of any other mention makes it fall as undefined by omission.
I'm not seeing this, though I may have lost track of this discussion!
The behaviour appears to be explicitly undefined due to the violation of
a "shall":
6.9
...
5 [...] If an identifier declared with external linkage is used in an
expression [...], somewhere in the entire program there shall be
exactly one external definition for the identifier; otherwise, there
shall be no more than one."
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-07 09:09 +0200 |
| Subject | Re: Global variables |
| Message-ID | <pcou2j$k4p$1@dont-email.me> |
| In reply to | #130300 |
On 07/05/18 04:21, Ben Bacarisse wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> On 5/6/18 5:57 PM, David Brown wrote: <snip> >> >> Yes, the normative description is implicitly of a single definition, so >> the lack of any other mention makes it fall as undefined by omission. > > I'm not seeing this, though I may have lost track of this discussion! > The behaviour appears to be explicitly undefined due to the violation of > a "shall": > > 6.9 > ... > 5 [...] If an identifier declared with external linkage is used in an > expression [...], somewhere in the entire program there shall be > exactly one external definition for the identifier; otherwise, there > shall be no more than one." > It seems 6.9p5 is the bit I have been missing, and that it does say explicitly that you may not have more than one definition of the same object (or function) in the program. So despite being commonly supported by most C implementations (unless you use something like "-fno-common"), having multiple "int x;" definitions in different compilation units in the same program is not allowed. Thanks to Richard and Ben (and others) for educating me here.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-07 08:49 -0700 |
| Subject | Re: Global variables |
| Message-ID | <ln1senbh5d.fsf@kst-u.example.com> |
| In reply to | #130304 |
David Brown <david.brown@hesbynett.no> writes:
> On 07/05/18 04:21, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> On 5/6/18 5:57 PM, David Brown wrote:
> <snip>
>>>
>>> Yes, the normative description is implicitly of a single definition, so
>>> the lack of any other mention makes it fall as undefined by omission.
>>
>> I'm not seeing this, though I may have lost track of this discussion!
>> The behaviour appears to be explicitly undefined due to the violation of
>> a "shall":
>>
>> 6.9
>> ...
>> 5 [...] If an identifier declared with external linkage is used in an
>> expression [...], somewhere in the entire program there shall be
>> exactly one external definition for the identifier; otherwise, there
>> shall be no more than one."
>>
>
> It seems 6.9p5 is the bit I have been missing, and that it does say
> explicitly that you may not have more than one definition of the same
> object (or function) in the program. So despite being commonly
> supported by most C implementations (unless you use something like
> "-fno-common"), having multiple "int x;" definitions in different
> compilation units in the same program is not allowed.
>
> Thanks to Richard and Ben (and others) for educating me here.
It's not exactly "not allowed". Having multiple definitions violates
a "shall" outside a constraint, so it causes undefined behavior.
An implementation is free to define the behavior in any way it likes,
or to behave in any way it likes without documenting the behavior.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-06 20:55 +0100 |
| Subject | Re: Global variables |
| Message-ID | <65JHC.109059$eg.30545@fx43.am4> |
| In reply to | #130261 |
On 06/05/2018 19:03, David Brown wrote:
> On 06/05/18 15:07, bartc wrote:
[Allowing () parameter lists]
> Another mistake from the programmer, not the language.
In my opinion it is a language mistake. If such a feature is genuinely
needed from time to time, use (flex) for that, and perhaps change the
meaning of () to be synonymous with (void).
>> Here's how it works in one of my current languages; names declared at
>> module scope:
>>
>> int abc # defined variable, not exported
>>
>> global int def # defined variable, exported
>>
>> There is no need for an 'extern' version, as 'import' takes care of
>> those details.
>
> I would not want that.
(Why am I not surprised?)
> I prefer to have the interface for a module -
> the exported part - declared independently.
My current compiler will produce an exports file listing everything
necessary for such an interface.
(Example for a dynamic language implementing a simple graphics library:
https://pastebin.com/raw/7JbKCfhs. The # comments are extracted from the
actual source code.)
At the moment, if I'm editing xyz.m and need a new library function
product(), then I might put it inside xyzlib.m:
global function product(int a,b,c)int =
return a*b*c
end
If I compile that, then it is instantly available to use in xyz.m. It
just needs 'import xyzlib'.
I don't need to waste time writing /and maintaining/ a separate version
of the declaration for an interface file.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-06 23:51 +0200 |
| Subject | Re: Global variables |
| Message-ID | <pcntds$df1$1@dont-email.me> |
| In reply to | #130269 |
On 06/05/18 21:55, bartc wrote: > On 06/05/2018 19:03, David Brown wrote: >> On 06/05/18 15:07, bartc wrote: > > [Allowing () parameter lists] > >> Another mistake from the programmer, not the language. > > In my opinion it is a language mistake. If such a feature is genuinely > needed from time to time, use (flex) for that, and perhaps change the > meaning of () to be synonymous with (void). For C, backwards compatibility is key - so the meaning of "foo()" cannot be changed to "foo(void)", as it is in C++. And C /does/ have a syntax for declaring variadic functions, using "...". So "foo()" is never necessary, or even useful, as far as I can see, in C89 or newer code. But because it /was/ necessary before, and exists in useful C source code, it has to be supported by current compilers. I'd be happier to see compilers warn on it be default - and think it is ridiculous that it is not part of things like gcc's -Wall warning sets. Still, if you /write/ "foo()", it is /your/ fault. It is badly written code. Just because the compiler accepts it, does not mean that the programmer is not to blame for using it. > >>> Here's how it works in one of my current languages; names declared at >>> module scope: >>> >>> int abc # defined variable, not exported >>> >>> global int def # defined variable, exported >>> >>> There is no need for an 'extern' version, as 'import' takes care of >>> those details. >> >> I would not want that. > > (Why am I not surprised?) Probably because you think that I think C is a perfect language. You are wrong, of course. You snipped the bit where I said why I would not want to export symbols in the way you have here. > >> I prefer to have the interface for a module - the exported part - >> declared independently. > > My current compiler will produce an exports file listing everything > necessary for such an interface. > I would not want that. I would want an interface file that /I/ wrote. With the declarations I want, in the way I want them, documented and commented as I want. Comments in a header or interface file tell the module user how to use the functions, structures and data. Comments in an implementation tell the reader (especially maintainers) how the functionality is achieved, and why the code is written in that particular way. These are totally different, with different information for different audiences. > (Example for a dynamic language implementing a simple graphics library: > https://pastebin.com/raw/7JbKCfhs. The # comments are extracted from the > actual source code.) > > At the moment, if I'm editing xyz.m and need a new library function > product(), then I might put it inside xyzlib.m: > > global function product(int a,b,c)int = > return a*b*c > end > > If I compile that, then it is instantly available to use in xyz.m. It > just needs 'import xyzlib'. > > I don't need to waste time writing /and maintaining/ a separate version > of the declaration for an interface file. > If you think that would be a waste of time, then I think you must have a very poor development process - both because you think it takes a noticeable amount of time, and because you think it is a waste.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-06 15:40 -0700 |
| Subject | Re: Global variables |
| Message-ID | <ln6040be7u.fsf@kst-u.example.com> |
| In reply to | #130283 |
David Brown <david.brown@hesbynett.no> writes:
> On 06/05/18 21:55, bartc wrote:
>> On 06/05/2018 19:03, David Brown wrote:
>>> On 06/05/18 15:07, bartc wrote:
>>
>> [Allowing () parameter lists]
>>
>>> Another mistake from the programmer, not the language.
>>
>> In my opinion it is a language mistake. If such a feature is genuinely
>> needed from time to time, use (flex) for that, and perhaps change the
>> meaning of () to be synonymous with (void).
>
> For C, backwards compatibility is key - so the meaning of "foo()" cannot
> be changed to "foo(void)", as it is in C++. And C /does/ have a syntax
> for declaring variadic functions, using "...". So "foo()" is never
> necessary, or even useful, as far as I can see, in C89 or newer code.
>
> But because it /was/ necessary before, and exists in useful C source
> code, it has to be supported by current compilers.
It has to be supported by current compilers because the standard says
so.
But it's been obsolescent since 1989, and a future standard *could*
remove them from the language. Backwards compatibility is important,
but it's not the only criterion for deciding whether to keep a feature.
Note that C99 dropped implicit int and C11 dropped gets(), both changes
that broke some existing code ("broke" in the sense of making it
non-conforming).
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-06 23:54 +0100 |
| Subject | Re: Global variables |
| Message-ID | <RILHC.74024$ny5.20170@fx17.am4> |
| In reply to | #130283 |
On 06/05/2018 22:51, David Brown wrote:
> On 06/05/18 21:55, bartc wrote:
>> My current compiler will produce an exports file listing everything
>> necessary for such an interface.
>>
>
> I would not want that. I would want an interface file that /I/ wrote.
> With the declarations I want, in the way I want them, documented and
> commented as I want.
I suppose there's nothing stopping you doing that if you want.
But the language doesn't need it and doesn't care.
>
> Comments in a header or interface file tell the module user how to use
> the functions, structures and data. Comments in an implementation tell
> the reader (especially maintainers) how the functionality is achieved,
> and why the code is written in that particular way. These are totally
> different, with different information for different audiences.
(I made a distinction between ordinary comments, and those - doc-strings
- that are added to the exports file.
However, proper documentation is a separate matter that is not really
within the remit of a language or implementation.
And per-function doc-strings only really serve as a reference; something
is else is needed for the big picture.)
>> global function product(int a,b,c)int =
>> return a*b*c
>> end
>>
>> If I compile that, then it is instantly available to use in xyz.m. It
>> just needs 'import xyzlib'.
>>
>> I don't need to waste time writing /and maintaining/ a separate
>> version of the declaration for an interface file.
>>
>
> If you think that would be a waste of time, then I think you must have a
> very poor development process - both because you think it takes a
> noticeable amount of time, and because you think it is a waste.
If I compile that product() function, then I automatically get an
exports file containing this:
importmodule test =
function product(int a,int b,int c)int
end importmodule
What purpose would be served by my writing this by hand? It might change
5 minutes later or disappear completely. Or be moved to a different module.
Believe me, this module system is a godsend.
You seem to have a pattern of automatically disliking any language ideas
I come up with, and preferring how it's done in C, just brushing away
all the extra effort involved.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-07 15:12 +1200 |
| Subject | Re: Global variables |
| Message-ID | <fl9ugkFj48lU1@mid.individual.net> |
| In reply to | #130283 |
On 05/07/2018 09:51 AM, David Brown wrote: > On 06/05/18 21:55, bartc wrote: >> On 06/05/2018 19:03, David Brown wrote: >>> On 06/05/18 15:07, bartc wrote: >> >> [Allowing () parameter lists] >> >>> Another mistake from the programmer, not the language. >> >> In my opinion it is a language mistake. If such a feature is genuinely >> needed from time to time, use (flex) for that, and perhaps change the >> meaning of () to be synonymous with (void). > > For C, backwards compatibility is key - so the meaning of "foo()" cannot > be changed to "foo(void)", as it is in C++. And C /does/ have a syntax > for declaring variadic functions, using "...". So "foo()" is never > necessary, or even useful, as far as I can see, in C89 or newer code. > > But because it /was/ necessary before, and exists in useful C source > code, it has to be supported by current compilers. It could be dropped and supported by new compilers in C < whatever standard dropped it mode. In my opinion it should be long gone! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-07 09:03 +0200 |
| Subject | Re: Global variables |
| Message-ID | <pcotog$hap$1@dont-email.me> |
| In reply to | #130301 |
On 07/05/18 05:12, Ian Collins wrote: > On 05/07/2018 09:51 AM, David Brown wrote: >> On 06/05/18 21:55, bartc wrote: >>> On 06/05/2018 19:03, David Brown wrote: >>>> On 06/05/18 15:07, bartc wrote: >>> >>> [Allowing () parameter lists] >>> >>>> Another mistake from the programmer, not the language. >>> >>> In my opinion it is a language mistake. If such a feature is genuinely >>> needed from time to time, use (flex) for that, and perhaps change the >>> meaning of () to be synonymous with (void). >> >> For C, backwards compatibility is key - so the meaning of "foo()" cannot >> be changed to "foo(void)", as it is in C++. And C /does/ have a syntax >> for declaring variadic functions, using "...". So "foo()" is never >> necessary, or even useful, as far as I can see, in C89 or newer code. >> >> But because it /was/ necessary before, and exists in useful C source >> code, it has to be supported by current compilers. > > It could be dropped and supported by new compilers in C < whatever > standard dropped it mode. In my opinion it should be long gone! > That would be my preference too.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-05-18 20:23 -0700 |
| Subject | Re: Global variables |
| Message-ID | <kfn4lj4jpl6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #130301 |
Ian Collins <ian-news@hotmail.com> writes: > On 05/07/2018 09:51 AM, David Brown wrote: > >> On 06/05/18 21:55, bartc wrote: >> >>> On 06/05/2018 19:03, David Brown wrote: >>> >>>> On 06/05/18 15:07, bartc wrote: >>> >>> [Allowing () parameter lists] >>> >>>> Another mistake from the programmer, not the language. >>> >>> In my opinion it is a language mistake. If such a feature is genuinely >>> needed from time to time, use (flex) for that, and perhaps change the >>> meaning of () to be synonymous with (void). >> >> For C, backwards compatibility is key - so the meaning of "foo()" cannot >> be changed to "foo(void)", as it is in C++. And C /does/ have a syntax >> for declaring variadic functions, using "...". So "foo()" is never >> necessary, or even useful, as far as I can see, in C89 or newer code. >> >> But because it /was/ necessary before, and exists in useful C source >> code, it has to be supported by current compilers. > > It could be dropped and supported by new compilers in C < whatever > standard dropped it mode. In my opinion it should be long gone! A better idea is to add a standard #pragma that enables the new behavior desired. Old code keeps working, each team can choose the option (or options plural) that better suits their needs, and no team or project becomes a second-class citizen in the larger community.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-18 20:44 -0700 |
| Subject | Re: Global variables |
| Message-ID | <95854228-de06-4a3b-9231-3f690920aed6@googlegroups.com> |
| In reply to | #130790 |
On Friday, May 18, 2018 at 8:23:40 PM UTC-7, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > > > On 05/07/2018 09:51 AM, David Brown wrote: > > > >> On 06/05/18 21:55, bartc wrote: > >> > >>> On 06/05/2018 19:03, David Brown wrote: > >>> > >>>> On 06/05/18 15:07, bartc wrote: > >>> > >>> [Allowing () parameter lists] > >>> > >>>> Another mistake from the programmer, not the language. > >>> > >>> In my opinion it is a language mistake. If such a feature is genuinely > >>> needed from time to time, use (flex) for that, and perhaps change the > >>> meaning of () to be synonymous with (void). > >> > >> For C, backwards compatibility is key - so the meaning of "foo()" cannot > >> be changed to "foo(void)", as it is in C++. And C /does/ have a syntax > >> for declaring variadic functions, using "...". So "foo()" is never > >> necessary, or even useful, as far as I can see, in C89 or newer code. > >> > >> But because it /was/ necessary before, and exists in useful C source > >> code, it has to be supported by current compilers. > > > > It could be dropped and supported by new compilers in C < whatever > > standard dropped it mode. In my opinion it should be long gone! > > A better idea is to add a standard #pragma that enables the new > behavior desired. Old code keeps working, each team can choose > the option (or options plural) that better suits their needs, and > no team or project becomes a second-class citizen in the larger > community. Requesting Despicable 'The Fool' Owl to atone, as fruitless as it is, is not the same as referencing his duplicity. My main idea was that advocates show up here _to_ battle those who disagree. It is not like most do not quickly figure out what this forum is, Snit included. Where did you go to school? That's what Despicable 'The Fool' Owl does when he gets cornered. He of course creates a puppet, starts a new thread so he can claim he didn't do it. Don't blame me it was my left hand... and then Despicable 'The Fool' Owl babbles to it with his right hand. Proof Sandman accuses everyone of being Snit http://sandman.net/files/snit_circus.png. Generally, I wouldn't call a comment like Despicable 'The Fool' Owl's claims a fabrication right up until you refute it (as you are here) and Despicable 'The Fool' Owl responds with the same thing again without offering any evidence. He's obviously dishonest, he got busted and he's doing the predictable ego protecting funny business taught in https://goo.gl/JsDUwi as he does his damnedest to be given a smattering of honor... but it blew up in his face. How is GIMP on Linux doing anything above the lowest common denominator? -- Get Rich Slow http://www.5z8.info/yourdick_v1o3ww_manhunter https://www.facebook.com/jenny.eklund Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-19 17:22 +0200 |
| Subject | Re: Global variables |
| Message-ID | <pdpfgn$2q2$1@dont-email.me> |
| In reply to | #130790 |
On 19/05/18 05:23, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 05/07/2018 09:51 AM, David Brown wrote: >> >>> On 06/05/18 21:55, bartc wrote: >>> >>>> On 06/05/2018 19:03, David Brown wrote: >>>> >>>>> On 06/05/18 15:07, bartc wrote: >>>> >>>> [Allowing () parameter lists] >>>> >>>>> Another mistake from the programmer, not the language. >>>> >>>> In my opinion it is a language mistake. If such a feature is genuinely >>>> needed from time to time, use (flex) for that, and perhaps change the >>>> meaning of () to be synonymous with (void). >>> >>> For C, backwards compatibility is key - so the meaning of "foo()" cannot >>> be changed to "foo(void)", as it is in C++. And C /does/ have a syntax >>> for declaring variadic functions, using "...". So "foo()" is never >>> necessary, or even useful, as far as I can see, in C89 or newer code. >>> >>> But because it /was/ necessary before, and exists in useful C source >>> code, it has to be supported by current compilers. >> >> It could be dropped and supported by new compilers in C < whatever >> standard dropped it mode. In my opinion it should be long gone! > > A better idea is to add a standard #pragma that enables the new > behavior desired. Old code keeps working, each team can choose > the option (or options plural) that better suits their needs, and > no team or project becomes a second-class citizen in the larger > community. > That is good for keeping backwards compatibility, but is not as good for encouraging new, better behaviour. People have a tendency to continue using old coding styles and techniques unless forced to think about something new and better. If compilers were to reject code with "foo()" declarations, it would require people to change - you would either have to specifically add "this is old code" flags or pragmas, or fix the code to use proper prototypes. That would greatly speed the process of getting ride of the old style and having all C code written with prototypes. The cost, obviously, is that some code that compiled warning and error free would no longer compile without additional effort. In my opinion, non-prototype function declarations have been marked obsolete for long enough - nearly 30 years. It is reasonable to say that they are no longer wanted.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-19 11:56 -0700 |
| Subject | Re: Global variables |
| Message-ID | <43272644-0236-4c18-b810-63d113a73a0e@googlegroups.com> |
| In reply to | #130802 |
On Saturday, May 19, 2018 at 10:23:13 AM UTC-5, David Brown wrote:
> > A better idea is to add a standard #pragma that enables the new
> > behavior desired. Old code keeps working, each team can choose
> > the option (or options plural) that better suits their needs, and
> > no team or project becomes a second-class citizen in the larger
> > community.
>
> That is good for keeping backwards compatibility, but is not as good for
> encouraging new, better behaviour. People have a tendency to continue
> using old coding styles and techniques unless forced to think about
> something new and better. If compilers were to reject code with "foo()"
> declarations, it would require people to change - you would either have
> to specifically add "this is old code" flags or pragmas, or fix the code
> to use proper prototypes. That would greatly speed the process of
> getting ride of the old style and having all C code written with
> prototypes. The cost, obviously, is that some code that compiled
> warning and error free would no longer compile without additional effort.
If the Standard were to replace the One Program rule with a rule that
a conforming implementation may at almost any time indicate (in
Implementation-Defined fashion) a refusal to process or continue
processing a program whose meaning is defined by the Standard, but
that unless or until an an implementation issues such a refusal it must
behave in conforming standard, that would let the marketplace decide
whether it was better to accept or reject programs that use the old
syntax without explicitly requesting either acceptance or rejection.
> In my opinion, non-prototype function declarations have been marked
> obsolete for long enough - nearly 30 years. It is reasonable to say
> that they are no longer wanted.
Non-prototype declarations of actual functions are pretty well obsolete
for most purposes, though they might sometimes be needed for code that
interacts with code written in other languages. Having an explicit
syntax for that which could be easily accommodated by old compilers, e.g.
requiring that implementations pre-define a macro _STDC_UNKNOWN_ARGS
which binds to a compiler intrinsic would make it possible for a source
file that starts with:
#ifndef _STDC_UNKNOWN_ARGS
#define _STDC_UNKNOWN_ARGS
#endif
to use foo(_STDC_UNKNOWN_ARGS) in places where it would have previously
used foo(), without affecting compatibility with old implementations.
Incidentally, on a related note, I would say that "foo(...)" should be
an optional syntax which implementations should support on platforms
where it would be meaningful, but reject on platforms where it would not.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-06 16:28 -0700 |
| Subject | Re: Global variables |
| Message-ID | <608da596-f4c3-448f-974d-9ab2437f0dd0@googlegroups.com> |
| In reply to | #130261 |
On Sunday, May 6, 2018 at 1:04:09 PM UTC-5, David Brown wrote:
> No, neither compilers nor linkers /have/ to report on such problems.
>
> You seem to be getting your knickers in a twist here about something
> that I /agree/ is a bad feature, something that I /agree/ should never
> be used, and that I /agree/ should never have been allowed in the first
> place.
>
> The C standards don't have anything to say about having multiple
> definitions (identical or otherwise) of a variable in a program. Early
> pre-standard C toolchains supported it, and code was written that used
> it - so later toolchains kept it for compatibility. I think that was a
> mistake.
In cases where some existing programs require constructs which cannot
practically be supported on all build chains, the authors of the
Standard tend to simply treat the construct as UB. They do this whether
or not there would be any imaginable reason for a build chain not to do
one of the following:
1. Issue a diagnostic and refuse to process the program.
2. Issue a diagnostic, but process the program in a fashion which
is (except for the diagnostic) consistent among all
implementations that would not reject the program.
3. Silently accept the program in a fashion which, as above, is
consistent (except for the lack of diagnostic) among all
implementations that would not reject the program.
IMHO, the Standard would have been much more useful if it had recognized
that there are variations in implementations and recommended that programs
should things in the widely-supported fashion when practical, but that
implementations which support other ways of doing things may be usable
with a wider range of programs than those which don't.
On a similar note, there should have been prototype forms for functions
with completely-variable arguments (no fixed first member), or with
unknown arguments, but with the caveat that implementations need not
support such constructs, but should reject programs that use them unless
they can support them in predictable fashion.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2018-05-06 14:19 -0400 |
| Subject | Re: Global variables |
| Message-ID | <pcngvl$oqf$1@dont-email.me> |
| In reply to | #130257 |
bartc wrote: [snip] > Here's a beautiful example of getting it wrong, a simple 5-module > 1-header project: > > http://kociemba.org/downloads/optiqtmSrc.zip # (rubik's cube solver) > > The header declares lots of global variables and tables, The term "global variable", while in common (and usually quite understandable) use, doesn't actually occur in the C standard. The closest concept to that is an "External object definition" (per section 6.9.2) which gives us two types of object: - an "external definition", which is (roughly) an object, declared at file scope, with an initializer, and - a "tentative definition", which is (roughly) an object, declared at file scope, without an initializer. > without using extern The standard does not seem to impose a requirement for an external definition or a tentative definition to use the "extern" storage class specifier. Like "auto" within a function "extern" is assumed (when a storage class is not explicitly specified) on definitions that appear /outside/ a function. > and without them being also declared in one of the C files, True, but misleading. A header file contributes nothing to a compilation /unless/ it is #included in a source file or compiled /as/ a source file. Your C source files #include your header, and thus (once translation stage 4 is complete) the external and tentative definitions contained in the headers have been handled as if they /had/ been "declared in one of the C files". > which has the effect that they are seen as defined, exported variables > from each C file that uses them. As is the explicit requirements of the C language, and the default behaviour of most compilers. > My linker complained about multiple definitions of variables. From the Standard C standpoint, wouldn't that make your linker "wrong"? Historically, linkage editors assign the same storage location to multiple storage definitions that have both the same name and size, and are uninitialized. Additionally, (again historically) linkage editors defer to the initialized storage definition if it exists. Here's where /your/ linker differs from both the historic norm, and the requirements of the C language. > But no other C compiler's linker said anything at all As would be expected. > (apart from one that crashed, I believe for other reasons). [snip] -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-06 20:16 +0100 |
| Subject | Re: Global variables |
| Message-ID | <IwIHC.237614$5v7.81786@fx02.am4> |
| In reply to | #130262 |
On 06/05/2018 19:19, Lew Pitcher wrote:
>> My linker complained about multiple definitions of variables.
>
> From the Standard C standpoint, wouldn't that make your linker "wrong"?
> Historically, linkage editors assign the same storage location to multiple
> storage definitions that have both the same name and size, and are
> uninitialized. Additionally, (again historically) linkage editors defer to
> the initialized storage definition if it exists.
>
> Here's where /your/ linker differs from both the historic norm, and the
> requirements of the C language.
>
>> But no other C compiler's linker said anything at all
>
> As would be expected.
I expect that they all started by working sensibly, then had to adjust
to existing practice in order to be able to compile existing C which
doesn't follow the rules. (As far as I can see, 'extern' is never really
needed because there never seem to be any consequences of not using it.)
Instead of non-static module variables in a C module, being in either
Initialised or Uninitialised sections (.data or .bss), C makes use of a
third category: Undefined [I think called .comm in gcc/asm files].
This just sounds like more sloppiness in the language. This is how it
can be done according to the rules:
======= Unexported Variable ======
static int abc; // in body of the module
==================================
======= Exported Variable ========
extern int abc; // probably in header
int abc; // in body of the module
==================================
======= Imported Variable ========
extern int abc; // probably in header
// not declared in body
==================================
======= Exported, Initialised ====
extern int abc; // probably in header
int abc = 1234; // in body of the module
==================================
There is no need for tentative definitions, certainly not ones that are
still tentative at the end of the source file. (Neither is there any
need for more than two declarations of a variable; it seems 1000
declarations are fine.)
And therefore there is no need for compilers and linkers to pander to
the sloppiness. Especially as the more they do so, the more every new
compiler and linker needs to do the same.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-06 23:09 +0200 |
| Subject | Re: Global variables |
| Message-ID | <pcnqus$u15$1@dont-email.me> |
| In reply to | #130266 |
On 06/05/18 21:16, bartc wrote: > On 06/05/2018 19:19, Lew Pitcher wrote: > >>> My linker complained about multiple definitions of variables. >> >> From the Standard C standpoint, wouldn't that make your linker "wrong"? > > > >> Historically, linkage editors assign the same storage location to >> multiple >> storage definitions that have both the same name and size, and are >> uninitialized. Yes, this is something linkers have traditionally done. I am not sure, but I believe it is important for Fortran, and it was useful for assembly programmers too before C came along. But it is not a requirement for C, and it is (IMHO) a misfeature for C because it adds nothing but makes it easier to make mistakes. >> Additionally, (again historically) linkage editors >> defer to >> the initialized storage definition if it exists. >> >> Here's where /your/ linker differs from both the historic norm, and the >> requirements of the C language. It differs from the historical norm, but not from the requirements of the C language. >> >>> But no other C compiler's linker said anything at all >> >> As would be expected. It is expected, yes - but to me it is a disappointment. I would prefer to see complaints from the linker, at least when warnings are enabled. > > I expect that they all started by working sensibly, then had to adjust > to existing practice in order to be able to compile existing C which > doesn't follow the rules. (As far as I can see, 'extern' is never really > needed because there never seem to be any consequences of not using it.) "Existing C" pre-dated the rules of C. And the rules of C don't require common sections. Fortran, which pre-dates C, /does/ have requirements for a common section. "extern" is needed if you want to write correct code that works regardless of the details of the compiler and/or linker, or when people use options such as gcc's "-fno-common" to disable common sections (to aid spotting errors and to generate more efficient code). > > Instead of non-static module variables in a C module, being in either > Initialised or Uninitialised sections (.data or .bss), C makes use of a > third category: Undefined [I think called .comm in gcc/asm files]. It is not "undefined" - it is "common". (Note that the names of the sections are implementation specific, and not part of the C standards. What you give here, however, are common choices for the basic names.) Static variables also go in .data or .bss (or something like .rodata or .const for const data) - they just don't have globally visible names. > > This just sounds like more sloppiness in the language. It is not "sloppiness" - it is a design choice. I don't agree that it is a /good/ choice, but it is a choice. > This is how it > can be done according to the rules: > > ======= Unexported Variable ====== > > static int abc; // in body of the module > > ================================== > > ======= Exported Variable ======== > > extern int abc; // probably in header > > int abc; // in body of the module > ================================== Note that this "int abc;" is a tentative definition, and as long as no initialising definition is seen in the same compilation, it is considered (as far as the C standards are concerned) identical to "int abc = 0;". C implementations are usually different - either putting in into a .common section (boo!) or a .bss section (yeah!). The distinction between .data and .bss is for efficiency - at the start of the program runtime, the .data section is initialised by copying data from the fixed information (also containing the code and const data), while the .bss section is cleared to all zeros (usually by a fast loop). > > ======= Imported Variable ======== > > extern int abc; // probably in header > > // not declared in body > ================================== > > ======= Exported, Initialised ==== > > extern int abc; // probably in header > > int abc = 1234; // in body of the module > ================================== Yes. That is all fine, and that is the way (IMHO) it should be done. > > There is no need for tentative definitions, certainly not ones that are > still tentative at the end of the source file. There are no definitions that are still tentative at the end of the source file - they are, as far as C is concerned, treated as "= 0" initialisations. Even when compilers put them in common sections, they are not really tentative. > (Neither is there any > need for more than two declarations of a variable; it seems 1000 > declarations are fine.) I am happy with a declaration in the header, and a definition in the implementation file. It is very rare that I need to do something else there. But C is quite happy with duplicate declarations as long as they are compatible. > > And therefore there is no need for compilers and linkers to pander to > the sloppiness. Especially as the more they do so, the more every new > compiler and linker needs to do the same. > I agree with you that the "common symbol" system is a bad idea, unnecessary for C and can lead to errors. What I don't agree with is that it is a feature of linkers made to handle C or C code - this is manifestly wrong as it predates C, is needed for Fortran and is useful for assembly (at least the way some people like to write their assembly). You are also wrong in suggesting that C requires it - it does not. Some C code requires it, but the language itself does not.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-06 23:41 +0100 |
| Subject | Re: Global variables |
| Message-ID | <HwLHC.136997$Vm6.49156@fx45.am4> |
| In reply to | #130276 |
On 06/05/2018 22:09, David Brown wrote: > On 06/05/18 21:16, bartc wrote: >> Instead of non-static module variables in a C module, being in either >> Initialised or Uninitialised sections (.data or .bss), C makes use of >> a third category: Undefined [I think called .comm in gcc/asm files]. > > It is not "undefined" - it is "common". (Note that the names of the > sections are implementation specific, and not part of the C standards. > What you give here, however, are common choices for the basic names.) In the COFF-format object file I looked at, the tentative variable was shown as being in an undefined section (with section number 0 instead of a 1-based section number). -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-03 09:13 -0700 |
| Message-ID | <lnvac4d8e3.fsf@kst-u.example.com> |
| In reply to | #130074 |
Dan Purgert <dan@djph.net> writes:
> How is "import <some_module>" any different than "#include
> <some_module>"?
#include exists in C. import doesn't.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-05-03 17:29 +0000 |
| Message-ID | <slrnpemhoa.jmn.dan@xps-linux.djph.net> |
| In reply to | #130090 |
Keith Thompson wrote: > Dan Purgert <dan@djph.net> writes: >> How is "import <some_module>" any different than "#include >> <some_module>"? > > #include exists in C. import doesn't. > My question was more pointed at the apparent argument that "import thing" is somehow better than "include thing". -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web