Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #110007 > unrolled thread
| Started by | bartc <bc@freeuk.com> |
|---|---|
| First post | 2017-05-15 11:46 +0100 |
| Last post | 2017-05-15 09:47 -0700 |
| Articles | 20 on this page of 126 — 27 participants |
Back to article view | Back to comp.lang.c
C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-15 11:46 +0100
Re: C Macros Badly Defined? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-15 12:32 +0100
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 06:48 -0700
Re: C Macros Badly Defined? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-15 15:18 +0100
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 11:22 -0700
Re: C Macros Badly Defined? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-15 20:40 +0100
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-16 01:58 -0700
Re: C Macros Badly Defined? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-16 13:49 +0100
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-19 21:47 -0700
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-15 14:52 +0100
Re: C Macros Badly Defined? Thiago Adams <thiago.adams@gmail.com> - 2017-05-15 07:11 -0700
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-15 15:29 +0100
Re: C Macros Badly Defined? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-15 16:41 +0100
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-15 08:53 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-24 08:16 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-24 10:43 -0700
Re: C Macros Badly Defined? Ike Naar <ike@iceland.freeshell.org> - 2017-05-24 19:06 +0000
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-27 06:10 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-27 12:02 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-27 13:42 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-27 15:48 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-28 14:40 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-29 08:33 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-29 08:17 -0700
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-29 16:26 +0100
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-30 06:13 -0700
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-30 09:57 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 19:12 +0200
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-30 14:55 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-30 15:39 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-30 16:03 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-30 16:50 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-30 17:12 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-31 06:30 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 09:36 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 12:08 -0700
Re: C Macros Badly Defined? scott@slp53.sl.home (Scott Lurndal) - 2017-05-31 19:16 +0000
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 12:35 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 04:06 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 10:33 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-01 12:00 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 15:35 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-01 17:26 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 20:48 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 12:43 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 21:50 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:36 +0000
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-03 11:44 +0000
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-03 09:19 -0700
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-03 16:22 +0000
Re: Standards in various formats Noob <root@127.0.0.1> - 2017-06-01 13:24 +0200
Re: C Macros Badly Defined? jadill33@gmail.com - 2017-05-31 13:02 -0700
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-30 22:06 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-05-31 12:51 +0200
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-31 06:21 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-05-31 17:16 +0200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 17:24 +0200
Re: C Macros Badly Defined? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-31 22:18 +0200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 23:09 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 17:32 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 23:50 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 18:01 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 00:33 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 22:36 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 06:08 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-01 11:08 -0400
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 01:30 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 11:38 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 03:13 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 12:25 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 04:48 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 14:27 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 05:55 -0700
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-01 11:11 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 17:40 +0200
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 08:32 +1200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 23:14 +0200
Re: C Macros Badly Defined? jameskuyper@verizon.net - 2017-06-01 14:41 -0700
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 09:48 +1200
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-02 00:56 +0200
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 11:12 +1200
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:54 +0000
Re: C Macros Badly Defined? Leon Taylor <leontaylor476@gmail.com> - 2017-06-03 05:10 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-04 14:32 +0200
Re: C Macros Badly Defined? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-01 21:44 +0000
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:51 +0000
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-01 21:38 +0000
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 11:10 +1200
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-01 23:34 +0000
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:48 +0000
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-06-01 08:56 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-02 14:11 +0200
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-06-02 10:02 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:45 +0000
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 09:11 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:29 +0000
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-15 18:31 +0100
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-15 11:56 -0700
Re: C Macros Badly Defined? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-15 19:57 +0100
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-15 20:31 +0100
Re: C Macros Badly Defined? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-15 22:08 +0100
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-15 23:50 +0100
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-15 16:13 -0700
Re: C Macros Badly Defined? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-16 01:36 +0100
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-16 10:15 +0100
Re: C Macros Badly Defined? Philip Lantz <prl@canterey.us> - 2017-05-16 19:17 -0700
Re: C Macros Badly Defined? Philip Lantz <prl@canterey.us> - 2017-05-16 19:12 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-17 08:48 -0700
Re: C Macros Badly Defined? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-17 11:19 -0500
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-17 10:22 -0700
Re: C Macros Badly Defined? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-05-18 04:17 +0200
Re: C Macros Badly Defined? Philip Lantz <prl@canterey.us> - 2017-05-18 18:40 -0700
Re: C Macros Badly Defined? Philip Lantz <prl@canterey.us> - 2017-05-18 18:36 -0700
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-16 10:57 +0100
Re: C Macros Badly Defined? Thiago Adams <thiago.adams@gmail.com> - 2017-05-16 07:02 -0700
Re: C Macros Badly Defined? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-16 16:26 +0100
Re: C Macros Badly Defined? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-05-18 03:27 +0200
Re: C Macros Badly Defined? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-18 03:25 +0100
Re: C Macros Badly Defined? James Kuyper <jameskuyper@verizon.net> - 2017-05-17 22:35 -0400
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-19 18:38 -0700
Re: C Macros Badly Defined? Thiago Adams <thiago.adams@gmail.com> - 2017-05-15 06:00 -0700
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-15 15:05 +0100
Re: C Macros Badly Defined? Thiago Adams <thiago.adams@gmail.com> - 2017-05-24 09:44 -0700
Re: C Macros Badly Defined? Thiago Adams <thiago.adams@gmail.com> - 2017-05-26 17:26 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 06:43 -0700
Re: C Macros Badly Defined? fir <profesor.fir@gmail.com> - 2017-05-15 09:47 -0700
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-15 22:08 +0100 |
| Message-ID | <877f1h7rpy.fsf@bsb.me.uk> |
| In reply to | #110071 |
bartc <bc@freeuk.com> writes: > On 15/05/2017 19:57, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> then I get yet another assorted bunch of results. More bugs >>> presumably. >> >> I doubt there will be any fewer that's almost certain. But with no idea >> what flags you are using, none of these may be bugs. > > I just don't think that flags have much to do with it. Except for > perhaps for gcc (and clang which uses the same flags), where > apparently they can be used to make gcc do anything. I really don't know why you can't just tell us. Your remark about it not mattering suggest that you are using no flags at all (save for -E) for any of compilers you listed. Is that correct? > And if they do, then they shouldn't. Nonsense. It would be entirely reasonable for a compiler to support some legacy behaviour in either its default mode or with some special flags. <snip> >> No, you are not allowed pp directives in the middle of a macro call[1] >> but I don't see the connection with #12. #12 relies on the fact the the >> replacement list is scanned alone with the remaining tokens: >> >> #define A(x,y) if(x==y) >> #define B A( >> >> so "B 1,2)" expands to "A(| 1,2)" (using | to mark where the replacement >> list ends). This replacement list is scanned along with the remaining >> tokens, so a valid call of A is seen. >> >> [1] 6.10.3 p11: >> >> "The sequence of preprocessing tokens bounded by the outside-most >> matching parentheses forms the list of arguments for the function-like >> macro. The individual arguments within the list are separated by comma >> preprocessing tokens, but comma preprocessing tokens between matching >> inner parentheses do not separate arguments. If there are sequences of >> preprocessing tokens within the list of arguments that would otherwise >> act as preprocessing directives, the behavior is undefined." >> > > If it's so perfectly clear, why do so many compilers have trouble? That's rhetoric. Instead, can you say what you think is unclear about #define A(x,y) if(x==y) #define B A( B 10,20) ? It's entirely possible that the erroneous results you report are not due to misunderstanding but are the consequences of incorrect fixes elsewhere. Or they may simply be due to incorrect implementation (i.e. despite understanding the words in the standard). But I found lccwin64 and PellesC (8.0) get example 12 right. Using no flags and Pelles Compiler Driver, Version 8.00.0 Copyright (c) Pelle Orinius 2002-2015 Logiciels/Informatique lcc-win (64 bits) version 4.1. Compilation date: Oct 27 2016 16:34:50 but even a very old version of lccwin32 gets 12 right. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-15 23:50 +0100 |
| Message-ID | <QgqSA.37019$m94.16146@fx33.am4> |
| In reply to | #110083 |
On 15/05/2017 22:08, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > I really don't know why you can't just tell us. Your remark about it > not mattering suggest that you are using no flags at all (save for -E) Actually, I did use -E or equivalent to get the output, and nothing else. Would source be preprocessed differently when it was actually compiled? I was anyway /only/ looking at preprocessing. >> If it's so perfectly clear, why do so many compilers have trouble? > > That's rhetoric. Instead, can you say what you think is unclear about > > #define A(x,y) if(x==y) > #define B A( > B 10,20) Why do you think I thought up the example? I wanted one where a macro call was synthesised from elements at different levels of macro expansion including level zero (direct from original source). Just to see what would happen. > ? It's entirely possible that the erroneous results you report are not > due to misunderstanding but are the consequences of incorrect fixes > elsewhere. Or they may simply be due to incorrect implementation > (i.e. despite understanding the words in the standard). > > But I found lccwin64 and PellesC (8.0) get example 12 right. > > Using no flags and > > Pelles Compiler Driver, Version 8.00.0 > Copyright (c) Pelle Orinius 2002-2015 > > Logiciels/Informatique lcc-win (64 bits) version 4.1. > Compilation date: Oct 27 2016 16:34:50 > > but even a very old version of lccwin32 gets 12 right. I've tried PellesC and lccwin again, and results are variable. In the original code, the macros for #11 and #12 were positioned just before each invocation. Also, part of #11 was commented out which I hadn't realised (I redid all tests for an uncommented #11, but only looked at and updated the #11 results). Anyway, the upshot is that processing: #define F(a) a*G #define G(a) F(a) 11: F(2)//(9) #define A(x,y) if(x==y) #define B A( 12: B 10,20); with Pelles C 64-bit 8.0.170 gives this -E output (some blanks and #lines removed): 11: 2 *G #define A(x,y) if(x==y) 12: A( 10,20); But this input: #define F(a) a*G #define G(a) F(a) 11: F(2)(9) #define A(x,y) if(x==y) #define B A( 12: B 10,20); produces: 11: 2 * F(9) 12: if(10 == 20); So something funny is going on, judging from that #define being sent to the output. I've observed something similar with lccwin64. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-15 16:13 -0700 |
| Message-ID | <ln37c54st2.fsf@kst-u.example.com> |
| In reply to | #110099 |
bartc <bc@freeuk.com> writes:
> On 15/05/2017 22:08, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>> I really don't know why you can't just tell us. Your remark about it
>> not mattering suggest that you are using no flags at all (save for -E)
>
> Actually, I did use -E or equivalent to get the output, and nothing
> else. Would source be preprocessed differently when it was actually
> compiled? I was anyway /only/ looking at preprocessing.
gcc does not fully conform to any edition of the C standard by
default. I don't know how or whether the various "-std=..." options
affect the behavior of the preprocessor, but I would suggest using
"-std=c11 -pedantic-errors -E" if you're looking at the behavior
of the preprocessor in the context of the current C standard.
(But even that can be less than entirely useful for code whose
behavior is undefined.)
[...]
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-16 01:36 +0100 |
| Message-ID | <87mvad63j9.fsf@bsb.me.uk> |
| In reply to | #110099 |
bartc <bc@freeuk.com> writes:
> On 15/05/2017 22:08, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>> I really don't know why you can't just tell us. Your remark about it
>> not mattering suggest that you are using no flags at all (save for -E)
>
> Actually, I did use -E or equivalent to get the output, and nothing
> else.
Finally.
> Would source be preprocessed differently when it was actually
> compiled? I was anyway /only/ looking at preprocessing.
Eh? I just want to know what flags you used. It's really not that odd
to ask when you posted compiler results.
>>> If it's so perfectly clear, why do so many compilers have trouble?
>>
>> That's rhetoric. Instead, can you say what you think is unclear about
>>
>> #define A(x,y) if(x==y)
>> #define B A(
>> B 10,20)
>
> Why do you think I thought up the example? I wanted one where a macro
> call was synthesised from elements at different levels of macro
> expansion including level zero (direct from original source). Just to
> see what would happen.
But what is unclear about it? Presumably you've read what the language
standard says about macro expansion. It's not many paragraphs. Did I
get it right in my explanation? Do you see a murky area where the words
could mean something else? I want to talk technical. You just seem to
want to bang the "ooh, it's all so complicated" drum.
>> ? It's entirely possible that the erroneous results you report are not
>> due to misunderstanding but are the consequences of incorrect fixes
>> elsewhere. Or they may simply be due to incorrect implementation
>> (i.e. despite understanding the words in the standard).
>>
>> But I found lccwin64 and PellesC (8.0) get example 12 right.
>>
>> Using no flags and
>>
>> Pelles Compiler Driver, Version 8.00.0
>> Copyright (c) Pelle Orinius 2002-2015
>>
>> Logiciels/Informatique lcc-win (64 bits) version 4.1.
>> Compilation date: Oct 27 2016 16:34:50
>>
>> but even a very old version of lccwin32 gets 12 right.
>
> I've tried PellesC and lccwin again, and results are variable. In the
> original code, the macros for #11 and #12 were positioned just before
> each invocation. Also, part of #11 was commented out which I hadn't
> realised (I redid all tests for an uncommented #11, but only looked at
> and updated the #11 results).
Always post the code that gives the results you are reporting, please!
<snip cases>
> So something funny is going on, judging from that #define being sent
> to the output.
It's just a bug. Here a small test case if you want to report it.
#define F()
F
#define X
X
There is obviously a bug in the code that looks ahead for '(' after
seeing a function-like macro name. The following #define is not
processed as a directive but it does persuade the scanner that no '(' is
coming.
> I've observed something similar with lccwin64.
Yes, lccwin64 gives the same results when given an input that actually
trips it up. Both PellesC and lccwin64 are based on Dave Hanson's lcc,
so I would bet the bug dates back to lcc's preprocessor. Both have been
extensively developed so they have obviously diverged from the original
lcc, but the coincidence suggests a common cause.
(Quick search... Source of lcc's cpp is available and, yes, it
generated the same faulty output.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-16 10:15 +0100 |
| Message-ID | <%qzSA.13429$lN5.9676@fx40.am4> |
| In reply to | #110113 |
On 16/05/2017 01:36, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>> Would source be preprocessed differently when it was actually
>> compiled? I was anyway /only/ looking at preprocessing.
>
> Eh? I just want to know what flags you used. It's really not that odd
> to ask when you posted compiler results.
You know I avoid using compiler flags except for ones such as -E, -c or -O3.
> But what is unclear about it? Presumably you've read what the language
> standard says about macro expansion. It's not many paragraphs. Did I
> get it right in my explanation? Do you see a murky area where the words
> could mean something else? I want to talk technical. You just seem to
> want to bang the "ooh, it's all so complicated" drum.
It's not just me that thinks it's complicated. In the original #12
macro, 5 compilers out of 6 got it wrong. Now it turns out two of those
results were erroneous. But that still leaves half getting it wrong
(with those two turning out to have an unrelated bug).
I think (this is going back several months) I tried such an example to
see how much effort I should put into getting it right. So if the mighty
MSVC got it wrong (even with the 2008 version, but 2008 is still
comparatively recent), then I probably didn't need to bother (as there
were plenty of more pressing matters to get on with).
What it would mean in practice is that if it turns out I can't compile a
particular source, then neither can MSVC.
In the long term, that might even lead to people avoiding using those
dodgier macros. Whereas if all compilers accepted them, then the bar
would be raised even higher.
> There is obviously a bug in the code that looks ahead for '(' after
> seeing a function-like macro name.
I don't have that bug because I deliberately limit the possibilities, so
that a macro call must look like one of these two:
M(A)
M (A)
That means there will be a set of source codes that my preprocessor will
fail on because they will do one of these, or worse:
M (A)
M
(A)
M /*comment*/ (A)
etc. But I don't care. If the C standard had such a restriction (and in
some places single spaces /are/ significant), then that bug in LCC
wouldn't have existed.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2017-05-16 19:17 -0700 |
| Message-ID | <MPG.338552a46401d91613e@news.eternal-september.org> |
| In reply to | #110123 |
bartc wrote: > Ben Bacarisse wrote: > > bartc writes: > > >> Would source be preprocessed differently when it was actually > >> compiled? I was anyway /only/ looking at preprocessing. > > > > Eh? I just want to know what flags you used. It's really not that odd > > to ask when you posted compiler results. > > You know I avoid using compiler flags except for ones such as -E, -c or -O3. If you're going to use gcc to help you determine what the standard requires, I strongly suggest that you use a flag that tells it to compile some standard flavor of C, rather than its own privately-defined C-like language.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2017-05-16 19:12 -0700 |
| Message-ID | <MPG.33855173c811a96a13d@news.eternal-september.org> |
| In reply to | #110099 |
bartc wrote: > Ben Bacarisse wrote: > > > I really don't know why you can't just tell us. Your remark about it > > not mattering suggest that you are using no flags at all (save for -E) > > Actually, I did use -E or equivalent to get the output, and nothing > else. Would source be preprocessed differently when it was actually > compiled? I was anyway /only/ looking at preprocessing. You seem to have completely missed his point. A compiler may treat its input as C11, C99, C89, K&R, or some private C-like language, depending on the flags.* Do you expect the preprocessor rules to be identical for all these possibilities? (I don't know whether they are or not, but I certainly wouldn't expect them to be without checking.) * And of course gcc might treat it as Fortran, but I think we can ignore that for our current purposes.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-17 08:48 -0700 |
| Message-ID | <f3a68706-d91e-4262-86b8-f7927fc94a23@googlegroups.com> |
| In reply to | #110194 |
On Tuesday, May 16, 2017 at 9:12:48 PM UTC-5, Philip Lantz wrote: > * And of course gcc might treat it as Fortran, but I think we can ignore > that for our current purposes. If there exists a conforming C compiler that would interpret a file that began with __FORTRAN as a FORTRAN-77 program (allowable behavior given the presence of an implementation-reserved identifier) then if such a file would be processed as a usable FORTRAN program it would also be a "conforming C program" because there would be at least one conforming C implementation which could process it.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-17 11:19 -0500 |
| Message-ID | <uftohc5vbh61a4lshndtka08sb481kv0fl@4ax.com> |
| In reply to | #110210 |
On Wed, 17 May 2017 08:48:12 -0700 (PDT), supercat@casperkitty.com wrote: >On Tuesday, May 16, 2017 at 9:12:48 PM UTC-5, Philip Lantz wrote: >> * And of course gcc might treat it as Fortran, but I think we can ignore >> that for our current purposes. > >If there exists a conforming C compiler that would interpret a file that >began with __FORTRAN as a FORTRAN-77 program (allowable behavior given >the presence of an implementation-reserved identifier) then if such a >file would be processed as a usable FORTRAN program it would also be a >"conforming C program" because there would be at least one conforming C >implementation which could process it. Piffle! There's no need for an ugly language declaration like that, it's perfectly possible to write programs that can be compiled as C or Fortran, or even run as a shell script. http://www.ioccc.org/1986/applin/applin.c As to whether or not such an ability reflects the original intention of C (later ruined by the ANSI committee), I'll leave for others to debate. ;-)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-17 10:22 -0700 |
| Message-ID | <1cb863d0-4550-4af7-95fc-b5829a236556@googlegroups.com> |
| In reply to | #110213 |
On Wednesday, May 17, 2017 at 11:20:06 AM UTC-5, robert...@yahoo.com wrote: > On Wed, 17 May 2017 08:48:12 -0700 (PDT), supercat wrote: > >If there exists a conforming C compiler that would interpret a file that > >began with __FORTRAN as a FORTRAN-77 program (allowable behavior given > >the presence of an implementation-reserved identifier) then if such a > >file would be processed as a usable FORTRAN program it would also be a > >"conforming C program" because there would be at least one conforming C > >implementation which could process it. > > Piffle! There's no need for an ugly language declaration like that, > it's perfectly possible to write programs that can be compiled as C or > Fortran, or even run as a shell script. > > http://www.ioccc.org/1986/applin/applin.c My point was that the appearance of an identifier starting with __ would give a C compiler latitude to treat everything else in arbitrary fashion, so the only requirement for such a file to be conforming would be the existence of a conforming compiler that would process it usefully. The example might have been improved, however, by having the magic line be const __FORTRAN=77; which would then allow the program to be a valid FORTRAN file as well as a valid C file, at least if a lowercase "C" is a valid comment indicator (the system on which I programmed FORTRAN didn't *have* lowercase letters, so I don't know).
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2017-05-18 04:17 +0200 |
| Message-ID | <eo4eimFm4akU1@mid.individual.net> |
| In reply to | #110210 |
Am 17.05.2017 um 17:48 schrieb supercat@casperkitty.com: > On Tuesday, May 16, 2017 at 9:12:48 PM UTC-5, Philip Lantz wrote: >> * And of course gcc might treat it as Fortran, but I think we can ignore >> that for our current purposes. > > If there exists a conforming C compiler that would interpret a file that > began with __FORTRAN as a FORTRAN-77 program (allowable behavior given > the presence of an implementation-reserved identifier) then if such a > file would be processed as a usable FORTRAN program it would also be a > "conforming C program" because there would be at least one conforming C > implementation which could process it. IMO it's a matter of the compiler front-ends, which languages are accepted. But in most cases distinct compilers for different languages are built, even if these use the gcc infrastructure and code generation back-ends. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2017-05-18 18:40 -0700 |
| Message-ID | <MPG.3387ed02ff3e6591ea@news.eternal-september.org> |
| In reply to | #110251 |
Hans-Peter Diettrich wrote: > Am 17.05.2017 um 17:48 schrieb supercat@casperkitty.com: > > Philip Lantz wrote: > >> * And of course gcc might treat it as Fortran, but I think we can ignore > >> that for our current purposes. > > > > If there exists a conforming C compiler that would interpret a file that > > began with __FORTRAN as a FORTRAN-77 program (allowable behavior given > > the presence of an implementation-reserved identifier) then if such a > > file would be processed as a usable FORTRAN program it would also be a > > "conforming C program" because there would be at least one conforming C > > implementation which could process it. > > IMO it's a matter of the compiler front-ends, which languages are > accepted. But in most cases distinct compilers for different languages > are built, even if these use the gcc infrastructure and code generation > back-ends. Regardless of that, if you don't know what options the compiler was invoked with, you have /no/ idea what it is going to do, and you can't draw any conclusions from what messages it prints.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2017-05-18 18:36 -0700 |
| Message-ID | <MPG.3387ec17e8858cabe9@news.eternal-september.org> |
| In reply to | #110210 |
supercat@casperkitty.com wrote:
> Philip Lantz wrote:
> > * And of course gcc might treat it as Fortran, but I think we can ignore
> > that for our current purposes.
>
> If there exists a conforming C compiler that would interpret a file that
> began with __FORTRAN as a FORTRAN-77 program (allowable behavior given
> the presence of an implementation-reserved identifier) then if such a
> file would be processed as a usable FORTRAN program it would also be a
> "conforming C program" because there would be at least one conforming C
> implementation which could process it.
You completely missed my point. I wasn't talking about any of that. Bart
thinks that command line options don't matter. Consider this, which shows
that command line options matter quite a bit:
$ cat > f.c
C This is Fortran
print *,"This is Fortran."
end
$ gcc -x f77 -c f.c
$ cat c.f
/* this is C */
main() { printf("this is C\n"); }
$ gcc -x c -c c.f
c.f: In function 'main':
c.f:2:10: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default]
main() { printf("this is C\n"); }
^
$ gcc c.f
c.f:1.1:
/* this is C */
1
Error: Non-numeric character in statement label at (1)
c.f:1.2:
/* this is C */
1
Error: Invalid character in name at (1)
c.f:2.1:
main() { printf("this is C\n"); }
1
Error: Non-numeric character in statement label at (1)
c.f:2.1:
main() { printf("this is C\n"); }
1
Error: Unclassifiable statement at (1)
c.f:2.33:
main() { printf("this is C\n"); }
1
Error: Invalid character in name at (1)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-16 10:57 +0100 |
| Message-ID | <k2ASA.3868$lG2.309@fx11.am4> |
| In reply to | #110068 |
On 15/05/2017 19:57, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>> The majority verdict on #5 is that it should be 'a d (x)'. So my code
>> should really be changed (I thought I'd fixed 1-11 actually).
>
> #5 is just "f" with these defines:
>
> #define a(x) mac_a(x)
> #define d(x) (x)
> #define f a d d (x)
>
> So, as far I can see, this is what happens. I'll write <x> for the
> token x and <_> for the space token (I don't think newline tokens
> feature here).
>
> <f> is replaced by <a><_><d><_><d><_><(><x><)>. This replacement is
> scanned for macros to expand along with any tokens the follow <f> (but
> lets say there are none).
>
> <a> not followed by <_>*<(> has no expansion so I believe we can now
> output the first tokens (i.e. no repeated scanning happens)
>
> result: <a><_>
>
> <d> (again not followed by <_>*<(>) expands to nothing:
>
> result: <a><_><d><_>
>
> <d><_><(> is a function-like macro invocation, so we must collect the
> arguments. This involves scanning (with no expansion) for a matching
> <)> treating <,> at the outer level as a separator. That's easy. The
> argument list has one token list: <x>.
>
> Before substituting <x> we expand any macros, but there are none. This
> round of exansion is done in isolation as if it were a short, separate
> source file. There are no # or ## tokens in sight so we can simply
> replace <x> in the replacement list with <x> from the macro arguments.
>
> replacement list: <(><x><)>
>
> Again, this list scanned for macros to expand (including, this time, any
> tokens that might follow in the input stream but there is nothing to
> do. We now know the final result:
>
> result: <a><_><d><_><(><x><)>
Now that this first <d> is followed by <(>, why wouldn't it now be
expanded? I believe that is what MSVC must have done.
Is it because once a macro name has been processed once (and either it
has been expanded, or it couldn't be expanded because it wasn't followed
by "(") then it's no longer eligible to be expanded again?
(That is not the problem I get. I now fail to expand this #5 properly
because I added a loop. That was to get around this example:
#define info(x) (mem(x))
#define llink(x) info(x+1)
#define prevbreak llink
#define serial info
serial(prevbreak(10));
Output should be: (mem((mem(10+1))));
All compilers manage this except TCC which produces (mem(info(10+1)));
As did mine before I made the fix, but that broke example #5 (however
this one occurs in a real program so it takes priority).
The issue here is that at some point, a macro name is produced that is
not at first followed by "(", so is not expanded, but later it is.
Similar to my point about why the d(x) in "a d (x)" wasn't expanded above.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-05-16 07:02 -0700 |
| Message-ID | <93009cfc-089c-419c-94c5-65f7ef2fa9f7@googlegroups.com> |
| In reply to | #110124 |
On Tuesday, May 16, 2017 at 6:57:43 AM UTC-3, Bart wrote: > On 15/05/2017 19:57, Ben Bacarisse wrote: > > bartc writes: > > >> The majority verdict on #5 is that it should be 'a d (x)'. So my code > >> should really be changed (I thought I'd fixed 1-11 actually). It would be very nice if you publish the samples/results in your github. As a comment, Microsoft is planning to fix the preprocessor, not because of C, but because of C++. https://blogs.msdn.microsoft.com/vcblog/2017/05/10/c17-features-in-vs-2017-3/ "[C] C99 preprocessor support is still partial, in that variadic macros mostly work. We’re planning to overhaul the preprocessor before marking this as complete." C++ perspective: "This document details the changes that need to be made to the working draft to resynchronize the preprocessor and translation phases of C++ with C99 " Working draft changes for C99 preprocessor synchronization http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1653.htm
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-16 16:26 +0100 |
| Message-ID | <87fug44yc6.fsf@bsb.me.uk> |
| In reply to | #110124 |
bartc <bc@freeuk.com> writes:
> On 15/05/2017 19:57, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> The majority verdict on #5 is that it should be 'a d (x)'. So my code
>>> should really be changed (I thought I'd fixed 1-11 actually).
>>
>> #5 is just "f" with these defines:
>>
>> #define a(x) mac_a(x)
>> #define d(x) (x)
>> #define f a d d (x)
>>
>> So, as far I can see, this is what happens. I'll write <x> for the
>> token x and <_> for the space token (I don't think newline tokens
>> feature here).
>>
>> <f> is replaced by <a><_><d><_><d><_><(><x><)>. This replacement is
>> scanned for macros to expand along with any tokens the follow <f> (but
>> lets say there are none).
>>
>> <a> not followed by <_>*<(> has no expansion so I believe we can now
>> output the first tokens (i.e. no repeated scanning happens)
>>
>> result: <a><_>
>>
>> <d> (again not followed by <_>*<(>) expands to nothing:
>>
>> result: <a><_><d><_>
>>
>> <d><_><(> is a function-like macro invocation, so we must collect the
>> arguments. This involves scanning (with no expansion) for a matching
>> <)> treating <,> at the outer level as a separator. That's easy. The
>> argument list has one token list: <x>.
>>
>> Before substituting <x> we expand any macros, but there are none. This
>> round of exansion is done in isolation as if it were a short, separate
>> source file. There are no # or ## tokens in sight so we can simply
>> replace <x> in the replacement list with <x> from the macro arguments.
>>
>> replacement list: <(><x><)>
>>
>> Again, this list scanned for macros to expand (including, this time, any
>> tokens that might follow in the input stream but there is nothing to
>> do. We now know the final result:
>>
>> result: <a><_><d><_><(><x><)>
>
> Now that this first <d> is followed by <(>, why wouldn't it now be
> expanded? I believe that is what MSVC must have done.
Do you think it should be expanded in this case:
#define d(x) [x]
#define p (y)
d p
? Replacement lists are re-scanned (once, I believe) but not the
result. Once tokens have been emitted the scanning does no back-up to
see if subsequent tokens have now make a valid call.
> Is it because once a macro name has been processed once (and either it
> has been expanded, or it couldn't be expanded because it wasn't
> followed by "(") then it's no longer eligible to be expanded again?
No, that wording applies to macros that have been expanded -- they are
not recognised when scanning the replacement list. d has not been
expanded here and it does not appear in a replacement list anymore.
It's been though the algorithm and out the other end.
> (That is not the problem I get. I now fail to expand this #5 properly
> because I added a loop. That was to get around this example:
>
> #define info(x) (mem(x))
> #define llink(x) info(x+1)
> #define prevbreak llink
> #define serial info
>
> serial(prevbreak(10));
>
> Output should be: (mem((mem(10+1))));
>
> All compilers manage this except TCC which produces (mem(info(10+1)));
> As did mine before I made the fix, but that broke example #5 (however
> this one occurs in a real program so it takes priority).
This sort of "balloon animal" debugging -- where you squeeze it into
shape in one place on one place and a bug pops up somewhere else --
usually indicaes a need to step back and review the overall algorithm.
At least that's how I deal with this sort of situation.
> The issue here is that at some point, a macro name is produced that is
> not at first followed by "(", so is not expanded, but later it
> is. Similar to my point about why the d(x) in "a d (x)" wasn't
> expanded above.)
You do have to get the sequence right. I started to go through this
example but I failed to find a good notation to show the nested
expansions and I ended up thinking it was not helping. I might revisit
it if I get time.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2017-05-18 03:27 +0200 |
| Message-ID | <eo4bkcFli1qU1@mid.individual.net> |
| In reply to | #110044 |
Am 15.05.2017 um 17:41 schrieb Ben Bacarisse: > bartc <bc@freeuk.com> writes: > >> On 15/05/2017 12:32, Ben Bacarisse wrote: >>> bartc <bc@freeuk.com> writes: > <snip> >>>> Are C's preprocessor and macro expansion rules really so poorly >>>> defined that so many compilers get it wrong? >>> >>> Not, I think, in this case. It seems very clear. Do you think the >>> wording of the standard needs to be improved and, if so, how? >> >> I would prefer that the possibilities were purposely kept simple. > > Ah, that's not what I meant. I was not asking you to invent a macro > language you'd prefer, I was asking if you can suggest a way in which > the wording of (or, for that matter, any other changes to) the standard > would make the current intended semantics clearer. IMO the problem arises from translation phase 4, with the mix of macro expansion and preprocessor directive handling. If macro expansion would start only after all macro arguments are collected, at least no preprocessor directives can occur in the argument list. This convention also would produce the same result, regardless of whether a function or a functional macro is compiled. > This is a good case to consider since there is clearly some > disagreement. (There's a high probably that I'm wrong about it being > defined but it's certain that it's not as clear as I thought it was.) > > <snip> >>>> But then maybe someone will have a macro expansion that generates >>>> #-directives >>> >>> Macros can't (validly) expand to directives. Synthetic preprocessor directive construction should be disallowed/ignored, because this leads to self modifying code. This were in accordance to the tokenization, where it is impossible to construct comments from /##/, as MSVC did some time ago. >> 6: e(a,,a) AFAIK empty macro arguments are not allowed. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-18 03:25 +0100 |
| Message-ID | <87r2zmzys5.fsf@bsb.me.uk> |
| In reply to | #110249 |
Hans-Peter Diettrich <DrDiettrich1@aol.com> writes: > Am 15.05.2017 um 17:41 schrieb Ben Bacarisse: >> bartc <bc@freeuk.com> writes: >> >>> On 15/05/2017 12:32, Ben Bacarisse wrote: >>>> bartc <bc@freeuk.com> writes: > >> <snip> >>>>> Are C's preprocessor and macro expansion rules really so poorly >>>>> defined that so many compilers get it wrong? >>>> >>>> Not, I think, in this case. It seems very clear. Do you think the >>>> wording of the standard needs to be improved and, if so, how? >>> >>> I would prefer that the possibilities were purposely kept simple. >> >> Ah, that's not what I meant. I was not asking you to invent a macro >> language you'd prefer, I was asking if you can suggest a way in which >> the wording of (or, for that matter, any other changes to) the standard >> would make the current intended semantics clearer. > > IMO the problem arises from translation phase 4, with the mix of macro > expansion and preprocessor directive handling. If macro expansion > would start only after all macro arguments are collected, at least no > preprocessor directives can occur in the argument list. Macro expansion does start only after the arguments are collected. At least it can be arranged that way. Arguments are also expanded but that does not have to happen until after they are all collected. > This > convention also would produce the same result, regardless of whether a > function or a functional macro is compiled. I don't follow this, but then I think I've misunderstood what you mean above. <snip> >>> 6: e(a,,a) > > AFAIK empty macro arguments are not allowed. No, they are allowed. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-17 22:35 -0400 |
| Message-ID | <ofj13q$nl9$1@dont-email.me> |
| In reply to | #110249 |
On 05/17/2017 09:27 PM, Hans-Peter Diettrich wrote: > Am 15.05.2017 um 17:41 schrieb Ben Bacarisse: >> bartc <bc@freeuk.com> writes: ... >>> 6: e(a,,a) > > AFAIK empty macro arguments are not allowed. 6.10.3p4 mentions "arguments consisting of no preprocessing tokens", which implies that it's permissible for such arguments to exist. Section 7 of the forward mentions "empty macro arguments" as one of the features introduced in C99.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-19 18:38 -0700 |
| Message-ID | <kfny3tsjoj9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110254 |
James Kuyper <jameskuyper@verizon.net> writes: > On 05/17/2017 09:27 PM, Hans-Peter Diettrich wrote: >> Am 15.05.2017 um 17:41 schrieb Ben Bacarisse: >>> bartc <bc@freeuk.com> writes: > > ... > >>>> 6: e(a,,a) >> >> AFAIK empty macro arguments are not allowed. > > 6.10.3p4 mentions "arguments consisting of no preprocessing tokens", > which implies that its permissible for such arguments to exist. Section > 7 of the forward mentions "empty macro arguments" as one of the features > introduced in C99. If you will excuse a micro-quibble... They are mentioned as one of the /changes/ in C99. Empty macro arguments were actually introduced in the original standard, in section G.5.12 of C90 (and IIANM under a different numbering in C89), as a "Common Extension".
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web