Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #108434 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2017-04-24 23:33 +0200 |
| Last post | 2017-04-26 11:36 +0200 |
| Articles | 9 on this page of 109 — 19 participants |
Back to article view | Back to comp.lang.c
https://github.com/bartg/langs/tree/master/bccproj jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-24 23:33 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-24 23:14 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-25 00:31 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-04-25 14:46 +0000
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-25 17:05 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-26 01:32 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-26 11:32 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-26 12:09 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 14:32 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-04-28 06:23 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 14:26 +0000
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-04-28 11:04 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 18:26 +0000
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-04-28 12:59 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 20:29 +0000
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-28 17:35 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-04-28 13:21 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-28 22:35 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-01 05:16 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-01 13:47 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 05:16 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-05 18:46 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-06 12:00 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 12:01 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-06 12:15 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 14:03 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 05:53 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 14:26 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 07:10 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 15:36 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 15:43 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj David Kleinecke <dkleinecke@gmail.com> - 2017-05-08 12:06 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 11:02 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 19:46 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 12:23 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 21:08 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-08 13:26 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-05-08 13:32 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-08 13:40 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 21:33 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 13:30 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 22:00 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-05-08 22:18 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-08 18:12 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-09 07:04 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Ian Collins <ian-news@hotmail.com> - 2017-05-10 07:50 +1200
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-09 13:31 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Ian Collins <ian-news@hotmail.com> - 2017-05-10 08:58 +1200
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-09 14:25 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Philip Lantz <prl@canterey.us> - 2017-05-18 05:45 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-05-18 14:02 +0000
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-18 07:22 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-05-10 14:32 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj raltbos@xs4all.nl (Richard Bos) - 2017-05-10 10:19 +0000
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-10 09:51 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-05-10 17:37 +0000
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-10 10:53 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 12:39 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-15 07:58 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-05-15 11:54 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-15 12:25 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-05-15 15:20 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-15 15:43 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-16 04:38 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-16 12:48 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj raltbos@xs4all.nl (Richard Bos) - 2017-05-15 12:34 +0000
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-05-15 08:02 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-08 18:24 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-10 05:32 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Thiago Adams <thiago.adams@gmail.com> - 2017-05-06 12:04 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-28 09:53 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-28 19:47 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-28 11:56 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-04-28 12:21 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-28 13:07 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-28 22:23 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-28 14:03 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-04-28 14:57 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-28 15:57 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-04-28 11:49 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-26 13:31 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 15:14 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-26 15:10 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 16:36 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-26 08:49 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-26 20:44 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 21:02 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-26 22:07 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 22:56 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-27 11:16 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj Richard Heathfield <rjh@cpax.org.uk> - 2017-04-27 10:53 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-27 12:56 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-04-27 04:13 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj bartc <bc@freeuk.com> - 2017-04-27 12:27 +0100
Re: https://github.com/bartg/langs/tree/master/bccproj "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-04-27 06:05 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Ian Collins <ian-news@hotmail.com> - 2017-04-27 09:38 +1200
Re: https://github.com/bartg/langs/tree/master/bccproj David Kleinecke <dkleinecke@gmail.com> - 2017-04-26 17:40 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Geoff <geoff@invalid.invalid> - 2017-04-26 22:22 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-27 01:45 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Geoff <geoff@invalid.invalid> - 2017-04-26 21:55 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj David Brown <david.brown@hesbynett.no> - 2017-04-27 11:25 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-27 12:59 -0400
Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-27 15:03 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj scott@slp53.sl.home (Scott Lurndal) - 2017-04-27 13:27 +0000
Re: https://github.com/bartg/langs/tree/master/bccproj GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 01:29 +0200
Re: https://github.com/bartg/langs/tree/master/bccproj Philip Lantz <prl@canterey.us> - 2017-04-26 10:14 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj supercat@casperkitty.com - 2017-04-26 12:25 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj Keith Thompson <kst-u@mib.org> - 2017-04-24 15:26 -0700
Re: https://github.com/bartg/langs/tree/master/bccproj jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-26 11:36 +0200
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-27 11:25 +0200 |
| Message-ID | <odsd8p$i2m$1@dont-email.me> |
| In reply to | #108576 |
On 27/04/17 06:55, Geoff wrote: > On Tue, 25 Apr 2017 17:05:02 +0100, bartc <bc@freeuk.com> wrote: > >> In this case it's because the translator from a source language (not C) >> to C has to be aware of C's rather bizarre restriction that the prefix >> 'str-' is reserved and can't be used for user identifiers. (So 'weak' is >> OK, but not 'strong'; presumably not even 'string' is legal.) > > This is not true. Standard C doesn't reserve 'str-' as you describe > but when creating 'str-' functions in your implementation it does put > the responsibility on you to avoid name collisions. From §7.1.3, "Each macro name in any of the following subclauses (including the future library directions) is reserved for use as specified if any of its associated headers is included, unless explicitly stated otherwise". Thus "str-" identifiers /are/ reserved, /if/ you use the <stdlib.h> or <string.h> headers in your code. If you avoid these headers, you can use str- identifiers as you like. However, you /may/ have to use compiler flags to avoid compiler builtins or other optimisations for existing str- library functions, should you decide to write your own "strcat" or "strlen" functions with slightly different semantics from the standard functions. And I don't know what rules apply if you include <string.h> in one translation unit, and in another unit you don't use the include file but define your own strfoo() function with external linkage. > This means > researching the topic thoroughly to be sure you're not going to create > conflicts. (The perceived reservation is due to the extensive use by > the standard library of 'str-' functions so the namespace is > relatively crowded unless you like names like strmodality() for your > library extensions.) > > The lazy way out is to use the name space reserved for the > implementation and use the leading underscore for the purpose it was > intended. Most implementations conforming to the current standard are > using _strsomething for functions that extend the string function > library. >
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-04-27 12:59 -0400 |
| Message-ID | <00027c75-0014-a67c-2d2e-b1e6c098d11b@verizon.net> |
| In reply to | #108584 |
On 04/27/2017 05:25 AM, David Brown wrote: > On 27/04/17 06:55, Geoff wrote: >> On Tue, 25 Apr 2017 17:05:02 +0100, bartc <bc@freeuk.com> wrote: >> >>> In this case it's because the translator from a source language (not C) >>> to C has to be aware of C's rather bizarre restriction that the prefix >>> 'str-' is reserved and can't be used for user identifiers. (So 'weak' is Note that this "bizarre" restriction is intended to allow future versions of the standard to add functions with those names, and for implementors of the C standard library to add such functions even before they've been standardized. In general, if anything unexpected happens due to your use of such an identifier, it will happen because the identifier you are using is already in use by the C library for some other, conflicting purpose. I'm not sure why BartC considers that so bizarre. >>> OK, but not 'strong'; presumably not even 'string' is legal.) Correct - they both fit the pattern of "str" followed by a lowercase letter, as described below. >> This is not true. Standard C doesn't reserve 'str-' as you describe >> but when creating 'str-' functions in your implementation it does put >> the responsibility on you to avoid name collisions. > > From §7.1.3, "Each macro name in any of the following subclauses > (including the future library directions) is reserved for use as > specified if any of its associated headers is included, unless > explicitly stated otherwise". The relevant parts of "Future library Directions" are 7.31.12: "Function names that begin with str and a lowercase letter may be added to the declarations in the <stdlib.h> header." and 7.31.13: "Function names that begin with str, mem, or wcs and a lowercase letter may be added to the declarations in the <string.h> header." Since those are function names, which might have external linkage, and not macros, the relevant clause is actually the one immediately after the one you cited above: "All identifiers with external linkage in any of the following subclauses (including the future library directions) and errno are always reserved for use as identifiers with external linkage." (7.1.3p1) Note that those identifiers are "always reserved", and not just when you #include the relevant header. Of course, "Any function declared in a header may be additionally implemented as a function-like macro defined in the header," (7.1.4p1), so what you said about macros does apply if you #include the relevant header.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-04-27 15:03 +0200 |
| Message-ID | <20170427150323.f554ab28ec063316a88ebfc2@gmail.com> |
| In reply to | #108576 |
On Wed, 26 Apr 2017 21:55:32 -0700 Geoff <geoff@invalid.invalid> wrote: > The lazy way out is to use the name space reserved for the > implementation and use the leading underscore for the purpose it was > intended. Most implementations conforming to the current standard are > using _strsomething for functions that extend the string function > library. Most C library implementations use the leading underscore only because the name space is reserved for the C library implementation. Avoiding name collision from several C library implementation may be a harder task than googling the specific name with the leading underscore. As a result, any C programmer should avoid the leading underscore if not for implementing the C standard library. For any private use, I would recommend to add a specific prefix bound to the project such as myproject_ which the C standard (K&R) allow at least 31 significant leading characters to define the full name.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-27 13:27 +0000 |
| Message-ID | <8lmMA.30797$sn6.8359@fx44.iad> |
| In reply to | #108598 |
GOTHIER Nathan <nathan.gothier@gmail.com> writes: >On Wed, 26 Apr 2017 21:55:32 -0700 >Geoff <geoff@invalid.invalid> wrote: > >> The lazy way out is to use the name space reserved for the >> implementation and use the leading underscore for the purpose it was >> intended. Most implementations conforming to the current standard are >> using _strsomething for functions that extend the string function >> library. > >Most C library implementations use the leading underscore only because the name >space is reserved for the C library implementation. Avoiding name collision >from several C library implementation may be a harder task than googling the >specific name with the leading underscore. You're conflating applications with the implementation. Bart is creating a new implementation of C, so he is allowed to use the leading underscore in his implementation. > >As a result, any C programmer should avoid the leading underscore if not for >implementing the C standard library. Which is exactly what Bart is doing.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-04-26 01:29 +0200 |
| Message-ID | <20170426012942.e3df2ee90abff46ce3becb32@gmail.com> |
| In reply to | #108476 |
On Tue, 25 Apr 2017 14:46:05 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > If you're adding functions to the implementation that aren't defined > by one of the relevent standards, should you not be prepending at least > one underscore to the name? Otherwise, you'll likely break existing > programs (as per above). Reserved names doesn't mean you should waste an entire name space for the need of an unrealized future. Since the C standard provides a list of reserved names, it means the implementor or the programmer shouldn't define function names which could make conflicts against the C standard. Actually I think the C standard is wrong in reserving name spaces such as str*, mem*, ... because it prevents the implementor or the programmer to use relevant names and consequently extending the de-facto standard with consistency.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2017-04-26 10:14 -0700 |
| Message-ID | <MPG.336a7555821ad047137@news.eternal-september.org> |
| In reply to | #108476 |
Scott Lurndal wrote: > bartc writes: > > jacobnavia wrote: > >> Hi Bart > >> > >> Got your compiler, looks impressive. Tried to compile it and got a > >> problem with > >> > >> bartcc.c:1236:15: error: conflicting types for 'strmode' > >> char * strmode (int32,int32); > >> ^ > >> /usr/include/string.h:164:7: note: previous declaration is here > >> void strmode(int, char *); > >> > >> What is that strmode? > >> > >> I did not know that function. > > > >OK, strmode() is one of my functions (convert a type, or 'mode', into > >string). Presumably it clashes with a C library function called > >'strmode' (although I didn't see the problem with Windows compilers, nor > >gcc on Linux). > > If you're adding functions to the implementation that aren't defined > by one of the relevent standards, should you not be prepending at least > one underscore to the name? Otherwise, you'll likely break existing > programs (as per above). The name strmode is reserved to the implementation, so the implementation is free to add a function with that name. It is the program's use of the name that causes the conflict. Since the C source wasn't written by a programmer, but was generated by a compiler, it is the compiler's responsibility to avoid such conflicts. The compiler that is generating C code as output should add a prefix to all names in its C output to avoid problems like this. (Note that a simple '_' prefix won't do, because if a symbol in the original source already starts with '_' or a capital letter, then that would change it into a reserved name.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-26 12:25 -0700 |
| Message-ID | <4b91c417-ea9c-468b-837d-c1f7c729e18e@googlegroups.com> |
| In reply to | #108546 |
On Wednesday, April 26, 2017 at 12:14:44 PM UTC-5, Philip Lantz wrote:
> Since the C source wasn't written by a programmer, but was generated by a
> compiler, it is the compiler's responsibility to avoid such conflicts. The
> compiler that is generating C code as output should add a prefix to all names
> in its C output to avoid problems like this. (Note that a simple '_' prefix
> won't do, because if a symbol in the original source already starts with '_'
> or a capital letter, then that would change it into a reserved name.)
There are two approaches a compiler can take:
1. Adjust any name which would match an implementation-reserved form, and
then require some special syntax in cases where user code knows of an
implementation-provided symbol that has a reserved name, and wishes to
use the meaning attached by the implementation.
2. Use whatever names programmers provide, but indicate that use of some
names may cause difficulties.
Note that the Standard was written at a time when implementers could be
relied upon to use common sense. While an implementation might be allowed
to break any code that uses "stretch" as an identifier (since it starts
with "str"), I think the expectation was that implementations would avoid
breaking code needlessly whether the Standard required it or not. Since
existing implementations' libraries already defined some str* functions,
forbidding libraries from including functions with those names would have
broken a lot of existing code. That does not imply, however, that functions
which are added in future shouldn't be defined in a new header, and use a
pattern like:
#define strnewthing __strnewthing
so that only code which includes the header would have to worry about a
naming conflict. Existing code, which would have had no reason to include
a header that didn't exist when it was written, would have been able to
use the name without difficulty.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-24 15:26 -0700 |
| Message-ID | <lnpog1o32f.fsf@kst-u.example.com> |
| In reply to | #108434 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Got your compiler, looks impressive. Tried to compile it and got a
> problem with
>
> bartcc.c:1236:15: error: conflicting types for 'strmode'
> char * strmode (int32,int32);
> ^
> /usr/include/string.h:164:7: note: previous declaration is here
> void strmode(int, char *);
>
> What is that strmode?
>
> I did not know that function.
It's an implementation-defined function from BSD. The man page on my
system says:
#include <bsd/string.h>
void
strmode(mode_t mode, char *bp);
https://www.freebsd.org/cgi/man.cgi?query=strmode&sektion=3&apropos=0&manpath=freebsd
Of course names starting with "str" are reserved, so this kind of
problem is probably to be expected -- but you might try compiling with
"-std=c11 -pedantic" or something similar. (I'm assuming gcc because
your error message looks gcc-ish.)
--
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 | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-04-26 11:36 +0200 |
| Message-ID | <odppgc$it1$1@dont-email.me> |
| In reply to | #108434 |
Le 24/04/2017 à 23:33, jacobnavia a écrit : > Hi Bart > > Got your compiler, looks impressive. Tried to compile it and got a > problem with > > bartcc.c:1236:15: error: conflicting types for 'strmode' > char * strmode (int32,int32); > ^ > /usr/include/string.h:164:7: note: previous declaration is here > void strmode(int, char *); > > What is that strmode? > > I did not know that function. I compiled successfully the software of bart with just a change from strmode to Strmode.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web