Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100318 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-12-27 14:08 +0000 |
| Last post | 2016-12-27 11:42 -0600 |
| Articles | 20 on this page of 202 — 18 participants |
Back to article view | Back to comp.lang.c
Octal BartC <bc@freeuk.com> - 2016-12-27 14:08 +0000
Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 06:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 14:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:07 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 15:22 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:37 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 16:24 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:30 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 09:10 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 09:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 10:47 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:03 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 12:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:44 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 13:37 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:38 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 17:53 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:26 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:48 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 22:20 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 18:41 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 19:19 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-29 14:52 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 18:41 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:54 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 17:44 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 22:39 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 11:49 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 23:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 12:32 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:51 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 14:00 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 01:13 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:04 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:45 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-29 14:49 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 15:33 -0800
Re: Octal supercat@casperkitty.com - 2016-12-30 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:19 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:32 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-14 12:35 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:51 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:25 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 06:21 -0800
Re: Octal supercat@casperkitty.com - 2017-01-14 14:00 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:08 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:02 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:52 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:46 -0800
Re: Octal supercat@casperkitty.com - 2017-01-16 01:46 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:33 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:19 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 09:39 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:02 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:13 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:41 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:31 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:39 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:05 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:05 +0000
Re: Octal asetofsymbols@gmail.com - 2016-12-28 11:20 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:01 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 12:30 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:51 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 16:26 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:40 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:41 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 18:04 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 19:36 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:42 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 00:34 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 11:04 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:09 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:46 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:56 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:52 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:27 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:09 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:02 +0000
Re: Octal Ike Naar <ike@iceland.freeshell.org> - 2016-12-28 17:25 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:45 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:21 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 09:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:23 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 11:18 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:54 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 12:57 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:01 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:44 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 17:32 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:03 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:26 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:31 +1300
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:58 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:59 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 09:00 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:21 +0100
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 11:52 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:10 +0000
Re: Octal supercat@casperkitty.com - 2016-12-29 05:52 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 19:51 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 21:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:15 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:53 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 12:07 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 13:04 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 05:31 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 15:00 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 15:55 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:00 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 08:33 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:02 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:38 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 13:59 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-01 14:24 -0800
Re: Octal supercat@casperkitty.com - 2017-01-01 15:51 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 13:09 +1300
Re: Octal supercat@casperkitty.com - 2017-01-01 16:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:24 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-02 01:53 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:15 +1300
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:28 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 06:24 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 17:53 +0000
Re: Octal luser droog <luser.droog@gmail.com> - 2016-12-30 10:01 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 09:57 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 13:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 11:09 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 14:46 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:28 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 16:01 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 14:48 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:51 +0000
Re: Octal supercat@casperkitty.com - 2016-12-30 15:20 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:34 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 23:40 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:12 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 21:38 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 12:04 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 13:42 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 08:59 +1300
Re: Octal supercat@casperkitty.com - 2016-12-29 12:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:56 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 22:09 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:27 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 21:18 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:46 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 20:55 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 14:54 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:44 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:39 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:04 -0600
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 19:52 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 09:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 18:02 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 16:17 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:09 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:02 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:32 -0800
Re: Octal Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 13:45 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:16 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:26 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-02 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-12 23:22 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:45 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:59 -0800
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 09:45 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 17:14 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 10:37 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 03:07 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:25 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 11:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 04:35 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:31 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 09:38 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:12 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:20 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 13:39 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:29 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:20 +0100
Re: Octal Noob <root@127.0.0.1> - 2016-12-28 13:02 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:30 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 13:25 +0000
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 15:19 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 08:37 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:43 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:07 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:21 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 15:28 +0100
Re: Octal BGB <cr88192@hotmail.com> - 2016-12-27 11:42 -0600
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-28 12:09 +0000 |
| Message-ID | <87o9zwgsrh.fsf@bsb.me.uk> |
| In reply to | #100410 |
BartC <bc@freeuk.com> writes: > On 28/12/2016 01:52, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: > >> The root of this minor glitch is that 'E' or 'e' can be either a >> hexadecimal digit *or* it can introduce an exponent in a decimal >> floating constant. > > But this is a hexadecimal one! So there is no conflict. > >>> And what would the value of that preprocessing number be? >> >> That particular pp-number has no value, either in the sense of a numeric >> value or of it being useful. Its illegality is just a consequence of >> the admittedly rather odd rules for handling numeric constants in the >> preprocessor and in later translation phases, rules that were presumably >> designed both to make the preprocessor's job easier and to maintain >> compatibility with existing implementations. > > What /is/ the preprocessor's job? As I still don't understand what is > going on. > > Are you saying that the sequence "127.0.0.1", which might be parsed in > a normal language as "127.0", ".0", ".1" (and very likely a syntax > error), is treated by the pp as one token "127.0.0.1" and passed on to > the program also as one token "127.0.0.1"? > > This is contrary to my understanding of how the preprocessor works, > which is that the output is considered to be text-based, not > token-based, and the next compilation phase will see the character > sequence "127.0.0.1" and re-tokenise it whichever way it wants. Maybe you are confusing how they often work with how the process is defined? The process is defined in terms of tokens (the result of the PP is, logically, a sequence of tokens) but the PP's output can be a text stream provided that the following phases of the implementation behave as they are required to do. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-28 08:17 -0800 |
| Message-ID | <a1f82620-a8cb-472f-b9e1-3b480f084587@googlegroups.com> |
| In reply to | #100410 |
On Wednesday, December 28, 2016 at 5:27:34 AM UTC-6, Bart wrote:
> This is contrary to my understanding of how the preprocessor works,
> which is that the output is considered to be text-based, not
> token-based, and the next compilation phase will see the character
> sequence "127.0.0.1" and re-tokenise it whichever way it wants.
Prior to the C Standard, some compilers had a preprocessor stage which ran
through all the source files and combined them into a preprocessor-output
text file, which was then fed to subsequent compilation stages, while others
would have the preprocessor generate data in an internal-use format (either
in memory or disk) which retained the results of scanning certain parts.
For example, given something like:
#define plusplus() ++
int main(void)
{
int i=0,=0;
return i+plus()j;
}
some compilers which ran the preprocessor as a separate stage may have
converted the return statement into "return i+++j;" which would in turn
be parsed as "return i++ +j;", but others may have converted the first
+ to a token before expanding the macro "plus()", and thus interpreting
the statement as "return i+ ++j;".
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 17:02 +0000 |
| Message-ID | <o40r4j$cqc$1@dont-email.me> |
| In reply to | #100429 |
On 28/12/2016 16:17, supercat@casperkitty.com wrote:
> On Wednesday, December 28, 2016 at 5:27:34 AM UTC-6, Bart wrote:
>> This is contrary to my understanding of how the preprocessor works,
>> which is that the output is considered to be text-based, not
>> token-based, and the next compilation phase will see the character
>> sequence "127.0.0.1" and re-tokenise it whichever way it wants.
>
> Prior to the C Standard, some compilers had a preprocessor stage which ran
> through all the source files and combined them into a preprocessor-output
> text file, which was then fed to subsequent compilation stages, while others
> would have the preprocessor generate data in an internal-use format (either
> in memory or disk) which retained the results of scanning certain parts.
I rarely use macros with parameters but never realised they were such a
minefield. And in fact the rules would effect also affect straight
source whether it uses macros or not.
> For example, given something like:
>
> #define plusplus() ++
> int main(void)
> {
> int i=0,=0;
> return i+plus()j;
> }
>
> some compilers which ran the preprocessor as a separate stage may have
> converted the return statement into "return i+++j;" which would in turn
> be parsed as "return i++ +j;", but others may have converted the first
> + to a token before expanding the macro "plus()", and thus interpreting
> the statement as "return i+ ++j;".
How was it possible to have a language that gave different results
depending on how the preprocessing rules were interpreted?
But fortunately your example is parsed as "+ ++" on all the compilers
I've tried.
(Tomorrow I'll have a go at writing a preprocessor to see how far I can
get; not an enticing prospect. Hopefully it'll have little impact on
throughput for code that sparsely uses macros (currently around 5Mlps).
But there is no way my pp would generate "+++" and then "++","+" from
that example, no matter what the Standard says! Nor "0x123E+3" as a
single token.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-12-28 17:25 +0000 |
| Message-ID | <slrn3vfso67te3.sbb.ike@iceland.freeshell.org> |
| In reply to | #100436 |
On 2016-12-28, BartC <bc@freeuk.com> wrote:
> On 28/12/2016 16:17, supercat@casperkitty.com wrote:
>> On Wednesday, December 28, 2016 at 5:27:34 AM UTC-6, Bart wrote:
>>> This is contrary to my understanding of how the preprocessor works,
>>> which is that the output is considered to be text-based, not
>>> token-based, and the next compilation phase will see the character
>>> sequence "127.0.0.1" and re-tokenise it whichever way it wants.
>>
>> Prior to the C Standard, some compilers had a preprocessor stage which ran
>> through all the source files and combined them into a preprocessor-output
>> text file, which was then fed to subsequent compilation stages, while others
>> would have the preprocessor generate data in an internal-use format (either
>> in memory or disk) which retained the results of scanning certain parts.
>
> I rarely use macros with parameters but never realised they were such a
> minefield. And in fact the rules would effect also affect straight
> source whether it uses macros or not.
>
>> For example, given something like:
>>
>> #define plusplus() ++
>> int main(void)
>> {
>> int i=0,=0;
>> return i+plus()j;
>> }
>>
>> some compilers which ran the preprocessor as a separate stage may have
>> converted the return statement into "return i+++j;" which would in turn
>> be parsed as "return i++ +j;", but others may have converted the first
>> + to a token before expanding the macro "plus()", and thus interpreting
>> the statement as "return i+ ++j;".
>
> How was it possible to have a language that gave different results
> depending on how the preprocessing rules were interpreted?
Did you miss the phrase "Prior to the C standard [...]" in supercat's
post?
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 17:45 +0000 |
| Message-ID | <o40tkb$l69$1@dont-email.me> |
| In reply to | #100440 |
On 28/12/2016 17:25, Ike Naar wrote: > On 2016-12-28, BartC <bc@freeuk.com> wrote: >> How was it possible to have a language that gave different results >> depending on how the preprocessing rules were interpreted? > > Did you miss the phrase "Prior to the C standard [...]" in supercat's > post? It doesn't change my point. Have the result of two consecutive macro expansions be either "A B" or "AB" is quite a big deal to just be left to the whim of an implementer. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 10:21 -0800 |
| Message-ID | <lnful752yg.fsf@kst-u.example.com> |
| In reply to | #100447 |
BartC <bc@freeuk.com> writes:
> On 28/12/2016 17:25, Ike Naar wrote:
>> On 2016-12-28, BartC <bc@freeuk.com> wrote:
>>> How was it possible to have a language that gave different results
>>> depending on how the preprocessing rules were interpreted?
>>
>> Did you miss the phrase "Prior to the C standard [...]" in supercat's
>> post?
>
> It doesn't change my point.
I think it does.
> Have the result of two consecutive macro
> expansions be either "A B" or "AB" is quite a big deal to just be left
> to the whim of an implementer.
Now that we have a standard, the behavior is unambiguous. You're
inventing a problem that does not exist.
And if, as you said elsethread, you're going to implement a C
preprocessor while ignoring the requirements of the standard, you're
actually *creating* a problem that does not currently exist.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-28 09:27 -0800 |
| Message-ID | <ed3b405f-1661-4f0c-8225-4d4ac34678c6@googlegroups.com> |
| In reply to | #100436 |
On Wednesday, December 28, 2016 at 11:02:48 AM UTC-6, Bart wrote: > How was it possible to have a language that gave different results > depending on how the preprocessing rules were interpreted? > > But fortunately your example is parsed as "+ ++" on all the compilers > I've tried. Compilers have been processing such things consistently for a long time; in the case of preprocessors which produce text-file output, the normal solution is to add a white space character into the preprocessor output between tokens in cases where they might otherwise get grouped, though that requires that the compiler recognize all the places where such a space may be needed. > (Tomorrow I'll have a go at writing a preprocessor to see how far I can > get; not an enticing prospect. Hopefully it'll have little impact on > throughput for code that sparsely uses macros (currently around 5Mlps). > > But there is no way my pp would generate "+++" and then "++","+" from > that example, no matter what the Standard says! Nor "0x123E+3" as a > single token.) I don't know that any version of the Standard would ever have allowed the pluses to be parsed as "++ +" but in the days before the Standard there were lots of differences in how compilers handled corner cases; while it's often good to clarify corner-case behavior, it's even better to provide ways of avoiding having to deal with them altogether. Unfortunately, C's pre- processor is not only extremely limited, but it is also designed in a way which makes it hard to incorporate user-written tools into the translation process. It would be helpful, for example, if there were an optional annex to provide recommendations for how compilers might offer to split the preprocessing and main compilation steps such that an outside tool could be run between them. Because such support may not be practical on all systems the Standard should not require it for all implementations, but on many systems such support could be easily supported and also useful on the systems where it was practical.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 10:23 -0800 |
| Message-ID | <lnbmvv52vm.fsf@kst-u.example.com> |
| In reply to | #100441 |
supercat@casperkitty.com writes:
[...]
> I don't know that any version of the Standard would ever have allowed the
> pluses to be parsed as "++ +" but in the days before the Standard there
> were lots of differences in how compilers handled corner cases; while it's
> often good to clarify corner-case behavior, it's even better to provide ways
> of avoiding having to deal with them altogether. Unfortunately, C's pre-
> processor is not only extremely limited, but it is also designed in a way
> which makes it hard to incorporate user-written tools into the translation
> process. It would be helpful, for example, if there were an optional annex
> to provide recommendations for how compilers might offer to split the
> preprocessing and main compilation steps such that an outside tool could be
> run between them. Because such support may not be practical on all systems
> the Standard should not require it for all implementations, but on many
> systems such support could be easily supported and also useful on the systems
> where it was practical.
So you want the standard to specify something that isn't required for
all implementations.
Why not specify it outside the C standard, and let implementations
conform to the extra requirements if they want to?
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-28 11:18 -0800 |
| Message-ID | <e99c3bbf-5268-4c8e-8ccb-12ea5144ad7c@googlegroups.com> |
| In reply to | #100457 |
On Wednesday, December 28, 2016 at 12:23:09 PM UTC-6, Keith Thompson wrote: > supercat writes: > So you want the standard to specify something that isn't required for > all implementations. > > Why not specify it outside the C standard, and let implementations > conform to the extra requirements if they want to? In some cases, because the Standard would require that any programs making use of such features be regarded as ill-formed. In other cases because in the absence of a standard people writing different implementations may agree that compilers for certain platforms should offer certain features or guarantees, but may disagree how they should be supported. In cases where there would be two roughly-equally-good ways of implementing something, having the Standard make it an optional feature so everyone implements it the same way may be more helpful than waiting until after production code has been written for a variety of implementations using mutually-incompatible extensions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 10:19 -0800 |
| Message-ID | <lnk2aj531s.fsf@kst-u.example.com> |
| In reply to | #100436 |
BartC <bc@freeuk.com> writes:
> On 28/12/2016 16:17, supercat@casperkitty.com wrote:
>> On Wednesday, December 28, 2016 at 5:27:34 AM UTC-6, Bart wrote:
>>> This is contrary to my understanding of how the preprocessor works,
>>> which is that the output is considered to be text-based, not
>>> token-based, and the next compilation phase will see the character
>>> sequence "127.0.0.1" and re-tokenise it whichever way it wants.
>>
>> Prior to the C Standard, some compilers had a preprocessor stage which ran
>> through all the source files and combined them into a preprocessor-output
>> text file, which was then fed to subsequent compilation stages, while others
>> would have the preprocessor generate data in an internal-use format (either
>> in memory or disk) which retained the results of scanning certain parts.
>
> I rarely use macros with parameters but never realised they were such a
> minefield. And in fact the rules would effect also affect straight
> source whether it uses macros or not.
They're not really that much of a minefield.
>> For example, given something like:
>>
>> #define plusplus() ++
>> int main(void)
>> {
>> int i=0,=0;
>> return i+plus()j;
>> }
>>
>> some compilers which ran the preprocessor as a separate stage may have
>> converted the return statement into "return i+++j;" which would in turn
>> be parsed as "return i++ +j;", but others may have converted the first
>> + to a token before expanding the macro "plus()", and thus interpreting
>> the statement as "return i+ ++j;".
>
> How was it possible to have a language that gave different results
> depending on how the preprocessing rules were interpreted?
It was possible because the language had not yet been standardized.
Since 1989, it has been, and there is no ambiguity in supercat's
example. `i+plus()j` is unambiguously equivalent to `i + ++ j`.
> But fortunately your example is parsed as "+ ++" on all the compilers
> I've tried.
Good.
> (Tomorrow I'll have a go at writing a preprocessor to see how far I can
> get; not an enticing prospect. Hopefully it'll have little impact on
> throughput for code that sparsely uses macros (currently around 5Mlps).
>
> But there is no way my pp would generate "+++" and then "++","+" from
> that example, no matter what the Standard says! Nor "0x123E+3" as a
> single token.)
So you're going to implement a C preprocessor, but you're not interested
in what the Standard says. Interesting choice.
--
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 | 2016-12-29 15:54 +0000 |
| Message-ID | <o43bg3$u8t$1@dont-email.me> |
| In reply to | #100455 |
On 29/12/2016 12:42, David Brown wrote: > On 29/12/16 13:04, BartC wrote: >> I don't care for that vast array of features. I'm only interested in two: >> >> * The speed of its generated code >> * And that gcc is available everywhere and is stable and well-tested >> > > I, and many others, find a lot of other features of gcc important. In > no particular order, and in addition to your two points, these include: > * Powerful inline assembly So powerful that it is practically unusable! > * Supported as /the/ standard compiler by many microcontroller manufacturers > * Part of a solid toolchain and development environment > * Works on both Linux and Windows That should be a given; what exactly is the difference between the two for a /compiler/? > Different people have different needs from their toolchains. And if you > have very limited needs, it might be annoying to have to "pay" in speed > and size for features you don't want. Compiling one of my programs from scratch on an early Raspberry Pi takes about 5 minutes using gcc -O3. That's about 100 lines per second, on a 700MHz processor. Apart from speed, another property I like is for a tool to be small and compact, and be easy (and quick) to build if I should need to. gcc fails on all counts. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-29 12:57 -0800 |
| Message-ID | <4a97740c-7df0-47b9-8f24-bf4a4f775c00@googlegroups.com> |
| In reply to | #100462 |
On Thursday, December 29, 2016 at 4:32:22 PM UTC, David Brown wrote: > > The earliest Raspberry Pi's were very slow, and had particularly slow > "disks". But so what? One of gcc's strengths is its flexibility for > cross compiling - people who know how to use their tools and want to > compile large programs for a Raspberry Pi usually do so on a desktop > machine. > That's against the spirit of the Raspberry PI. The idea is that you give it to junior and he can do with it as he will. Which you can't do with a PC (unless you're a millionaire), because if junior breaks it you just tut tut and buy him another three. > > Yes, well, different people have different needs. But it gets silly > when you repeatedly condemn gcc as big and slow when you don't actually > understand it and why it is different from a tool like TCC. If TCC is > better for /your/ needs, then that's great - use TCC. Just don't > imagine that /your/ needs and priorities apply to anyone else. > There is tendency in the software world to fail to understand that size and complexity still have a cost, even if downloads and disk space are essentially free. But gcc produces tighter code than tcc and tends to be installed by default. It's the compile I use for Baby X Linux.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-30 10:01 +1300 |
| Message-ID | <eclbtpFpuo9U7@mid.individual.net> |
| In reply to | #100466 |
On 12/30/16 09:57 AM, Malcolm McLean wrote: > On Thursday, December 29, 2016 at 4:32:22 PM UTC, David Brown wrote: >> >> The earliest Raspberry Pi's were very slow, and had particularly slow >> "disks". But so what? One of gcc's strengths is its flexibility for >> cross compiling - people who know how to use their tools and want to >> compile large programs for a Raspberry Pi usually do so on a desktop >> machine. >> > That's against the spirit of the Raspberry PI. The idea is that you > give it to junior and he can do with it as he will. Which you can't > do with a PC (unless you're a millionaire), because if junior breaks > it you just tut tut and buy him another three. Junior would have been using a development kit on her PC, or if she were more advanced, Python on the Pi... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-30 10:44 +0100 |
| Message-ID | <o45a7h$b8k$1@dont-email.me> |
| In reply to | #100466 |
On 29/12/16 21:57, Malcolm McLean wrote: > On Thursday, December 29, 2016 at 4:32:22 PM UTC, David Brown wrote: >> >> The earliest Raspberry Pi's were very slow, and had particularly slow >> "disks". But so what? One of gcc's strengths is its flexibility for >> cross compiling - people who know how to use their tools and want to >> compile large programs for a Raspberry Pi usually do so on a desktop >> machine. >> > That's against the spirit of the Raspberry PI. The idea is that you > give it to junior and he can do with it as he will. Which you can't > do with a PC (unless you're a millionaire), because if junior breaks > it you just tut tut and buy him another three. Junior can use gcc on the Pi to compile hello_world.c without any problems. But when they want to re-compile their home-made web browser, it's time to move to a PC and cross-compilation tools.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-29 17:32 +0100 |
| Message-ID | <o43dnk$7a0$1@dont-email.me> |
| In reply to | #100462 |
On 29/12/16 16:54, BartC wrote: > On 29/12/2016 12:42, David Brown wrote: >> On 29/12/16 13:04, BartC wrote: > >>> I don't care for that vast array of features. I'm only interested in >>> two: >>> >>> * The speed of its generated code >>> * And that gcc is available everywhere and is stable and well-tested >>> >> >> I, and many others, find a lot of other features of gcc important. In >> no particular order, and in addition to your two points, these include: > >> * Powerful inline assembly > > So powerful that it is practically unusable! I use it, when I need to (I don't write anything in assembler if it can be done just as well in C). So do many people. And the syntax has been copied by several other compilers. > >> * Supported as /the/ standard compiler by many microcontroller >> manufacturers >> * Part of a solid toolchain and development environment >> * Works on both Linux and Windows > > That should be a given; what exactly is the difference between the two > for a /compiler/? There are lots of tools that are not cross-platform. It is a requirement for /me/, since I use both Linux and Windows, but a large proportion of users are happy as long as a tool works on their particular platform. > >> Different people have different needs from their toolchains. And if you >> have very limited needs, it might be annoying to have to "pay" in speed >> and size for features you don't want. > > Compiling one of my programs from scratch on an early Raspberry Pi takes > about 5 minutes using gcc -O3. That's about 100 lines per second, on a > 700MHz processor. The earliest Raspberry Pi's were very slow, and had particularly slow "disks". But so what? One of gcc's strengths is its flexibility for cross compiling - people who know how to use their tools and want to compile large programs for a Raspberry Pi usually do so on a desktop machine. > > Apart from speed, another property I like is for a tool to be small and > compact, and be easy (and quick) to build if I should need to. gcc fails > on all counts. > Yes, well, different people have different needs. But it gets silly when you repeatedly condemn gcc as big and slow when you don't actually understand it and why it is different from a tool like TCC. If TCC is better for /your/ needs, then that's great - use TCC. Just don't imagine that /your/ needs and priorities apply to anyone else.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-29 17:03 +0000 |
| Message-ID | <o43fj2$ene$1@dont-email.me> |
| In reply to | #100499 |
On 29/12/2016 16:32, David Brown wrote: > On 29/12/16 16:54, BartC wrote: >> Compiling one of my programs from scratch on an early Raspberry Pi takes >> about 5 minutes using gcc -O3. That's about 100 lines per second, on a >> 700MHz processor. > > The earliest Raspberry Pi's were very slow, and had particularly slow > "disks". But so what? The same machine, with the same 'slow' disks, can compile bytecode at up to 50K lines per second (and I expected up to 100K lps, but am at the mercy of gcc's code generator until I can investigate for myself). A 700MHz 32-bit machine with solid-state disks should be a supercomputer compared with what many of us were using in the 80s, or even the 90s. >> Apart from speed, another property I like is for a tool to be small and >> compact, and be easy (and quick) to build if I should need to. gcc fails >> on all counts. >> > > Yes, well, different people have different needs. But it gets silly > when you repeatedly condemn gcc as big and slow when you don't actually > understand it and why it is different from a tool like TCC. If TCC is > better for /your/ needs, then that's great - use TCC. Just don't > imagine that /your/ needs and priorities apply to anyone else. Some interesting views coming out on this thread. It seems that even if a compiler and build system processed an infinite number of lines per second, and had compile/build times of 0.0 seconds, then people would still prefer to stick with their old lumbering versions! And if those tools are a bit too slow, then buy a much faster computer to run them on! (re. your cross-compiling comment). I condemn gcc because whenever /I/ use it, it /is/ slow. But I have to admit it does the job (eventually). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-29 16:26 -0600 |
| Message-ID | <ea2b6c1rg4vd8uo0eapk95cub8kq3sbg1d@4ax.com> |
| In reply to | #100532 |
On Fri, 30 Dec 2016 09:00:38 +1300, Ian Collins <ian-news@hotmail.com> wrote: >On 12/30/16 06:03 AM, BartC wrote: >> On 29/12/2016 16:32, David Brown wrote: >>> On 29/12/16 16:54, BartC wrote: >> >>>> Compiling one of my programs from scratch on an early Raspberry Pi takes >>>> about 5 minutes using gcc -O3. That's about 100 lines per second, on a >>>> 700MHz processor. >>> >>> The earliest Raspberry Pi's were very slow, and had particularly slow >>> "disks". But so what? >> >> The same machine, with the same 'slow' disks, can compile bytecode at up >> to 50K lines per second (and I expected up to 100K lps, but am at the >> mercy of gcc's code generator until I can investigate for myself). >> >> A 700MHz 32-bit machine with solid-state disks should be a supercomputer >> compared with what many of us were using in the 80s, or even the 90s. > >I wouldn't class an SD card as "solid-state disks"! Leaving aside the silliness of including the word "disk" in the name... How exactly do you distinguish? Both are block addressable devices, albeit with a different I/O interface (although some SD cards can operate in ATA mode). How about a USB memory stick? Sure, most things marketed as "SSDs" likely are faster and more reliable than the average SD card, but neither of those seems like a useful hard discriminator.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-30 11:31 +1300 |
| Message-ID | <eclh62Fpuo9U11@mid.individual.net> |
| In reply to | #100536 |
On 12/30/16 11:26 AM, Robert Wessel wrote: > On Fri, 30 Dec 2016 09:00:38 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> I wouldn't class an SD card as "solid-state disks"! > > > Leaving aside the silliness of including the word "disk" in the > name... > > How exactly do you distinguish? Both are block addressable devices, > albeit with a different I/O interface (although some SD cards can > operate in ATA mode). How about a USB memory stick? The usual discriminator is something solid state that is interchangeable with spinning rust. These days the lines are more burly with solid state only devices such as NVMe and mSATA. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-29 16:58 -0600 |
| Message-ID | <qp4b6c1sk21mkletuh5q2n7jq9gfe15tbj@4ax.com> |
| In reply to | #100539 |
On Fri, 30 Dec 2016 11:31:30 +1300, Ian Collins <ian-news@hotmail.com> wrote: >On 12/30/16 11:26 AM, Robert Wessel wrote: >> On Fri, 30 Dec 2016 09:00:38 +1300, Ian Collins <ian-news@hotmail.com> >> wrote: >> >>> I wouldn't class an SD card as "solid-state disks"! >> >> >> Leaving aside the silliness of including the word "disk" in the >> name... >> >> How exactly do you distinguish? Both are block addressable devices, >> albeit with a different I/O interface (although some SD cards can >> operate in ATA mode). How about a USB memory stick? > >The usual discriminator is something solid state that is interchangeable >with spinning rust. These days the lines are more burly with solid >state only devices such as NVMe and mSATA. So where does that leave USB memory sticks vs. USB external HDs? Or an SD card plus a $10 SATA-to-SD adapter?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-30 11:59 +1300 |
| Message-ID | <ecliquFpuo9U12@mid.individual.net> |
| In reply to | #100553 |
On 12/30/16 11:58 AM, Robert Wessel wrote: > On Fri, 30 Dec 2016 11:31:30 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> On 12/30/16 11:26 AM, Robert Wessel wrote: >>> On Fri, 30 Dec 2016 09:00:38 +1300, Ian Collins <ian-news@hotmail.com> >>> wrote: >>> >>>> I wouldn't class an SD card as "solid-state disks"! >>> >>> >>> Leaving aside the silliness of including the word "disk" in the >>> name... >>> >>> How exactly do you distinguish? Both are block addressable devices, >>> albeit with a different I/O interface (although some SD cards can >>> operate in ATA mode). How about a USB memory stick? >> >> The usual discriminator is something solid state that is interchangeable >> with spinning rust. These days the lines are more burly with solid >> state only devices such as NVMe and mSATA. > > > So where does that leave USB memory sticks vs. USB external HDs? > > Or an SD card plus a $10 SATA-to-SD adapter? In the slow lane... -- Ian
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web