Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #92512 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2016-08-19 14:22 -0700 |
| Last post | 2016-08-22 05:11 -0700 |
| Articles | 20 on this page of 355 — 30 participants |
Back to article view | Back to comp.lang.c
Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 14:22 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 09:36 +1200
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 22:48 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 14:56 -0700
Re: Default values in #define Chad <cdalten@gmail.com> - 2016-08-22 07:56 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-22 17:09 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:21 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:47 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:55 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-22 09:27 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 09:41 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-22 20:19 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 12:54 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 09:14 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:23 -0700
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-23 05:42 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:52 -0700
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-23 06:01 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:06 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:01 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:56 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:59 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-23 10:42 -0700
Re: Default values in #define matt@godbolt.org - 2016-08-23 06:47 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:57 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:31 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:43 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 16:06 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 07:15 -0700
Re: Default values in #define albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-04 13:26 +0100
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-05 22:07 -0600
Re: Default values in #define supercat@casperkitty.com - 2016-12-06 06:22 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 00:50 -0600
Re: Default values in #define supercat@casperkitty.com - 2016-12-07 06:33 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 23:06 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-08 01:44 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-08 06:58 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 08:16 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 02:47 -0600
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 15:49 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 15:52 -0800
Re: Default values in #define asetofsymbols@gmail.com - 2016-12-09 00:52 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 03:19 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-07 04:43 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-08 14:18 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-08 07:22 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-08 08:00 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-08 22:14 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-12-08 13:44 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:07 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-09 17:00 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 17:46 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 08:37 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-10 09:42 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 10:05 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 02:51 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-11 04:40 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 23:06 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 03:15 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-12 16:12 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 07:33 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-13 01:45 -0600
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 16:49 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 10:25 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 10:50 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 04:02 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-13 13:14 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:57 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 14:32 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:58 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:21 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-13 14:41 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:47 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 16:24 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 07:30 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:12 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 12:21 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 15:02 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 13:19 -0800
Petty and unprofessional (Was: Default values in #define) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-13 16:46 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 09:04 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 20:06 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 11:19 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-13 11:33 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 11:44 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-14 10:04 +0100
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:37 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:28 -0600
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:23 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 16:10 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 18:54 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 18:57 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 02:53 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 05:59 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 12:03 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 12:22 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 17:09 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 18:37 -0800
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:25 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 07:31 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 07:35 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 09:17 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 11:03 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 11:41 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 12:31 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 13:13 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-12 20:22 +0000
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 14:49 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-11 07:10 -0800
Re: Default values in #define luser droog <luser.droog@gmail.com> - 2016-12-11 07:21 -0800
Re: Default values in #define jameskuyper@verizon.net - 2016-12-11 10:33 -0800
Re: Default values in #define Melzzzzz <mel@zzzzz.com> - 2016-12-11 16:22 +0100
Re: Default values in #define luser droog <luser.droog@gmail.com> - 2016-12-11 07:16 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 13:54 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 14:09 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:31 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 16:11 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:49 -0700
Re: Default values in #define Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-21 05:50 -0600
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-21 13:10 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-22 12:56 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-22 21:11 +0100
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-22 15:47 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-23 11:54 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-23 20:07 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-23 14:30 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-24 06:25 +0100
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-24 10:34 +0200
Re: Default values in #define Richard Damon <Richard@Damon-Family.org> - 2016-08-24 08:50 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-24 15:37 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-24 11:58 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 01:27 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-24 22:28 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 23:38 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 10:44 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 07:29 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-25 07:32 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:26 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-25 11:11 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 12:03 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:31 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-29 09:28 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 22:51 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-29 16:35 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 01:44 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-30 10:06 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 10:41 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 21:24 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 12:32 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-30 22:30 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 09:17 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:46 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-31 10:29 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 10:12 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-31 12:30 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 11:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:56 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 08:17 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:18 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:34 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 00:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-02 05:19 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-01 11:38 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 10:03 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 10:31 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 12:50 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-01 21:30 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-02 05:37 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-02 08:16 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:20 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-06 07:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:54 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-02 08:40 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-02 10:16 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 15:16 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-25 08:28 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:14 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 00:54 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 01:00 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 11:17 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 04:08 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 13:45 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 06:09 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 17:11 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 09:31 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 12:48 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 09:50 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:01 +0200
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 10:57 -0700
Re: Default values in #define Ike Naar <ike@iceland.freeshell.org> - 2016-08-31 06:09 +0000
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 12:24 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 17:27 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 17:39 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:49 +0100
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:51 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:46 +0200
Re: Default values in #define Richard Damon <Richard@Damon-Family.org> - 2016-08-26 17:37 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 15:05 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 10:25 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 16:25 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 18:12 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 13:47 +1200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 19:32 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 22:54 -0400
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 21:11 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 18:25 +1200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 09:11 -0400
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 06:33 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 10:16 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 13:17 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 16:26 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 13:10 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 16:35 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 09:28 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 15:38 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 13:27 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 16:42 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:16 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 17:24 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:21 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 08:12 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 15:24 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 10:53 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 10:34 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 14:44 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 12:48 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 17:19 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 11:24 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:33 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 09:51 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:46 -0400
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-30 16:26 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-03 17:31 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:03 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 21:36 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 17:30 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 12:39 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 03:57 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 15:34 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 07:33 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:46 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 10:03 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:52 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 07:41 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 14:58 -0400
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 02:27 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 08:21 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-31 09:05 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-31 09:15 -0700
Re: Default values in #define Rosario19 <Ros@invalid.invalid> - 2016-09-02 22:22 +0200
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-28 08:41 +1200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:34 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 09:41 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 08:07 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:08 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 15:41 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 16:30 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 17:14 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 17:20 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 23:37 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 02:19 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:26 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 04:40 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:56 +0200
Re: Default values in #define albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-04 15:43 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 19:34 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 00:51 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 20:36 +1200
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-08-31 00:39 -0500
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 21:40 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 09:22 -0400
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 11:36 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:26 -0800
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-27 06:34 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 12:48 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:12 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:10 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:18 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 10:32 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:49 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:13 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:48 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 09:14 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 08:59 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:43 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-29 22:58 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-30 07:14 +0100
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-30 00:14 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 00:26 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 02:10 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 10:47 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 03:32 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:38 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 04:44 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 14:00 +0200
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 18:55 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 12:24 -0700
Re: Default values in #define me <crisdunbar@gmail.com> - 2016-08-30 14:11 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 16:28 -0700
Re: Default values in #define me <crisdunbar@gmail.com> - 2016-08-30 16:54 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-31 06:27 +0100
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 23:09 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 16:06 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:35 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:30 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 04:39 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:40 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:17 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 06:47 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:58 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 09:09 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:16 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 02:02 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 12:49 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 09:02 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 10:31 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:01 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:24 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:43 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:29 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 16:27 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-25 10:02 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:33 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-25 14:12 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 14:22 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:27 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-22 23:13 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 14:39 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 09:32 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:33 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 06:13 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:22 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 16:13 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 07:35 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-23 19:08 +0100
Re: Default values in #define Rosario19 <Ros@invalid.invalid> - 2016-08-24 09:05 +0200
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-24 00:49 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-24 05:40 -0700
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-19 22:56 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 10:14 +1200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 18:09 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 13:15 +1200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 19:10 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 14:50 +1200
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-20 10:35 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-20 03:13 -0700
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-20 12:24 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-21 00:14 +1200
Re: Default values in #define gazelle@shell.xmission.com (Kenny McCormack) - 2016-08-20 14:13 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 05:17 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-20 12:08 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 14:06 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-20 12:14 -0700
Re: Default values in #define Philipp Klaus Krause <pkk@spth.de> - 2016-08-21 12:51 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 05:11 -0700
Page 5 of 18 — ← Prev page 1 … 3 4 [5] 6 7 … 18 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 09:04 -0800 |
| Message-ID | <6ffdfa0f-3fec-4cac-a086-25a475da81ee@googlegroups.com> |
| In reply to | #99192 |
On Tuesday, December 13, 2016 at 8:32:23 AM UTC-5, David Brown wrote: > On 13/12/16 13:02, Rick C. Hodgin wrote: > > I used to code almost exclusively in assembly in the 1990s. It was my > > everyday language. And AT&T syntax was horrid to my eyes and mind > > even back then. It remains patently so to this day, to the point where > > if I were forced to code in it ... I would not. I would leave that job > > and find another. And if there weren't any, I would switch professions. > > There is no other way to describe that than petty and unprofessional. Sure there is. As with most disagreements between us, you don't place any value on the things I place great value on, and therefore you are able to conclude "petty and unprofessional" and be justified in your mind in so doing. > There may certainly be business decisions that you cannot in good > conscience accept, and there may also be business decisions that change > the scope of the job or the way of working to such an extent that it is > no longer the job you want. But this is not one of them. There are > very few people who are employed as "x86 assembly programmers" - I doubt > if there are /any/ who are employed as "Intel syntax x86 assembly > programmers". I was surprised. When I went to Intel in 2007 to see one of their development and testing facilities in the U.S. pacific northwest, I was shown a room with about 35 developers. I asked them what they were doing in there? I was told they are writing test cases in assembly to test various aspects of the CPU's functionality. For all I know they were paid actors brought in that day to put on a good show for TGDaily.com (the online website I was reporting for). > It amazes me how amazed you are over something so trivial. I know. It's amazing. :-) There aren't too many things in my life I would change professions over. Nearly all of them relate to ethics / morals issues where I would take a hard stance on something because of my faith. This is one of the few other areas where a personal issue, such as the difficulty I have in reading, would cause me to leave due to hardship on the job. But, I doubt it would come to that. Historically, I've been given a pretty wide latitude over what tools I'm able to use to conduct my work, so long as I'm being productive. As such, I can't ever see it happening. Nonetheless, this is one where I would leave if it came down to only being able to use AT&T syntax, and my job duties related mostly to assembly development. Another is if I were forced to use Apple tools of any kind. I will not develop for Apple products. I'm also about to the place where I may be forced out anyway if my company forces me to switch from Win7 to Win10. I will not switch. I've tried Win10 and it is draconian in the way it invades the computer and desktop. So far, my manager has said I can be the one hold out who uses a Win7 machine because we still have many customers who use Win7 and we need to support their configuration, and that's not likely to change for many years. Some things are important to people, David. You shouldn't discount them so easily. It's okay to be amazed, but to conclude something like "petty and unprofessional" is simply out of line. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-13 20:06 +0100 |
| Message-ID | <o2pgpn$8pq$1@dont-email.me> |
| In reply to | #99219 |
On 13/12/16 18:04, Rick C. Hodgin wrote: > On Tuesday, December 13, 2016 at 8:32:23 AM UTC-5, David Brown wrote: >> On 13/12/16 13:02, Rick C. Hodgin wrote: >>> I used to code almost exclusively in assembly in the 1990s. It was my >>> everyday language. And AT&T syntax was horrid to my eyes and mind >>> even back then. It remains patently so to this day, to the point where >>> if I were forced to code in it ... I would not. I would leave that job >>> and find another. And if there weren't any, I would switch professions. >> >> There is no other way to describe that than petty and unprofessional. > > Sure there is. As with most disagreements between us, you don't place > any value on the things I place great value on, and therefore you are > able to conclude "petty and unprofessional" and be justified in your > mind in so doing. > You have given some brief explanations of why you prefer the Intel syntax to the AT&T syntax. As explanations for a preference, they were absolutely fine (except for the "I'm a bit dyslexic" excuse - lots of people, including me, are somewhat dyslexic without letting it be a hinder. It is certainly /not/ a hinder for AT&T syntax more than it is for Intel syntax.). You have perfectly valid, justified opinions and reasons for preferring Intel syntax. But to view those as so important that you would rather leave programming than work with AT&T assembly - yes, that is petty and unprofessional. >> There may certainly be business decisions that you cannot in good >> conscience accept, and there may also be business decisions that change >> the scope of the job or the way of working to such an extent that it is >> no longer the job you want. But this is not one of them. There are >> very few people who are employed as "x86 assembly programmers" - I doubt >> if there are /any/ who are employed as "Intel syntax x86 assembly >> programmers". > > I was surprised. When I went to Intel in 2007 to see one of their > development and testing facilities in the U.S. pacific northwest, I > was shown a room with about 35 developers. I asked them what they > were doing in there? I was told they are writing test cases in > assembly to test various aspects of the CPU's functionality. > The chances are pretty high that those folks were using Intel syntax. But the chances are /very/ high that if they were asked to do the job using AT&T syntax (which is not impossible if they are using *nix tools), they would simply use AT&T syntax. In other words, they are x86 assembly programmers - /not/ Intel syntax x86 assembly programmers even if that happens to be the tool they use most. > For all I know they were paid actors brought in that day to put on > a good show for TGDaily.com (the online website I was reporting for). > >> It amazes me how amazed you are over something so trivial. > > I know. It's amazing. :-) > > There aren't too many things in my life I would change professions > over. Nearly all of them relate to ethics / morals issues where I > would take a hard stance on something because of my faith. This is > one of the few other areas where a personal issue, such as the > difficulty I have in reading, would cause me to leave due to hardship > on the job. I can understand taking a firm stance on ethical or moral issues, and resigning because of them. It's unlikely that I would agree with you on which issues are so important (though there would be some overlap), but I can understand it. I cannot understand taking such a stance over the syntax of an assembler, any more than I could understand resigning because of the colour of the wallpaper or the brand of coffee in the cafeteria. > > But, I doubt it would come to that. Historically, I've been given > a pretty wide latitude over what tools I'm able to use to conduct my > work, so long as I'm being productive. As such, I can't ever see > it happening. Nonetheless, this is one where I would leave if it > came down to only being able to use AT&T syntax, and my job duties > related mostly to assembly development. Another is if I were forced > to use Apple tools of any kind. I will not develop for Apple products. > > I'm also about to the place where I may be forced out anyway if my > company forces me to switch from Win7 to Win10. I will not switch. > I've tried Win10 and it is draconian in the way it invades the > computer and desktop. So far, my manager has said I can be the one > hold out who uses a Win7 machine because we still have many customers > who use Win7 and we need to support their configuration, and that's > not likely to change for many years. > > Some things are important to people, David. You shouldn't discount > them so easily. It's okay to be amazed, but to conclude something > like "petty and unprofessional" is simply out of line. > > Best regards, > Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 11:19 -0800 |
| Message-ID | <83a08f2d-b0ff-4410-a1c8-d0e2903af46a@googlegroups.com> |
| In reply to | #99229 |
On Tuesday, December 13, 2016 at 2:06:59 PM UTC-5, David Brown wrote: > I can understand taking a firm stance on ethical or moral issues, and > resigning because of them... > > I cannot understand taking such a stance over the syntax of an > assembler... Yep. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-13 11:33 -0800 |
| Message-ID | <lneg1bpqt4.fsf@kst-u.example.com> |
| In reply to | #99229 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> You have given some brief explanations of why you prefer the Intel
> syntax to the AT&T syntax.
Let me just point out that this has nothing to do with C. I'm sure
there are places where this would be topical (though I suspect it
would be considered a boring rehashing of a old dispute even there).
--
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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 11:44 -0800 |
| Message-ID | <f6cb9f0f-0e44-40be-9522-9a01128e405d@googlegroups.com> |
| In reply to | #99240 |
On Tuesday, December 13, 2016 at 2:32:30 PM UTC-5, Keith Thompson wrote: > Let me just point out that this has nothing to do with C. I'm sure > there are places where this would be topical (though I suspect it > would be considered a boring rehashing of a old dispute even there). Keith, have you ever noticed how you get in lots of little pokes with your replies? You're passive aggressive in your demeaning of other people. I'd get a handle on it if I were you because it's doing harm to both them and you. It also sends up flares and signals visibly the kind of person you are at your core. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-14 10:04 +0100 |
| Message-ID | <o2r1t6$k59$2@dont-email.me> |
| In reply to | #99240 |
On 13/12/16 20:33, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> You have given some brief explanations of why you prefer the Intel >> syntax to the AT&T syntax. > > Let me just point out that this has nothing to do with C. I'm sure > there are places where this would be topical (though I suspect it > would be considered a boring rehashing of a old dispute even there). > Fair 'nuff. The discussion is worn out anyway, I think.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-13 14:37 -0800 |
| Message-ID | <o2pt3s$mi2$1@dont-email.me> |
| In reply to | #99192 |
On 12/13/2016 5:32 AM, David Brown wrote:
> On 13/12/16 13:02, Rick C. Hodgin wrote:
>> FWIW, I always have been, and remain literally amazed, that anyone
>> who's seen AT&T syntax, and Intel's syntax, would choose AT&T's
>> over Intel's. I honestly believe it indicates something not right in
>> that person's thinking.
>
> I haven't written much x86, but I read a bit of it sometimes. I usually
> have a godbolt.org window open for various experimentations of
> compilation, and for a snippet I just compiled the generated code is:
godbolt.org is:
__________________________________________
.LC0:
.string "Awesome!"
main:
push rbp
mov rbp, rsp
mov edi, OFFSET FLAT:.LC0
call puts
mov eax, 0
pop rbp
ret
__________________________________________
;^D
__________________________________________
#include <cstdio>
int main() {
std::printf("Awesome!\n");
return 0;
}
__________________________________________
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-14 14:28 -0600 |
| Message-ID | <rs935c1dknv032c8so49vosevitc4jb4en@4ax.com> |
| In reply to | #99192 |
On Tue, 13 Dec 2016 14:32:16 +0100, David Brown
<david.brown@hesbynett.no> wrote:
>On 13/12/16 13:02, Rick C. Hodgin wrote:
>> FWIW, I always have been, and remain literally amazed, that anyone
>> who's seen AT&T syntax, and Intel's syntax, would choose AT&T's
>> over Intel's. I honestly believe it indicates something not right in
>> that person's thinking.
>
>I haven't written much x86, but I read a bit of it sometimes. I usually
>have a godbolt.org window open for various experimentations of
>compilation, and for a snippet I just compiled the generated code is:
>
>f1:
> xor eax, eax
> test BYTE PTR d[rip], 16
> sete al
> mov DWORD PTR d[rip], eax
> ret
>f3:
> mov eax, DWORD PTR d[rip]
> shr eax, 4
> xor eax, 1
> and eax, 1
> mov DWORD PTR d[rip], eax
> ret
>
>or
>
>f1:
> xorl %eax, %eax
> testb $16, d(%rip)
> sete %al
> movl %eax, d(%rip)
> ret
>f3:
> movl d(%rip), %eax
> shrl $4, %eax
> xorl $1, %eax
> andl $1, %eax
> movl %eax, d(%rip)
> ret
>
>
>What are the differences here? I see a few:
>
>1. Intel has dst, src ordering while AT&T has src, dst ordering.
>Neither makes any difference to me - if you have worked with a few
>assembly languages, you know that both orders work fine once you know
>which one you are using.
Just don't try to figure out what "fsub %st,%st(2)" means from the
syntax. (It subtracts %st(2) from %st, then leaves the result in
%st).
>2. Intel has no prefix on registers, AT&T has %. That would make Intel
>syntax a little nicer to write, but AT&T has less risk of mixups when
>reading - it is clear that "d" is an identifier, not a register.
>
>3. Intel has no prefix on immediate values, AT&T has $. I must admit
>that I can't see any advantage of a prefix on a numeric immediate value,
>at least not in this snippet. But I don't see a big issue.
>
>4. Intel uses extra words like "DWORD PTR" to indicate lengths, while
>AT&T puts the length indication in the mnemonic. I prefer seeing it in
>the mnemonic as being less verbose. But I would prefer the style used
>by m68k assembly, which would be "mov.l" rather than "movl". So in my
>book, neither format is ideal here.
Much of the time, Intel syntax determines the type from the label. So
if you had:
array dd 1,2,3,4
...
mov eax,array[ebx*4]
You'd load a dword (32 bits) out of the array define in the first
line, indexed by the value in ebx. IOW, basically the same as:
mov eax,dword ptr array[ebx*4]
or, for AT&T:
movl array(%ebx,4),%eax
The typing in the Intel case has the usual advantages (you'd get an
error if you tried coding "mov ax,array[ebx*4]", since the two
operands are different sizes), although given the nature of assembler,
you're often working with addresses in registers that have lost any
associated type, so the explicit typing ("dword ptr") is needed.
And since you're looking at generated code, assume it's generated in a
form convenient for the generator, not what any sane human would do…
>5. Intel has [], AT&T has (). So what?
>
>I gather that more complex addressing modes are a big ugly in AT&T
>compared to Intel - this example doesn't use such addressing modes.
>This has been described as Intel's syntax looking like an expression,
>and AT&T syntax looking like a function call.
It's modest. Instead of "[offset+reg1+(reg2*scale)]" (or the offset
placed outside of the brackets) as the general form, you have
"offset(%reg1, %reg2, scale)". In both cases various bits can be
omitted.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-13 14:23 -0800 |
| Message-ID | <o2ps9v$jos$1@dont-email.me> |
| In reply to | #99182 |
On 12/13/2016 4:02 AM, Rick C. Hodgin wrote: > FWIW, I always have been, and remain literally amazed, that anyone > who's seen AT&T syntax, and Intel's syntax, would choose AT&T's > over Intel's. Well, I can do both of them. Its fine. > I honestly believe it indicates something not right in > that person's thinking. ;^/ FWIW and imvho, this is a very odd thought. AT&T syntax is fine with me, especially if the requirements of a task include it. Think along the lines of "the team has a bunch of asm code in AT&T syntax, and do not want to mess with it wrt converting to Intel syntax". I happen to know both styles because I needed to work with MASM and GAS years ago. I thought it would build a better skill set wrt being able to use AT&T syntax, along with Intel's. FWIW, all of the asm code comprised the sensitive guts of synchronization primitives, this was before C11. Funny thing is that my compilers do not support C11 threading, however, they do support C++11 quite nicely. There are some quirks, but I would not quit any job over that non-sense. In fact, try to work around it, to at least be able to give possible workable options, to potential problems: https://groups.google.com/forum/#!topic/comp.lang.c/WPH7ed5uS4Y/discussion Now, I am mostly programming graphics... ;^) [...]
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 16:10 -0800 |
| Message-ID | <8f75df8b-1cda-48dc-8d53-5e914373a3f2@googlegroups.com> |
| In reply to | #99281 |
On Tuesday, December 13, 2016 at 5:23:21 PM UTC-5, Chris M. Thomasson wrote:
> Now, I am mostly programming graphics...
I had a thought last night watching this video:
https://www.youtube.com/watch?v=fAsaSkmbF5s&t=10m50s
If you were to take the Julia Sets for each pixel and render them off-
canvas, and then do a summation of black pixels and white pixels, and
then use that relationship for a Z axis on the X/Y plane, then you
could take the Mandelbrot shape and apply a 3D vector and render the
image that way. The ever morphing Julia Set at each pixel would
likely provide smooth shapes in most places, with some interesting
artifacts in others.
I'd be curious to see the output image.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-13 18:54 -0800 |
| Message-ID | <o2qc6s$s8r$1@dont-email.me> |
| In reply to | #99296 |
On 12/13/2016 4:10 PM, Rick C. Hodgin wrote: > On Tuesday, December 13, 2016 at 5:23:21 PM UTC-5, Chris M. Thomasson wrote: >> Now, I am mostly programming graphics... > > I had a thought last night watching this video: > > https://www.youtube.com/watch?v=fAsaSkmbF5s&t=10m50s > > If you were to take the Julia Sets for each pixel and render them off- > canvas, and then do a summation of black pixels and white pixels, and > then use that relationship for a Z axis on the X/Y plane, then you > could take the Mandelbrot shape and apply a 3D vector and render the > image that way. The ever morphing Julia Set at each pixel would > likely provide smooth shapes in most places, with some interesting > artifacts in others. > > I'd be curious to see the output image. So would I. Not sure I have heard of this before. 1. Take a random point 2. Render the Julia Set 3. Sum the inside pixels 4. Get the pixels outside by (total pixels) - (inside pixels). 5. Get a ratio based on 3 and 4, and use that at a z-axis for that point in 1. 6. goto 1 Is that what you have in mind?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-13 18:57 -0800 |
| Message-ID | <o2qcc1$s8r$2@dont-email.me> |
| In reply to | #99306 |
On 12/13/2016 6:54 PM, Chris M. Thomasson wrote: > On 12/13/2016 4:10 PM, Rick C. Hodgin wrote: >> On Tuesday, December 13, 2016 at 5:23:21 PM UTC-5, Chris M. Thomasson >> wrote: >>> Now, I am mostly programming graphics... >> >> I had a thought last night watching this video: >> >> https://www.youtube.com/watch?v=fAsaSkmbF5s&t=10m50s >> >> If you were to take the Julia Sets for each pixel and render them off- >> canvas, and then do a summation of black pixels and white pixels, and >> then use that relationship for a Z axis on the X/Y plane, then you >> could take the Mandelbrot shape and apply a 3D vector and render the >> image that way. [...] >> >> I'd be curious to see the output image. > > So would I. Not sure I have heard of this before. > > 1. Take a random point > > 2. Render the Julia Set > > 3. Sum the inside pixels > > 4. Get the pixels outside by (total pixels) - (inside pixels). > > 5. Get a ratio based on 3 and 4, and use that at a z-axis for that point > in 1. > > 6. goto 1 > > Is that what you have in mind? >> The ever morphing Julia Set at each pixel would >> likely provide smooth shapes in most places, with some interesting >> artifacts in others. It might get spiky on the borders.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-14 02:53 -0800 |
| Message-ID | <dbccd35b-8ed6-4f7e-81de-7725f077902a@googlegroups.com> |
| In reply to | #99306 |
Chris M. Thomasson wrote: > So would I. Not sure I have heard of this before. > 1. Take a random point > 2. Render the Julia Set > 3. Sum the inside pixels > 4. Get the pixels outside by (total pixels) - (inside pixels). > 5. Get a ratio based on 3 and 4, and use that at a z-axis for that point in 1. > 6. goto 1 > Is that what you have in mind? Do it for every pixel on the Mandelbrot range, and play around with 4,5. I might try +z = inside, and -z = outside, to create a Teddybearbrot or something. Don't know what it will produce. Maybe the new Thomassonbrot. :-) It would also be interesting to see other powers, and how the Teddybearbrot morphs between them. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-14 05:59 -0800 |
| Message-ID | <b648225f-4f71-44c5-9f75-9c4dc4763600@googlegroups.com> |
| In reply to | #99323 |
On Wednesday, December 14, 2016 at 5:53:52 AM UTC-5, Rick C. Hodgin wrote: > Chris M. Thomasson wrote: > > So would I. Not sure I have heard of this before. > > 1. Take a random point > > 2. Render the Julia Set > > 3. Sum the inside pixels > > 4. Get the pixels outside by (total pixels) - (inside pixels). > > 5. Get a ratio based on 3 and 4, and use that at a z-axis for that point in 1. > > 6. goto 1 > > Is that what you have in mind? > > Do it for every pixel on the Mandelbrot range, and play around with > 4,5. I might try +z = inside, and -z = outside, to create a Teddybearbrot > or something. > > Don't know what it will produce. Maybe the new Thomassonbrot. :-) > > It would also be interesting to see other powers, and how the Teddybearbrot > morphs between them. It might also become more interesting when you map the number of moves to escape (the coloring, as a Z-coordinate), or possibly the value it hones in on at the cutoff limit when it doesn't escape. Since they're all defined within a small area, it might be an interesting scaling factor. In addition, I've observed that as the Mandelbrot powers increase, it eventually winds up being a complete circle centered around the origin. I have a sneaking suspicion that this information will correlate to information about the Reimann Zeta function, that the relationship between Julia sets at each point, and the Mandelbrot set itself, will provide solutions for where the non-trivial zeros fall in the critical strip. Of course, I could be wrong. It is just a gut feeling. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-14 12:03 -0800 |
| Message-ID | <o2s8fq$u70$1@dont-email.me> |
| In reply to | #99337 |
On 12/14/2016 5:59 AM, Rick C. Hodgin wrote: > On Wednesday, December 14, 2016 at 5:53:52 AM UTC-5, Rick C. Hodgin wrote: >> Chris M. Thomasson wrote: >>> So would I. Not sure I have heard of this before. >>> 1. Take a random point >>> 2. Render the Julia Set >>> 3. Sum the inside pixels >>> 4. Get the pixels outside by (total pixels) - (inside pixels). >>> 5. Get a ratio based on 3 and 4, and use that at a z-axis for that point in 1. >>> 6. goto 1 >>> Is that what you have in mind? >> >> Do it for every pixel on the Mandelbrot range, and play around with >> 4,5. I might try +z = inside, and -z = outside, to create a Teddybearbrot >> or something. I will mess around with it when I get some more time. >> Don't know what it will produce. Maybe the new Thomassonbrot. :-) >> >> It would also be interesting to see other powers, and how the Teddybearbrot >> morphs between them. > > It might also become more interesting when you map the number of moves > to escape (the coloring, as a Z-coordinate), or possibly the value it > hones in on at the cutoff limit when it doesn't escape. Since they're > all defined within a small area, it might be an interesting scaling > factor. Using the escape count for z is well known. Here are some examples: http://m9.i.pbase.com/o6/09/60809/1/99902119.BnFRppjW.ElephantJuliareliefmap3D.jpg http://nocache-nocookies.digitalgott.com/gallery/0/190_09_05_08_4_19_38_0.jpg > In addition, I've observed that as the Mandelbrot powers increase, it > eventually winds up being a complete circle centered around the origin. It definitely tends towards a circle. I have created some 3d renderings of increasing powers of the Mandelbrot and got some interesting results: https://plus.google.com/101799841244447089430/posts/MkUVDRSt8vD https://plus.google.com/101799841244447089430/posts/YHJA9THHr2H https://plus.google.com/101799841244447089430/posts/KKAcSjFP6LA Here is a 3d Julia Set I did by taking escape count into account for each slice in the stack: https://plus.google.com/101799841244447089430/posts/MFsJr9GzcEy Here is one I did of a 3d stack of Mandelbulb slices of different powers: http://www.fractalforums.com/index.php?action=gallery;sa=view;id=17187 > I have a sneaking suspicion that this information will correlate to > information about the Reimann Zeta function, that the relationship > between Julia sets at each point, and the Mandelbrot set itself, will > provide solutions for where the non-trivial zeros fall in the critical > strip. > > Of course, I could be wrong. It is just a gut feeling. Interesting.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-14 12:22 -0800 |
| Message-ID | <o2s9ip$32s$1@dont-email.me> |
| In reply to | #99337 |
On 12/14/2016 5:59 AM, Rick C. Hodgin wrote: > On Wednesday, December 14, 2016 at 5:53:52 AM UTC-5, Rick C. Hodgin wrote: >> Chris M. Thomasson wrote: >>> So would I. Not sure I have heard of this before. >>> 1. Take a random point >>> 2. Render the Julia Set >>> 3. Sum the inside pixels >>> 4. Get the pixels outside by (total pixels) - (inside pixels). >>> 5. Get a ratio based on 3 and 4, and use that at a z-axis for that point in 1. >>> 6. goto 1 >>> Is that what you have in mind? >> >> Do it for every pixel on the Mandelbrot range, and play around with >> 4,5. I might try +z = inside, and -z = outside, to create a Teddybearbrot >> or something. I am thinking about just mapping the z value to a color in a 2d rendering at first. This would give a good idea as to what the 3d version would look like. [...]
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-14 17:09 -0800 |
| Message-ID | <o2sqdj$t4s$1@dont-email.me> |
| In reply to | #99404 |
On 12/14/2016 12:22 PM, Chris M. Thomasson wrote: > On 12/14/2016 5:59 AM, Rick C. Hodgin wrote: >> On Wednesday, December 14, 2016 at 5:53:52 AM UTC-5, Rick C. Hodgin >> wrote: >>> Chris M. Thomasson wrote: >>>> So would I. Not sure I have heard of this before. >>>> 1. Take a random point >>>> 2. Render the Julia Set >>>> 3. Sum the inside pixels >>>> 4. Get the pixels outside by (total pixels) - (inside pixels). >>>> 5. Get a ratio based on 3 and 4, and use that at a z-axis for that >>>> point in 1. >>>> 6. goto 1 >>>> Is that what you have in mind? >>> >>> Do it for every pixel on the Mandelbrot range, and play around with >>> 4,5. I might try +z = inside, and -z = outside, to create a >>> Teddybearbrot >>> or something. > > I am thinking about just mapping the z value to a color in a 2d > rendering at first. This would give a good idea as to what the 3d > version would look like. > > [...] So far it looks like a very smoothly shaded Mandelbrot set. This smooth shading implies smooth z axes. I am working on some 2d renderings.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-14 18:37 -0800 |
| Message-ID | <o2svin$92h$1@dont-email.me> |
| In reply to | #99432 |
On 12/14/2016 5:09 PM, Chris M. Thomasson wrote: > On 12/14/2016 12:22 PM, Chris M. Thomasson wrote: >> On 12/14/2016 5:59 AM, Rick C. Hodgin wrote: >>> On Wednesday, December 14, 2016 at 5:53:52 AM UTC-5, Rick C. Hodgin >>> wrote: >>>> Chris M. Thomasson wrote: >>>>> So would I. Not sure I have heard of this before. >>>>> 1. Take a random point >>>>> 2. Render the Julia Set >>>>> 3. Sum the inside pixels >>>>> 4. Get the pixels outside by (total pixels) - (inside pixels). >>>>> 5. Get a ratio based on 3 and 4, and use that at a z-axis for that >>>>> point in 1. >>>>> 6. goto 1 >>>>> Is that what you have in mind? >>>> >>>> Do it for every pixel on the Mandelbrot range, and play around with >>>> 4,5. I might try +z = inside, and -z = outside, to create a >>>> Teddybearbrot >>>> or something. >> >> I am thinking about just mapping the z value to a color in a 2d >> rendering at first. This would give a good idea as to what the 3d >> version would look like. >> >> [...] > > So far it looks like a very smoothly shaded Mandelbrot set. This smooth > shading implies smooth z axes. I am working on some 2d renderings. Here is a link to a rendering Rick: https://plus.google.com/101799841244447089430/posts/8GJEwV4rjBR The color is smooth, and will produce a smooth z-axis. Now, the interesting part would be to zoom into the border. :^)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-13 05:25 -0800 |
| Message-ID | <b6938dc0-cee1-4cf0-b1f0-b91dc10ca071@googlegroups.com> |
| In reply to | #99077 |
On Monday, December 12, 2016 at 4:49:32 PM UTC, Ben Bacarisse wrote: > > If Swift were alive today, he wouldn't have to write about wars over > which end of the egg to open in order to illustrate the absurd passions > about trivia that we are capable of. He'd be spoilt for choice. > Mrs Rees was my history teacher, and an extremely good historian who also ran the wargaming society. (We boys took it down a fantasy gaming direction she disapproved of, but that's another story). Once, she was teaching 16th century, and said, "Of course, we don't carry on like that today. We don't fight over religion". I think the date was 1980.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-12 07:31 -0800 |
| Message-ID | <2901cccb-1bb3-49e8-b3d0-b0b127ac6b64@googlegroups.com> |
| In reply to | #99032 |
On Monday, December 12, 2016 at 5:15:35 AM UTC-6, Rick C. Hodgin wrote: > What's the purpose of the % everywhere? It looks like AT&T syntax > was designed explicitly to make it easier for assemblers to parse the > source code, rather than to support the needs of human developers. Given that meany features which are useful for humans offer no benefit to code generators and vice versa, I would think that it would be helpful for development systems to define distinct forms of assembly language for the different purposes. Humans may benefit from having mnemonics for the various opcodes, but code generators could just as easily output numeric codes [e.g. "4,9,foo,3" meaning "Using format #4, generate code where the opcode is 9, the first operand is "foo", and the second operand is 3"]; since an assembler which works off the numeric format could be smaller, leaner, and faster than one which needs to know all the different opcodes and their associated mnemonics, a development system that used such an assembler could produce machine code more quickly than one which has to go through a more human-readable form. In cases where a human might need to read the code, a translation utility could output a human-readable representation.
[toc] | [prev] | [next] | [standalone]
Page 5 of 18 — ← Prev page 1 … 3 4 [5] 6 7 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web