Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #73976 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2015-10-27 09:52 -0700 |
| Last post | 2015-10-31 01:14 -0700 |
| Articles | 20 on this page of 174 — 20 participants |
Back to article view | Back to comp.lang.c
Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 09:52 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:06 -0700
Re: Problem with the function that should display new letter John Gordon <gordon@panix.com> - 2015-10-27 17:16 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:28 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:09 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:12 -0700
Re: Problem with the function that should display new letter Barry Schwarz <schwarzb@dqel.com> - 2015-10-27 13:12 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-27 13:23 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-27 13:49 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-27 21:27 +0000
Re: Problem with the function that should display new letter Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-27 18:00 -0400
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 02:53 +0000
Re: Problem with the function that should display new letter Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 00:43 -0500
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 06:08 +0000
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 08:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 09:26 +0100
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 08:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 10:40 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-28 06:44 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-28 06:35 -0700
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 13:40 -0400
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 13:47 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:38 -0700
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 16:46 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:39 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 18:20 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:36 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 12:09 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:51 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-27 19:25 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 12:27 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-28 10:07 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-28 00:50 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-28 21:04 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-28 01:13 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 10:40 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:02 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-28 11:28 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 11:57 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 12:53 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-28 13:33 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 08:35 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 10:59 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:04 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 11:38 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:43 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 12:10 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 12:58 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 13:55 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 14:02 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 15:01 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 15:44 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:22 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 16:26 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:44 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 18:45 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 19:26 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 20:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 22:59 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 22:48 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 01:14 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 01:07 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 14:07 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 13:57 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 16:22 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-29 08:38 -0700
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 17:25 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-29 12:46 -0700
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:03 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 19:19 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:54 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-30 12:20 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 21:36 +0000
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-30 10:47 +1300
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 22:25 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:59 +0100
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 10:07 +0100
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 16:25 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:01 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-28 09:50 -0700
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 21:57 +0000
Re: Problem with the function that should display new letter Geoff <geoff@invalid.invalid> - 2015-10-28 18:25 -0700
Re: Problem with the function that should display new letter Geoff <geoff@invalid.invalid> - 2015-10-28 18:23 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 01:44 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-28 07:07 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 07:07 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 09:08 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 14:29 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 16:10 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 20:27 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-31 12:40 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 02:16 -0800
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 03:36 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 10:46 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 03:56 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:00 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:02 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:05 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:14 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:14 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 11:26 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:26 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 05:29 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 09:23 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 07:44 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 11:39 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 09:52 -0700
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-29 16:02 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 09:56 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 13:41 -0400
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 17:46 +0000
Re: Problem with the function that should display new letter Udyant Wig <udyantw@gmail.com> - 2015-10-30 00:14 +0530
Re: Problem with the function that should display new letter raltbos@xs4all.nl (Richard Bos) - 2015-10-29 19:30 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 22:08 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 22:28 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:10 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-30 08:56 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 13:18 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-30 09:11 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:21 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:04 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:11 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:19 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:24 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 05:26 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-29 08:31 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 09:42 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 08:31 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 10:17 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 17:36 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:18 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 08:36 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 08:38 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 02:26 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:32 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 13:39 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 03:59 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 11:18 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:24 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-30 14:18 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:34 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 13:39 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:57 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 09:06 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 08:49 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 10:18 -0700
Re: Problem with the function that should display new letter Barry Schwarz <schwarzb@dqel.com> - 2015-10-29 11:48 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:23 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:42 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:13 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 10:17 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 10:23 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:39 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:45 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 13:55 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 07:05 -0700
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-30 23:29 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 01:14 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:02 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 18:05 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 23:46 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-11-01 08:46 -0800
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 23:43 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-11-01 16:05 -0800
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 21:41 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 22:46 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-31 18:22 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 23:57 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:20 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-31 13:38 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-31 11:28 -0700
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 00:06 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:58 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-31 01:14 -0700
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-29 01:14 +0100 |
| Message-ID | <n0ro9m$ohv$1@dont-email.me> |
| In reply to | #74114 |
On 28/10/15 23:48, Bartc wrote: > On 28/10/2015 21:59, David Brown wrote: >> On 28/10/15 17:22, Bartc wrote: > >>> Except the dividing line is fuzzy. [Between what is topical and not] >>> >>> For example, even when I don't want to use C at all, I can't get away >>> from it: >>> >>> * I need to use gcc in order to link, if I want to use main(argc,argv), >>> the subject of this subthread. >> >> MSVC will, AFAIUI, give argc and argv (and envp) to main when you make a >> console application. And if you are not using C or C++, then the >> concept of "main(argc, argv)" doesn't make sense anyway - you use >> whatever method is suitable for the language in question if you want to >> access command-line parameters. > > From what I can make out, Windows only ever calls a raw entry point > equivalent to int main(void). 'int main(int argc...)' and 'WinMain(...)' > are just conventions supported by C compilers and their > platform-specific support. The details of how this is all implemented is normally irrelevant. You are obsessed by the idea that C is tied to *nix, and that Windows is special. It is not. On any system, there can be dozens of ways for things to happen before your code starts at main(argc, argv). Among the tasks needed are setting up memory sections and stacks, initialising data sections, clearing the bss, linking up external libraries, and calling any pre-main initialisation (using extensions to C, library initialisations, C++ constructors, etc.). Some of this will be handled by the "OS", some by helper programs such as a link-loader, and some by code that is compiled into the executable itself. From the C viewpoint, it makes no difference. From the assembly viewpoint, some of this might be relevant - but there is no fundamental difference between Windows and other hosted systems. There is merely differences in the details - and that can vary as much between *nix systems (or the same system on different processors, or the same system with different types of binary files) as between Windows and other systems. > > You don't get them if you go step outside the normal tools (this came up > when I wanted to generate apps with 100% ASM and using standalone > linkers, but still using the documented C library functions. > > Took a while to sort out, not helped by experts insisting that Windows > worked a different way. It's not a problem now; what I miss more is > gcc's '__chkstk()' routine, but I think I can recreate that.) > >>> * If I want to communicate with the OS, the API is in C terms (and >>> clearly designed to be called from C). >> >> Windows API uses Pascal calling conventions, not C-style conventions, > > On Win64 everything uses the same convention. (Incompatible with > Linux64, obviously...) True. > >>> * If I want find out exactly what size a 'WORD' is in that API, or >>> exactly how a particular struct is laid out, I need to write C code to >>> do so. >> >> Or you could look in the documentation. Or you can use any other >> language that has support for those structs and APIs. > > That doesn't really work. Eg it tells you T is defined as U which is > defined as V, eventually arriving at a C type, but one which you still > have to actually use sizeof() on to double-check. > Why? On the systems I use, I documentation tends to be accurate. > When it comes to structs, then you have all that in spades, plus padding > and rounding and alignment to try and double guess. It's easier to just > experiment. And these can vary between 32-bits and 64-bits as well. I usually aim to write correct code, rather than work on a hit-and-miss development system. Maybe I have access to better quality code than you do, but I wouldn't want to use something where the API was so convoluted and obscure that I couldn't figure out the sizes of the data without experiment. > >>> * If I want to use a third party library, then more than likely, the API >>> will again be in C, it will come C header files that I have to make >>> sense of. >> >> Many will, but others use different languages. And if it is in C, it is >> generally easy to write support for the library in other languages. It >> would be a different matter entirely if the API were in Java, C#, >> Python, etc. - then you are pretty much stuck with the library's choice >> of language. C gives a very convenient and clear common base, and >> except for variadic functions like printf, it's generally a simple >> matter to interface to other languages. > > Yes, I know. I'm not complaining; it could be a lot worse! (Eg. C++). > The point is C comes into it again even if I'm trying not to program in it. > >>> * Sometimes, I need code to run on a target that my own language doesn't >>> support (in the form of generating native ASM). Then I have to generate >>> C code, considerable amounts of it sometimes. >> >> If you have such a dislike of C, you could always pick a different >> intermediary language. It would be more work, but it's your choice. > > There isn't anything else, apart from C++. Other intermediate codes are > too high level or too big and complex; it would be easier just to > generate the native code. > You could use Forth...
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-29 01:07 +0000 |
| Message-ID | <n0rrd7$gh$1@dont-email.me> |
| In reply to | #74123 |
On 29/10/2015 00:14, David Brown wrote: > On 28/10/15 23:48, Bartc wrote: >> On 28/10/2015 21:59, David Brown wrote: >>> Or you could look in the documentation. Or you can use any other >>> language that has support for those structs and APIs. >> >> That doesn't really work. Eg it tells you T is defined as U which is >> defined as V, eventually arriving at a C type, but one which you still >> have to actually use sizeof() on to double-check. >> > > Why? > > On the systems I use, I documentation tends to be accurate. > >> When it comes to structs, then you have all that in spades, plus padding >> and rounding and alignment to try and double guess. It's easier to just >> experiment. And these can vary between 32-bits and 64-bits as well. > > I usually aim to write correct code, rather than work on a hit-and-miss > development system. Maybe I have access to better quality code than you > do, but I wouldn't want to use something where the API was so convoluted > and obscure that I couldn't figure out the sizes of the data without > experiment. If you work exclusively in C, you might not see the problem so much, and you don't usually need to know the size and layout of a struct. You can also just compile for a 32, 64 or whatever bit target, and the same code will still work, but with a different struct size and set of offsets. You can also have different bits of code have different struct packing methods. But it can be a lot of work to try and duplicate the exact layout elsewhere, and make sure it still works on different targets. (In fact I haven't fully solved the problem and each duplicate struct definition has to be messily customised to match what will happen in C.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-29 14:07 +0100 |
| Message-ID | <n0t5i9$m6a$1@dont-email.me> |
| In reply to | #74127 |
On 29/10/15 02:07, Bartc wrote: > On 29/10/2015 00:14, David Brown wrote: >> On 28/10/15 23:48, Bartc wrote: >>> On 28/10/2015 21:59, David Brown wrote: > >>>> Or you could look in the documentation. Or you can use any other >>>> language that has support for those structs and APIs. >>> >>> That doesn't really work. Eg it tells you T is defined as U which is >>> defined as V, eventually arriving at a C type, but one which you still >>> have to actually use sizeof() on to double-check. >>> >> >> Why? >> >> On the systems I use, I documentation tends to be accurate. >> >>> When it comes to structs, then you have all that in spades, plus padding >>> and rounding and alignment to try and double guess. It's easier to just >>> experiment. And these can vary between 32-bits and 64-bits as well. >> >> I usually aim to write correct code, rather than work on a hit-and-miss >> development system. Maybe I have access to better quality code than you >> do, but I wouldn't want to use something where the API was so convoluted >> and obscure that I couldn't figure out the sizes of the data without >> experiment. > > If you work exclusively in C, you might not see the problem so much, and > you don't usually need to know the size and layout of a struct. I don't work exclusively in C, and I don't see any problem. Sometimes I work with assembly, sometimes I work with Python, and sometimes I work with a variety of different target types with different int sizes, alignment requirements, and different endianness. I have no problem passing data between all these, whether it be as structs or other binary formats. It is simply a matter of being accurate about your sizes and layouts - /designing/ things correctly, and /documenting/ them correctly, rather than using guesswork and trial-and-error as you are suggesting. > > You can also just compile for a 32, 64 or whatever bit target, and the > same code will still work, but with a different struct size and set of > offsets. You can also have different bits of code have different struct > packing methods. That never happens in my code. It does not happen, because I use appropriate fixed size types, and explicit padding - I know exactly what I am getting, and I know it will work on all appropriate targets (usually that is only one or two targets for any given bit of code, but it can vary from 8-bit to 64-bit processors). And even though I know I have written the code correctly, I also add static assertions to ensure that no mistakes are made and the layouts are precisely what they should be. > > But it can be a lot of work to try and duplicate the exact layout > elsewhere, and make sure it still works on different targets. (In fact I > haven't fully solved the problem and each duplicate struct definition > has to be messily customised to match what will happen in C.) > It is not a lot of work. It is just a matter of doing things correctly. (If I wanted something that would also work on a 36-bit dinosaur with mixed-endian ordering, that would be a different matter. I aim for practical, realistic and appropriate portability, rather than having to support any hypothetical conforming C system.)
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-29 13:57 +0000 |
| Message-ID | <n0t8go$1sb$1@dont-email.me> |
| In reply to | #74166 |
On 29/10/2015 13:07, David Brown wrote:
> On 29/10/15 02:07, Bartc wrote:
>> If you work exclusively in C, you might not see the problem so much, and
>> you don't usually need to know the size and layout of a struct.
>
> I don't work exclusively in C, and I don't see any problem. Sometimes I
> work with assembly, sometimes I work with Python, and sometimes I work
> with a variety of different target types
>> But it can be a lot of work to try and duplicate the exact layout
>> elsewhere, and make sure it still works on different targets. (In fact I
>> haven't fully solved the problem and each duplicate struct definition
>> has to be messily customised to match what will happen in C.)
>
> It is not a lot of work. It is just a matter of doing things correctly.
>
> (If I wanted something that would also work on a 36-bit dinosaur with
> mixed-endian ordering, that would be a different matter. I aim for
> practical, realistic and appropriate portability, rather than having to
> support any hypothetical conforming C system.)
Here's a typical example. I want to have the equivalent of getch(), but
that's not often available these days. Linux has its own workaround
which I've used. Under Windows, it can involve code like this (getch()
is written on top of this function):
#include <windows.h>
INPUT_RECORD lastkey;
int os_getchx_c(void) {
....
if (lastkey.Event.KeyEvent.wRepeatCount==0) {
do {
count=0;
ReadConsoleInput(hconsolein,&lastkey,1,(LPDWORD)&count);
} while (!(lastkey.EventType==1 &&
lastkey.Event.KeyEvent.bKeyDown==1));
}
....
--lastkey.Event.KeyEvent.wRepeatCount;
charcode = lastkey.Event.KeyEvent.uChar.AsciiChar;
keycode = lastkey.Event.KeyEvent.wVirtualKeyCode & 255;
....
}
In C, it's easy: you just include windows.h, and it includes everything
needed, which also takes care of the special struct packing rules used
by Windows.
Now you want to write this code in a language where windows.h is not
available. Then it's a lot of work including duplicating the
INPUT_RECORD struct above. MSDN says it's this:
typedef struct _INPUT_RECORD {
WORD EventType;
union {
KEY_EVENT_RECORD KeyEvent;
MOUSE_EVENT_RECORD MouseEvent;
WINDOW_BUFFER_SIZE_RECORD WindowBufferSizeEvent;
MENU_EVENT_RECORD MenuEvent;
FOCUS_EVENT_RECORD FocusEvent;
} Event;
} INPUT_RECORD;
We're interested in key events, and that struct is:
typedef struct _KEY_EVENT_RECORD {
BOOL bKeyDown;
WORD wRepeatCount;
WORD wVirtualKeyCode;
WORD wVirtualScanCode;
union {
WCHAR UnicodeChar;
CHAR AsciiChar;
} uChar;
DWORD dwControlKeyState;
} KEY_EVENT_RECORD;
So, I'm interested in what your approach would be to extracting the
relevant data from that lot.
(In ASM, you'd probably want a lot of offsets defined for each field of
interest. In Python, I think that has a struct-packing library, but even
there it needs to be told what the offsets are. Any solution also needs
to work with both 32 and 64 bit targets. (For INPUT_RECORD, there is no
difference, but sometimes there can be.))
(This is my version of the above struct, expressed without using C:
http://pastebin.com/x7EWQsd3.
That also shows what it looks like when converted back to C!
However this just illustrates what I'm trying to achieve; the important
bit is how to get there. And it's fiddly, painstaking work that can
include experimentation and testing to make sure both my input_record
and Windows' INPUT_RECORD are compatible, even tough my version has been
simplified (fewer event types, less nesting, and saner field names).)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-29 16:22 +0100 |
| Message-ID | <n0tdg4$nsi$1@dont-email.me> |
| In reply to | #74171 |
On 29/10/15 14:57, Bartc wrote:
> On 29/10/2015 13:07, David Brown wrote:
>> On 29/10/15 02:07, Bartc wrote:
>
>>> If you work exclusively in C, you might not see the problem so much, and
>>> you don't usually need to know the size and layout of a struct.
>>
>> I don't work exclusively in C, and I don't see any problem. Sometimes I
>> work with assembly, sometimes I work with Python, and sometimes I work
>> with a variety of different target types
>
>>> But it can be a lot of work to try and duplicate the exact layout
>>> elsewhere, and make sure it still works on different targets. (In fact I
>>> haven't fully solved the problem and each duplicate struct definition
>>> has to be messily customised to match what will happen in C.)
>>
>> It is not a lot of work. It is just a matter of doing things correctly.
>>
>> (If I wanted something that would also work on a 36-bit dinosaur with
>> mixed-endian ordering, that would be a different matter. I aim for
>> practical, realistic and appropriate portability, rather than having to
>> support any hypothetical conforming C system.)
>
> Here's a typical example. I want to have the equivalent of getch(), but
> that's not often available these days. Linux has its own workaround
> which I've used. Under Windows, it can involve code like this (getch()
> is written on top of this function):
>
> #include <windows.h>
>
> INPUT_RECORD lastkey;
>
> int os_getchx_c(void) {
> ....
> if (lastkey.Event.KeyEvent.wRepeatCount==0) {
> do {
> count=0;
> ReadConsoleInput(hconsolein,&lastkey,1,(LPDWORD)&count);
> } while (!(lastkey.EventType==1 &&
> lastkey.Event.KeyEvent.bKeyDown==1));
> }
> ....
> --lastkey.Event.KeyEvent.wRepeatCount;
>
> charcode = lastkey.Event.KeyEvent.uChar.AsciiChar;
> keycode = lastkey.Event.KeyEvent.wVirtualKeyCode & 255;
> ....
> }
>
> In C, it's easy: you just include windows.h, and it includes everything
> needed, which also takes care of the special struct packing rules used
> by Windows.
>
> Now you want to write this code in a language where windows.h is not
> available.
I don't quite see /why/ you would want to do that - after all, most
languages and/or gui libraries will have abstractions to provide such
features already. It is also not uncommon to have automatic translation
of C headers into other languages. (And if you are writing the
libraries or languages here, then C would be the typical choice for the
implementation. Most code in most C libraries is written in C.)
That leaves assembly - and writing raw Windows code in assembly is an
exercise in mind-damaging masochism, and almost invariably results in
slower code than using a decent C compiler.
But okay, you want to figure out the offsets in this structure for use
in assembly, and you want to do it manually rather than with a simple
automated tool.
Step one is the same as always - understand the types involved, their
sizes, and their alignments. I don't know exactly what they would be in
Windows - I have no interest in such low-level programming on that
platform. But it doesn't take more than a very quick google to get a list.
> Then it's a lot of work including duplicating the
> INPUT_RECORD struct above. MSDN says it's this:
>
> typedef struct _INPUT_RECORD {
> WORD EventType;
Word is 16-bit
> union {
> KEY_EVENT_RECORD KeyEvent;
> MOUSE_EVENT_RECORD MouseEvent;
> WINDOW_BUFFER_SIZE_RECORD WindowBufferSizeEvent;
> MENU_EVENT_RECORD MenuEvent;
> FOCUS_EVENT_RECORD FocusEvent;
> } Event;
You need the details of these types if you want to find the full size of
an INPUT_RECORD. But the alignment will be 32-bit to match the BOOL in
KEY_EVENT_RECORD, unless one of the other union fields has a higher
alignment requirement.
> } INPUT_RECORD;
>
> We're interested in key events, and that struct is:
>
> typedef struct _KEY_EVENT_RECORD {
> BOOL bKeyDown;
32-bit (BOOL is an "int", which is 32-bit on Win32 and Win64)
> WORD wRepeatCount;
Word is 16-bit
> WORD wVirtualKeyCode;
Word is 16-bit
> WORD wVirtualScanCode;
Word is 16-bit
> union {
> WCHAR UnicodeChar;
> CHAR AsciiChar;
> } uChar;
WCHAR is 16-bit
> DWORD dwControlKeyState;
32-bit
> } KEY_EVENT_RECORD;
So if you need to access wVirtualScanCode, for example, it is a 16-bit
unsigned integer at offset 12 bytes from the beginning of the structure.
>
> So, I'm interested in what your approach would be to extracting the
> relevant data from that lot.
Just write it down and add up the numbers. It's not even /remotely/
difficult. If you find this too hard, trying taking your socks and
shoes off so that you can count to 20.
>
> (In ASM, you'd probably want a lot of offsets defined for each field of
> interest. In Python, I think that has a struct-packing library, but even
> there it needs to be told what the offsets are. Any solution also needs
> to work with both 32 and 64 bit targets. (For INPUT_RECORD, there is no
> difference, but sometimes there can be.))
Python does not need offsets when using the struct library - it is
perfectly capable of doing the basic arithmetic needed to calculate them.
Stick to size-specific types and there are almost no issues when mixing
32-bit and 64-bit data. At worst, your pointers will mean there are two
different sizes involved - but that just means you have to do the same
simple sums twice rather than once. Windows API may use ugly,
non-standard typenames, but at least they all have specific fixed sizes.
>
> (This is my version of the above struct, expressed without using C:
> http://pastebin.com/x7EWQsd3.
You have arbitrarily changed the type names from windows into your own
type names (with wt_ first, and less ugly lower-case characters). Then
you removed the punctuation. Other than that, your code "expressed
without using C" is identical to the C code. It should be a small
matter to write a utility that does the conversion from Windows.h to
your own "C without punctuation characters" language. The only
challenge is padding - which is simple and obvious. (Personally, I
always prefer to be explicit about any padding in my own structures.)
>
> That also shows what it looks like when converted back to C!
You have replaced one set of non-standard type names with another set of
non-standard type names, removed the silly systems Hungarian notation,
and flattened the type (which is convenient for the case of key events,
less so if you want to handle other types of input events). This is all
completely trivial, easy to do manually and easy to automate.
>
> However this just illustrates what I'm trying to achieve; the important
> bit is how to get there. And it's fiddly, painstaking work that can
> include experimentation and testing to make sure both my input_record
> and Windows' INPUT_RECORD are compatible, even tough my version has been
> simplified (fewer event types, less nesting, and saner field names).)
>
I'm sorry, but I completely fail to see the problem here. Converting
between Windows struct definitions and your own language seems
absolutely trivial to me.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-29 08:38 -0700 |
| Message-ID | <3fdd2ab1-e426-4710-88c6-c4b2aea75746@googlegroups.com> |
| In reply to | #74173 |
On Thursday, October 29, 2015 at 10:23:10 AM UTC-5, David Brown wrote:
> Just write it down and add up the numbers. It's not even /remotely/
> difficult. If you find this too hard, trying taking your socks and
> shoes off so that you can count to 20.
IMHO, there should be a standardized way of identifying compilers where that
approach is guaranteed to work, versus those which might get more creative.
For example, given
struct ShortCoord {
int16_t x,y;
};
struct BasicEntry {
uint16_t color;
ShortCoord location;
};
some compilers might treat struct BasicEntry as three 16-bit half-words but
others might treat it as two 32-bit words and I don't think there's any
Standard means of asking a compiler whether it always uses consistent rules
regarding alignment even though such issues are absolutely vital for any
kind of data which will be shared with code produced with a different
compiler.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-29 17:25 +0100 |
| Message-ID | <n0th54$7gv$1@dont-email.me> |
| In reply to | #74176 |
On 29/10/15 16:38, supercat@casperkitty.com wrote:
> On Thursday, October 29, 2015 at 10:23:10 AM UTC-5, David Brown wrote:
>> Just write it down and add up the numbers. It's not even /remotely/
>> difficult. If you find this too hard, trying taking your socks and
>> shoes off so that you can count to 20.
>
> IMHO, there should be a standardized way of identifying compilers where that
> approach is guaranteed to work, versus those which might get more creative.
> For example, given
>
> struct ShortCoord {
> int16_t x,y;
> };
> struct BasicEntry {
> uint16_t color;
> ShortCoord location;
> };
>
> some compilers might treat struct BasicEntry as three 16-bit half-words but
> others might treat it as two 32-bit words and I don't think there's any
> Standard means of asking a compiler whether it always uses consistent rules
> regarding alignment even though such issues are absolutely vital for any
> kind of data which will be shared with code produced with a different
> compiler.
>
From §6.7.2.1:
14
Each non-bit-field member of a structure or union object is aligned in
an implementation-defined manner appropriate to its type.
15
Within a structure object, the non-bit-field members and the units in
which bit-fields reside have addresses that increase in the order in
which they are declared. A pointer to a structure object, suitably
converted, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides), and vice versa. There
may be unnamed padding within a structure object, but not at its beginning.
The compiler doesn't get to turn BasicEntry into anything other than
three 16-bit fields. It is conceivable (though unlikely) that the
compiler would want 32-bit alignment for the 16-bit types, if it is
documented (since it is implementation-defined). But the structures are
fixed and consistent.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-29 12:46 -0700 |
| Message-ID | <f33a2165-f704-457e-b930-954269cde2f4@googlegroups.com> |
| In reply to | #74182 |
On Thursday, October 29, 2015 at 11:25:32 AM UTC-5, David Brown wrote: > From §6.7.2.1: > > 14 > Each non-bit-field member of a structure or union object is aligned in > an implementation-defined manner appropriate to its type. > > 15 > Within a structure object, the non-bit-field members and the units in > which bit-fields reside have addresses that increase in the order in > which they are declared. A pointer to a structure object, suitably > converted, points to its initial member (or if that member is a > bit-field, then to the unit in which it resides), and vice versa. There > may be unnamed padding within a structure object, but not at its beginning. > The compiler doesn't get to turn BasicEntry into anything other than > three 16-bit fields. It is conceivable (though unlikely) that the > compiler would want 32-bit alignment for the 16-bit types, if it is > documented (since it is implementation-defined). But the structures are > fixed and consistent. Does anything require that implementations document their manner of laying out structures? The cited text seems to allow compilers to add as much or as little padding as they see fit, for any reason or no reason, provided only that structures with perfectly-matching initial sequences have those sequences laid out the same way. Forcing four-byte alignment on the inner struct would greatly improve the efficiency of a lot of code which passed around values of that type. It will also greatly degrade efficiency in some other situations. I wish C would define standardized directives to control such issues; even if some compilers couldn't support certain kinds of alignment requests and would have to refuse compilation of code that needed them, that would be better than having compilers silently choose different layouts. Further, even on systems that would normally receive no benefit from aligning on anything other than byte boundaries, having options to align things more coarsely would make it easier for such systems to share data with other systems that had stricter requirements.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-30 09:03 +0100 |
| Message-ID | <n0v84t$t07$1@dont-email.me> |
| In reply to | #74197 |
On 29/10/15 20:46, supercat@casperkitty.com wrote:
> On Thursday, October 29, 2015 at 11:25:32 AM UTC-5, David Brown wrote:
>> From §6.7.2.1:
>>
>> 14
>> Each non-bit-field member of a structure or union object is aligned in
>> an implementation-defined manner appropriate to its type.
>>
>> 15
>> Within a structure object, the non-bit-field members and the units in
>> which bit-fields reside have addresses that increase in the order in
>> which they are declared. A pointer to a structure object, suitably
>> converted, points to its initial member (or if that member is a
>> bit-field, then to the unit in which it resides), and vice versa. There
>> may be unnamed padding within a structure object, but not at its beginning.
>
>> The compiler doesn't get to turn BasicEntry into anything other than
>> three 16-bit fields. It is conceivable (though unlikely) that the
>> compiler would want 32-bit alignment for the 16-bit types, if it is
>> documented (since it is implementation-defined). But the structures are
>> fixed and consistent.
>
> Does anything require that implementations document their manner of laying
> out structures? The cited text seems to allow compilers to add as much or
> as little padding as they see fit, for any reason or no reason, provided
> only that structures with perfectly-matching initial sequences have those
> sequences laid out the same way.
>
I don't see it that way. (Perhaps one of the other "language lawyers"
will give us some pointers here - there are many in this group with a
lot more experience of the technicalities of the standards than me.) As
I read these paragraphs, I see that the alignment and padding must be
/appropriate/ to the types. Alignment (and therefore padding) for
fields in the struct cannot be less than you get for single items of
that type, since you are allowed to make pointers to the fields in an
instance of the struct.
I read "aligned in an implementation-defined manner appropriate to its
type" to mean the same alignment for fields as for separate objects of
the same type, since that is "appropriate", but that the exact alignment
there is implementation-dependent. (A 32-bit type would have 4-byte
alignment on most 32-bit systems, but 2-byte alignment on a 16-bit
system, and so on.)
Padding at the end of the struct is done so that in an array of structs,
each element is properly aligned.
There is /some/ wiggle-room for additional padding by the implementation
(it is mentioned in J.3.9), but I would certainly expect it to be
properly documented if it is different from normal alignment for the
target.
> Forcing four-byte alignment on the inner struct would greatly improve the
> efficiency of a lot of code which passed around values of that type. It
> will also greatly degrade efficiency in some other situations. I wish C
> would define standardized directives to control such issues;
You mean like _Alignas ?
> even if some
> compilers couldn't support certain kinds of alignment requests and would
> have to refuse compilation of code that needed them, that would be better
> than having compilers silently choose different layouts. Further, even on
> systems that would normally receive no benefit from aligning on anything
> other than byte boundaries, having options to align things more coarsely
> would make it easier for such systems to share data with other systems that
> had stricter requirements.
>
You mean like manually adding padding?
alignas(uint32_t)
struct {
uint8_t a;
uint8_t padding[3];
uint32_t b;
} s;
static_assert(sizeof(s) == 8, "The structure is the wrong size");
That is all standard C11, and it will compile correctly on any (I think)
target that supports uint8_t and uint32_t, with the same layout
regardless of packing or standard alignments for the target. (b may
have different endianness on different targets, of course.) And if a
compiler cannot give you a struct with the expected arrangement, you
will get a compile-time error.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-29 19:19 +0000 |
| Message-ID | <n0trc1$kim$1@dont-email.me> |
| In reply to | #74173 |
On 29/10/2015 15:22, David Brown wrote:
> On 29/10/15 14:57, Bartc wrote:
>> Here's a typical example. I want to have the equivalent of getch(), but
>> #include <windows.h>
>>
>> INPUT_RECORD lastkey;
>> In C, it's easy: you just include windows.h, and it includes everything
>> needed, which also takes care of the special struct packing rules used
>> by Windows.
>>
>> Now you want to write this code in a language where windows.h is not
>> available.
> But okay, you want to figure out the offsets in this structure for use
> in assembly, and you want to do it manually rather than with a simple
> automated tool.
> Step one is the same as always - understand the types involved, their
> sizes, and their alignments.
In the case of Win32 types, the padding and rounding rules for structs
might not match the defaults of the C compiler being used. You will
anyway need to know the padding and alignment used by the C compiler.
That is not always obvious (what /is/ the alignment used by C compiler
'X'? I don't know). Neither do you know if a 'pragma pack(N)' is in
effect or has been assumed.
As I said, it's trial and error.
>> So, I'm interested in what your approach would be to extracting the
>> relevant data from that lot.
>
> Just write it down and add up the numbers. It's not even /remotely/
> difficult. If you find this too hard, trying taking your socks and
> shoes off so that you can count to 20.
> I'm sorry, but I completely fail to see the problem here. Converting
> between Windows struct definitions and your own language seems
> absolutely trivial to me.
The problem is that there are tens of thousands of lines of this stuff
in the Windows headers. Every new function, you've got dozens of new
entities to translate (structs and types and messages and constants). I
don't know an automatic that can do that without writing half a C compiler.
(With Python of course, it apparently knows all the answers. You
presumably just feed it the INPUT_RECORD definition, and it magically
understands the C code, and knows the meanings of all the macros and
typedefs that have been used.)
I'm simply saying I need to know C well and/or use C to derive all this
information, even if my intention is to code in a different language.
And sometimes even the 'trick' of adding up the offsets is not
practical. I've lost the original C of this example, but the version I
ended up using in my language is this; notice the size of the first member:
type jpeg_properties = record
[19966]byte padding # skip complicated jpeg stuff
int16 jfif_app0_units # 19966
int16 jfif_app0_xdensity # 19968
int16 jfif_app0_ydensity # 19970
ref char jpeg_comment # 19972
int32 jpeg_comment_size # 19976
int32 padding2 # 19980, total size 19984
end
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-30 09:54 +0100 |
| Message-ID | <n0vb4l$6ab$1@dont-email.me> |
| In reply to | #74193 |
On 29/10/15 20:19, Bartc wrote:
> On 29/10/2015 15:22, David Brown wrote:
>> On 29/10/15 14:57, Bartc wrote:
>
>>> Here's a typical example. I want to have the equivalent of getch(), but
>
>>> #include <windows.h>
>>>
>>> INPUT_RECORD lastkey;
>
>>> In C, it's easy: you just include windows.h, and it includes everything
>>> needed, which also takes care of the special struct packing rules used
>>> by Windows.
>>>
>>> Now you want to write this code in a language where windows.h is not
>>> available.
>
>> But okay, you want to figure out the offsets in this structure for use
>> in assembly, and you want to do it manually rather than with a simple
>> automated tool.
>
>> Step one is the same as always - understand the types involved, their
>> sizes, and their alignments.
>
> In the case of Win32 types, the padding and rounding rules for structs
> might not match the defaults of the C compiler being used.
They will match the padding and "rounding" (do you mean "alignment"?)
rules for any C compiler compatible with that header. If Windows.h is a
standard header file for that OS, then any C compiler capable of
generating binaries for that OS will having matching rules suitable for
using that header.
A compiler for a completely different target may have different rules
for alignment, of course - but it is not directly suitable for
interacting with Windows using that API.
In this particular case, the alignment and padding rules for Win32 types
is quite simple and obvious in most cases. More complex cases, such as
for vector types, might require a few seconds of googling to learn the
alignments.
> You will
> anyway need to know the padding and alignment used by the C compiler.
> That is not always obvious (what /is/ the alignment used by C compiler
> 'X'? I don't know).
For the most part, people don't /need/ to know about padding and
alignments to work with C. Those that do are either working with very
low-level code, aiming for binary compatibility across targets (file
formats, communication protocols, etc.), or aiming for compatibility
across different programming languages.
If you are working on a "weird" architecture, you should already know
the details. For other systems, you can normally assume the following
rules, but should check in the documentation:
For "normal" systems, types up to the cpu width will always be naturally
aligned. Thus on a 32-bit system, 8-bit, 16-bit and 32-bit data types
will be aligned on 1-byte, 2-byte and 4-byte boundaries.
For types bigger than the natural size of the cpu, they will have higher
alignment if that will be faster on that cpu architecture, considering
features like caches. So 8-byte types are 8-byte aligned on some 32-bit
systems, and not on others. These need to be checked in the
documentation, on the web, or with a couple of minutes experimentation.
> Neither do you know if a 'pragma pack(N)' is in
> effect or has been assumed.
That should be either immediately obvious, or very well documented.
Otherwise assume that it is not in effect, because "pragma pack" would
be an idiotic thing to use.
>
> As I said, it's trial and error.
You are talking about /two/ platforms at most - Windows 32 and Windows
64. These are hardly rare or unusual platforms - there is no shortage
of documentation and information. The type names, sizes and alignments
are almost all clear and simple.
If you want to do trial-and-error, do so - then you will be sure. But
you only need to write a single quick little program, run it once, and
make a note of the results. That's all. It is the work of a few
minutes. You make it sound like you have to do extensive research every
time you want to access a different Windows API.
>
>>> So, I'm interested in what your approach would be to extracting the
>>> relevant data from that lot.
>>
>> Just write it down and add up the numbers. It's not even /remotely/
>> difficult. If you find this too hard, trying taking your socks and
>> shoes off so that you can count to 20.
>
>> I'm sorry, but I completely fail to see the problem here. Converting
>> between Windows struct definitions and your own language seems
>> absolutely trivial to me.
>
> The problem is that there are tens of thousands of lines of this stuff
> in the Windows headers. Every new function, you've got dozens of new
> entities to translate (structs and types and messages and constants). I
> don't know an automatic that can do that without writing half a C compiler.
Writing a translator that will cope with /all/ the variations in the
windows headers is not trivial, but it is not hard either.
>
> (With Python of course, it apparently knows all the answers. You
> presumably just feed it the INPUT_RECORD definition, and it magically
> understands the C code, and knows the meanings of all the macros and
> typedefs that have been used.)
For reading C (or C++) headers and automatically generating Python
interfaces, there are lots of tools - SIP and SWIG are two of them. For
other languages, I have heard of "h2xml" and "h2nasm".
You can also use clang as a library (libclang) for parsing C or C++ code
if you really want a full parser. (There are even python bindings for it.)
But my comment about Python not needing offsets was at a much simpler
level than this. You claimed that Python needs to be told about the
offsets when doing struct packing/unpacking. That is incorrect.
struct { uint16_t a; uint16_t b; int32_t; } s
translates roughly to Python:
s = struct.pack("HHi", (a, b, c));
(a, b, c) = struct.unpack("HHi", s);
The struct definition string characters tell Python that the binary
structure here consists of two uint16_t's and then an int32_t. Python
knows the sizes, and does not need help to work out offsets. (And you
can choose between using platform-native alignments, or no alignment.)
>
> I'm simply saying I need to know C well and/or use C to derive all this
> information, even if my intention is to code in a different language.
You need to know almost /nothing/ about C to handle this. You have to
know the types, and the meanings of "struct" and "union", and that's
about it. From your single post on your own language, I can guess my
way to all the information I need in order to make structures that match
those defined in your language. That's all you need.
>
> And sometimes even the 'trick' of adding up the offsets is not
> practical. I've lost the original C of this example, but the version I
> ended up using in my language is this; notice the size of the first member:
>
> type jpeg_properties = record
> [19966]byte padding # skip complicated jpeg stuff
> int16 jfif_app0_units # 19966
> int16 jfif_app0_xdensity # 19968
> int16 jfif_app0_ydensity # 19970
> ref char jpeg_comment # 19972
> int32 jpeg_comment_size # 19976
> int32 padding2 # 19980, total size 19984
> end
>
Sometimes you might want a quick script to do the sums for you - or put
the struct in a C program and print out its size.
You really are making a mountain out of a molehill here.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-30 12:20 +0000 |
| Message-ID | <n0vn6c$h49$1@dont-email.me> |
| In reply to | #74249 |
On 30/10/2015 08:54, David Brown wrote: > On 29/10/15 20:19, Bartc wrote: >> You will >> anyway need to know the padding and alignment used by the C compiler. >> That is not always obvious (what /is/ the alignment used by C compiler >> 'X'? I don't know). > > For the most part, people don't /need/ to know about padding and > alignments to work with C. Those that do are either working with very > low-level code, aiming for binary compatibility across targets (file > formats, communication protocols, etc.), or aiming for compatibility > across different programming languages. Well, *I* do otherwise my programs don't work. I either have to emulate data structures used in C code, or talk to C functions using exactly equivalent types, or generate ASM code that talks to C, or generate C code that talks to other C code (which doesn't sound like much until except generated C code doesn't use #includes for any of the libraries it uses.) Or, what I mostly do now, generate dynamically typed bytecode that talks directly to C dynamic libraries including the whole of Win32. You, obviously, can't think of anything simpler or more trivial to achieve. That's why there are so many complicated tools to help out! (And the people who wrote those knew nothing about C, it wasn't necessary!) (When I started looking at your suggestions, I started going down the familiar path of Unix tools that only come in some obscure compressed format and need to be built from source... I think I would rather translate the whole of windows.h by hand, blindfolded.) >> Neither do you know if a 'pragma pack(N)' is in >> effect or has been assumed. > > That should be either immediately obvious, or very well documented. > Otherwise assume that it is not in effect, because "pragma pack" would > be an idiotic thing to use. (I'm looking at the docs for struct BITMAPFILEHEADER in Win32. That one breaks the rules (DWORDs use alignment of 2 not 4), but I can't see anything about that in the remarks.) >> I'm simply saying I need to know C well and/or use C to derive all this >> information, even if my intention is to code in a different language. > > You need to know almost /nothing/ about C to handle this. You have to > know the types, and the meanings of "struct" and "union", and that's > about it. Sorry, but that is nonsense. You might as well say that about any other feature in C, and demolish the language altogether. The official docs for Win32 API use C source code and C type specs to define the interfaces. If you have to resort to looking at headers, are you seriously saying anyone would be able to make head or tail of any C header file, whilst knowing next to nothing about the language? I suppose those famous convoluted type specs aren't a problem either: just plug them into into cdecl and you're done! > From your single post on your own language, I can guess my > way to all the information I need in order to make structures that match > those defined in your language. That's all you need. (Thank you. That's the idea, of have simple, uncluttered and obvious looking source code. C it isn't! And actually, exactly the same struct syntax is used in my interpreted language, even though it's dynamically typed. Python it isn't either!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-29 21:36 +0000 |
| Message-ID | <n0u3du$kta$1@dont-email.me> |
| In reply to | #74173 |
On 29/10/2015 15:22, David Brown wrote: > On 29/10/15 14:57, Bartc wrote: >> Now you want to write this code in a language where windows.h is not >> available. > That leaves assembly - and writing raw Windows code in assembly is an > exercise in mind-damaging masochism, and almost invariably results in > slower code than using a decent C compiler. The point of ASM is that it really requires the interfaces to be as transparent as possible /because they can't use C headers as they are/. A C interface is better than anything higher level, but is not as good as a proper binary interface. (How many bits is a 'long'? What is the alignment on this platform or this compiler?) But if something is possible in bare ASM (and without involving C tools which have a habit of injecting all sorts of junk you don't know about), then it means I have a good chance of /generate/ ASM code. > But okay, you want to figure out the offsets in this structure for use > in assembly, and you want to do it manually rather than with a simple > automated tool. Which simple automatic tool did you have in mind? I would love to have one that could at least convert some hairy-looking C headers (full of torturous macros, conditional code and these weird attributes you get on functions) into something I could understand at a glance, which /then/ I could translate routinely. It would be worth having just to help me understand code I /don't/ need to translate! (Look at the C typedef in my link in a previous post: it spells out the type and size of each field exactly, and the pack(1) means you know exactly where everything goes. That's good enough for a binary spec, and would be a delight to translate.) I have thought of writing such a tool, taking the form of a C compiler front end, but it's a big job. And I wouldn't know what to do with conditional code: do you translate both branches of a #if/#else, which might be necessary for a one-time translation, or just one, as a normal compiler would? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-30 10:47 +1300 |
| Message-ID | <d9fiftF2lrhU3@mid.individual.net> |
| In reply to | #74204 |
Bartc wrote: > On 29/10/2015 15:22, David Brown wrote: >> On 29/10/15 14:57, Bartc wrote: > >>> Now you want to write this code in a language where windows.h is not >>> available. > >> That leaves assembly - and writing raw Windows code in assembly is an >> exercise in mind-damaging masochism, and almost invariably results in >> slower code than using a decent C compiler. > > The point of ASM is that it really requires the interfaces to be as > transparent as possible /because they can't use C headers as they are/. > > A C interface is better than anything higher level, but is not as good > as a proper binary interface. (How many bits is a 'long'? What is the > alignment on this platform or this compiler?) Isn't that why we have platform ABIs? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-29 22:25 +0000 |
| Message-ID | <n0u69k$v74$1@dont-email.me> |
| In reply to | #74206 |
On 29/10/2015 21:47, Ian Collins wrote: > Bartc wrote: >> A C interface is better than anything higher level, but is not as good >> as a proper binary interface. (How many bits is a 'long'? What is the >> alignment on this platform or this compiler?) > > Isn't that why we have platform ABIs? How would it help here in translating this function prototype? (You can just about make it out!) __GMP_DECLSPEC int _mpq_cmp_si __GMP_PROTO ((mpq_srcptr, long, unsigned long)) __GMP_ATTRIBUTE_PURE; Objective: to be able to call it from language X. I want X to be work on more than one target with the same source. (One target is acceptable if X is ASM.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-30 09:59 +0100 |
| Message-ID | <n0vbde$75m$1@dont-email.me> |
| In reply to | #74206 |
On 29/10/15 22:47, Ian Collins wrote: > Bartc wrote: >> On 29/10/2015 15:22, David Brown wrote: >>> On 29/10/15 14:57, Bartc wrote: >> >>>> Now you want to write this code in a language where windows.h is not >>>> available. >> >>> That leaves assembly - and writing raw Windows code in assembly is an >>> exercise in mind-damaging masochism, and almost invariably results in >>> slower code than using a decent C compiler. >> >> The point of ASM is that it really requires the interfaces to be as >> transparent as possible /because they can't use C headers as they are/. >> >> A C interface is better than anything higher level, but is not as good >> as a proper binary interface. (How many bits is a 'long'? What is the >> alignment on this platform or this compiler?) > > Isn't that why we have platform ABIs? > He is using Windows. MS didn't think of the idea of a "platform ABI" until Win64 - ABI's that let you easily mix code from different tools, or use pre-compiled static libraries, is a unixy sort of idea. That would encourage sharing, re-use and cooperation, and we can't have that risking MS's monopoly!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-30 10:07 +0100 |
| Message-ID | <n0vbs0$8n9$1@dont-email.me> |
| In reply to | #74204 |
On 29/10/15 22:36, Bartc wrote: > On 29/10/2015 15:22, David Brown wrote: >> On 29/10/15 14:57, Bartc wrote: > >>> Now you want to write this code in a language where windows.h is not >>> available. > >> That leaves assembly - and writing raw Windows code in assembly is an >> exercise in mind-damaging masochism, and almost invariably results in >> slower code than using a decent C compiler. > > The point of ASM is that it really requires the interfaces to be as > transparent as possible /because they can't use C headers as they are/. > > A C interface is better than anything higher level, but is not as good > as a proper binary interface. (How many bits is a 'long'? What is the > alignment on this platform or this compiler?) > > But if something is possible in bare ASM (and without involving C tools > which have a habit of injecting all sorts of junk you don't know about), > then it means I have a good chance of /generate/ ASM code. > >> But okay, you want to figure out the offsets in this structure for use >> in assembly, and you want to do it manually rather than with a simple >> automated tool. > > Which simple automatic tool did you have in mind? I would love to have > one that could at least convert some hairy-looking C headers (full of > torturous macros, conditional code and these weird attributes you get on > functions) into something I could understand at a glance, which /then/ I > could translate routinely. It would be worth having just to help me > understand code I /don't/ need to translate! Google for tools, or write one yourself. If you need to support parsing complicated headers, then just run the headers through a C preprocessor and use the output from that. gcc's preprocessor can save the output file, with helpful added line numbers to help you match up the preprocessed file with the original. If you spent have as much effort on such a tool as you do on moaning about how difficult this all is, you'd be finished by now. > > (Look at the C typedef in my link in a previous post: it spells out the > type and size of each field exactly, and the pack(1) means you know > exactly where everything goes. That's good enough for a binary spec, and > would be a delight to translate.) > > I have thought of writing such a tool, taking the form of a C compiler > front end, but it's a big job. And I wouldn't know what to do with > conditional code: do you translate both branches of a #if/#else, which > might be necessary for a one-time translation, or just one, as a normal > compiler would? > Did you invent your own keyboard before writing that paragraph? Did you make your own wheels for your bicycle? Use an existing C preprocessor if you want to preprocess C! You have been using Windows too long, and are thinking in terms of every program having to do everything, from scratch. Think like a *nix programmer - pass the header through "cpp", and into a Python script where you can easily parse the output and get what you need, generating the output in whatever format suits you. Or try something like h2xml as a starting point, and see if that could be helpful.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-28 16:25 +0100 |
| Message-ID | <n0qp8d$oo4$1@dont-email.me> |
| In reply to | #74078 |
On 28/10/15 14:55, Bartc wrote: > On 28/10/2015 12:58, Richard Heathfield wrote: >> On 28/10/15 12:10, Bartc wrote: > >>> (I need to do both: from generated assembly code, and from generated C >>> code. With the former, I don't have the luxury of using main(argc, argc) >>> (nor of using WinMain(...)). Since the input to both targets has to be >>> the same, I can only work with main(void).) >> >> <OT> >> Assembly language how-to for command line arguments: >> https://www.freebsd.org/doc/en/books/developers-handbook/x86-command-line.html >> >> </OT> > > "Before a UNIX® system starts a program, it pushes some data on the > stack,..." > > Presumably that would be argc and the list of argv values, which would > be jolly handy when you happen to be running C programs! > > But apparently that doesn't seem to happen with Windows (and how would > it know that an executable represents a C program?) > > Just too much 'intimacy' between C and Unix IMO (and I wonder which came > first: how Unix deals with argc/argv, or how C deals with it?) > You are reading the developers handbook for a *nix system, and you are surprised and confused that it refers to UNIX, and think that means that Windows does something different? The people writing that handbook are only writing about how things work in *nix in general, and FreeBSD in particular. Your logic here is as bad as the witch trial in Monty Python. To save your limited googling abilities, console applications in Windows get their argc/argv parameters like in Unix. The only difference is that in *nix, the shell will handle things like wildcards - in Windows, they are passed on to the program because in Windows every program is supposed to duplicate basic system functionality, preferably in a slightly different way each time.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-28 16:01 +0000 |
| Message-ID | <n0qrc0$1j8$1@dont-email.me> |
| In reply to | #74086 |
On 28/10/2015 15:25, David Brown wrote: > On 28/10/15 14:55, Bartc wrote: >> On 28/10/2015 12:58, Richard Heathfield wrote: >>> On 28/10/15 12:10, Bartc wrote: >> >>>> (I need to do both: from generated assembly code, and from generated C >>>> code. With the former, I don't have the luxury of using main(argc, argc) >>>> (nor of using WinMain(...)). Since the input to both targets has to be >>>> the same, I can only work with main(void).) >>> >>> <OT> >>> Assembly language how-to for command line arguments: >>> https://www.freebsd.org/doc/en/books/developers-handbook/x86-command-line.html >>> >>> </OT> >> >> "Before a UNIX® system starts a program, it pushes some data on the >> stack,..." >> >> Presumably that would be argc and the list of argv values, which would >> be jolly handy when you happen to be running C programs! >> >> But apparently that doesn't seem to happen with Windows (and how would >> it know that an executable represents a C program?) >> >> Just too much 'intimacy' between C and Unix IMO (and I wonder which came >> first: how Unix deals with argc/argv, or how C deals with it?) >> > > You are reading the developers handbook for a *nix system, and you are > surprised and confused that it refers to UNIX, and think that means that > Windows does something different? The people writing that handbook are > only writing about how things work in *nix in general, and FreeBSD in > particular. No, I'm fairly sure that Windows does it differently (but people are so used to C implementations pulling strings behind the scenes, that even experts have come to think that Windows actually supplies those argc and argv parameters). And if that link is correct, then that *is* a very strong correspondence between how Unix passes control to a program's entry point, and the arguments expected by C's main(argc,argv) entry point. (The difference is that the argv list becomes a pointer to the list.) > To save your limited googling abilities, console applications in Windows > get their argc/argv parameters like in Unix. No they don't. If they use C, then some C startup code will set up those parameters (possibly by calling GetCommandLine() in the Win32 API like I have to). But Windows itself does not pass anything like that. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-28 09:50 -0700 |
| Message-ID | <lny4enaqel.fsf@kst-u.example.com> |
| In reply to | #74090 |
Bartc <bc@freeuk.com> writes:
> On 28/10/2015 15:25, David Brown wrote:
[...]
>> To save your limited googling abilities, console applications in Windows
>> get their argc/argv parameters like in Unix.
>
> No they don't.
>
> If they use C, then some C startup code will set up those parameters
> (possibly by calling GetCommandLine() in the Win32 API like I have to).
>
> But Windows itself does not pass anything like that.
I've used MS Visual Studio before, but not lately.
When I configure it to build a console application, I can write,
compile, and run a C program defined with the standard
int main(int argc, char **argv)
I can execute it from a command line prompt, passing any arguments I
like to it. The program receives the arguments and works correctly.
Apart from telling the IDE that I want to build a console
application, I don't have to do anything special to make it
work. Whatever magic is done to make it work is part of the C
implementation, and I don't have to know or care how it's done,
or whether it's part of "Windows". I don't have to write any
special startup code. If there's a call to GetCommandLine(),
I don't see it, any more than I see the code that invokes main()
when I run a C program on Unix. It just works.
--
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]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web