Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #171992 > unrolled thread
| Started by | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| First post | 2023-08-10 04:29 -0700 |
| Last post | 2023-09-13 09:40 -0700 |
| Articles | 20 on this page of 359 — 21 participants |
Back to article view | Back to comp.lang.c
bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 04:29 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-10 12:57 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 05:07 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-10 13:14 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 06:53 -0700
Re: bart again (UCX64) cross@spitfire.i.gajendra.net (Dan Cross) - 2023-08-16 11:52 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-16 02:31 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-28 03:30 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-28 11:43 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-28 03:47 -0700
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-04 18:43 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 04:59 -0700
Re: bart again (UCX64) Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-28 17:45 +0300
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-28 19:19 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-29 22:01 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-29 20:00 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 00:25 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 01:35 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 11:38 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 07:06 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 15:53 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 12:46 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 22:59 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 15:54 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 00:17 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 16:30 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 11:58 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 05:32 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 14:45 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 07:43 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 15:56 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 08:38 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 12:56 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 22:09 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 10:12 +0200
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 23:53 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 14:39 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-31 20:56 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-08-31 14:36 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 15:30 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 16:17 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-08-31 19:36 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 20:26 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 13:17 -0700
Verbosity in command output (Was: bart again (UCX64)) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-31 21:43 +0000
Re: Verbosity in command output (Was: bart again (UCX64)) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 23:31 +0000
Re: Verbosity in command output (Was: bart again (UCX64)) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-31 21:36 -0700
Re: Verbosity in command output (Was: bart again (UCX64)) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:22 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 23:07 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 15:32 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 22:05 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 22:07 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 23:18 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 23:03 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 16:46 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 01:44 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 18:09 -0700
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-31 18:11 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 18:14 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 01:38 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 02:40 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 01:29 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 20:28 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 11:10 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 12:01 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 13:20 +0200
Re: bart again (UCX64) Richard Harnden <richard.nospam@gmail.com> - 2023-09-01 13:08 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 13:39 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 15:29 +0200
Re: bart again (UCX64) Richard Harnden <richard.nospam@gmail.com> - 2023-09-01 14:32 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 18:14 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 19:01 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:53 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-01 14:53 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 15:57 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-01 19:07 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 19:27 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:55 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 21:27 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 20:46 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 22:29 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 22:19 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 13:56 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 15:31 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 16:05 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 03:17 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 10:34 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 03:07 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 11:43 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 04:21 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 17:16 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 18:33 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-05 01:33 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 15:27 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 17:18 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-04 16:26 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 19:33 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-04 19:17 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 20:48 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 21:25 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-04 21:56 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-05 01:34 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 21:06 +0100
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-04 13:09 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 16:04 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 00:52 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 17:16 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 15:33 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-05 14:55 +0000
Re: bart again (UCX64) Bobby Moore <bobbymoore018@gmail.com> - 2023-09-05 08:30 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 17:31 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 18:06 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 17:54 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 20:10 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 20:57 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 22:37 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 22:05 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 15:10 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 22:32 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 06:49 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 16:08 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 07:53 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 17:35 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 09:37 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 20:49 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-06 19:51 +0000
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-06 12:52 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 00:36 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 17:06 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 18:47 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 11:11 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-07 04:04 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 13:24 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-06 18:13 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 21:17 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-06 22:24 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 11:37 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 11:53 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 13:33 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:36 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 22:59 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:58 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-08 00:35 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 20:41 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 20:47 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 14:07 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 22:22 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 15:26 -0700
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-05 18:26 -0700
Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-07 23:15 -0400
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 13:48 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 21:36 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 13:24 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 15:46 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:44 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 01:14 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-01 18:13 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 01:43 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:51 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:58 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 23:28 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-02 20:09 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 07:15 +0000
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-03 03:03 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 18:53 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 16:24 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 12:22 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 02:01 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 21:40 -0700
[OT] Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 17:06 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-03 18:02 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 10:39 +0100
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-02 07:33 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 16:26 +0100
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-02 09:03 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 19:22 +0100
Re: bart again (UCX64) vallor <vallor@cultnix.org> - 2023-09-05 01:38 +0000
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-04 20:05 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 16:45 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 06:49 +0000
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 05:30 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 17:16 +0000
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 08:47 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 19:57 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 19:01 -0700
Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-09 01:14 -0400
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 05:22 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 12:51 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 12:58 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 16:29 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 20:00 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 00:08 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 01:36 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 02:41 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:49 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:32 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-01 18:59 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 18:02 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-03 15:54 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 19:50 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-03 21:25 +0000
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-03 16:44 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 11:47 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:16 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:48 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 19:12 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:49 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 21:33 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 21:09 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 22:41 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 22:34 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 15:51 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 14:06 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 17:27 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 16:02 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 01:50 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 01:12 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 19:13 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 11:57 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 18:19 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 19:53 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 06:32 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:02 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 18:11 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 11:31 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 20:07 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 22:08 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 03:16 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 10:54 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 11:06 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 14:54 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 22:02 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-05 01:31 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 02:24 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 04:29 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 21:06 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 01:03 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 20:58 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 19:21 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 20:18 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-06 13:07 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 22:41 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-06 15:56 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 00:53 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-06 18:47 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 17:25 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-12 10:32 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 18:30 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 03:04 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 21:48 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 06:10 +0000
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-07 02:06 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 15:52 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:18 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 15:28 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 16:54 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:02 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 16:12 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 16:17 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:37 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:51 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 00:46 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:06 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 10:19 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 15:55 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 15:16 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 17:02 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 16:15 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 17:51 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:24 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 21:53 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:34 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:25 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 21:37 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:02 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:14 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:09 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:34 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:22 +0000
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 11:44 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 15:16 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 23:48 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 17:16 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:16 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 10:51 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 13:00 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 13:05 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:11 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 00:56 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 00:47 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:49 +0200
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-09 10:27 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 12:06 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-08 05:03 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 13:39 +0100
Re: bart again (UCX64) candycanearter07 <no@thanks.net> - 2023-09-08 07:49 -0500
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:07 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:51 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:35 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:04 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-04 14:14 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 16:59 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 15:41 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-04 18:15 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 18:57 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 09:23 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-30 15:55 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 17:10 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 13:13 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 22:50 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 14:54 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 19:02 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 22:42 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 15:08 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 02:00 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 23:18 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 02:28 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 06:58 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 15:52 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 11:02 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:25 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 16:49 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:16 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 18:11 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 22:08 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:48 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 14:52 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 02:23 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 03:47 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 18:44 +0000
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 18:01 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:59 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 17:50 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 10:43 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-01 02:17 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 13:26 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 11:35 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 13:39 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 14:09 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 15:33 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-01 05:14 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:41 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-01 18:21 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 14:31 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 22:39 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 07:07 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 19:17 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 19:28 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 21:03 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 11:23 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 20:50 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 23:12 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 02:25 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 20:37 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 07:51 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 16:09 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 20:17 +0100
Re: bart again (UCX64) Michael S <already5chosen@yahoo.com> - 2023-08-29 04:46 -0700
Buy Magic Mushrooms online Buy Magic Mushroom Chocolate Bars <taresa67kolyta@gmail.com> - 2023-09-13 09:40 -0700
Page 2 of 18 — ← Prev page 1 [2] 3 4 … 18 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-30 15:53 +0100 |
| Message-ID | <ucnl64$2p8as$1@dont-email.me> |
| In reply to | #173300 |
On 30/08/2023 15:06, Paul Edwards wrote:
> Hi Bart.
>
> I have encountered the below problem.
>
> mingw64 works, but cc64 crashes on the fprintf.
>
> Any idea? I will answer your other post now.
>
> C:\devel\pdos\pdpclib>pdld -s -nostdlib --no-insert-timestamp --image-base 0x400000 -o pdptest.exe w32start.obj pdptest.obj msvcrt.lib
>
> C:\devel\pdos\pdpclib>pdptest
> xhello 5
>
> C:\devel\pdos\pdpclib>type pdptest.c
>
> int fprintf(void *stream, const char *format, ...);
> int printf(const char *format, ...);
>
> extern char *__imp__iob;
>
> int main(void)
> {
> printf("xhello %d\n", 5);
> fprintf(__imp__iob + 48, "yhello, world\n");
> return (0);
> }
It's not clear which C library is being linked in here. BCC is designed
to use MSVCRT.DLL (that is reflected in headers like stdio.h).
Because '__imp__iob' is not exported by msvcrt.dll; '_iob' is as a
variable, but that crashes too (even after fiddling with the generated ASM).
(Or maybe that extra '__imp_' prefix is an artefact of the linking
method that is being used, if using msvcrt.lib to access the same .dll.)
I'm not sure how well BCC links to variables exported from DLLS rather
than functions, but your test doesn't appear to use my internal linker
anyway.
I managed to get your example working by using a function instead of a
variable. See that version below. Note that in my stdio.h, 'stdout' is
defined as:
#define stdout ((FILE*)(__iob_func()+sizeof(FILE)))
sizeof(FILE) is 48.
--------------------------------------------
int fprintf(void *stream, const char *format, ...);
int printf(const char *format, ...);
extern char* __iob_func(void);
int main(void)
{
printf("xhello %d\n", 5);
fprintf(__iob_func() + 48, "yhello, world\n");
return (0);
}
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2023-08-30 12:46 -0700 |
| Message-ID | <65d28a7d-ffd5-4b8b-b3f0-2500bb05f9b7n@googlegroups.com> |
| In reply to | #173304 |
On Wednesday, August 30, 2023 at 10:54:10 PM UTC+8, Bart wrote: > It's not clear which C library is being linked in here. BCC is designed > to use MSVCRT.DLL (that is reflected in headers like stdio.h). I have my own msvcrt.dll, built using makefile.s64 or makefile.n64 > Because '__imp__iob' is not exported by msvcrt.dll; '_iob' is as a I believe it is - that's why I can use mingw64 and it works. > I managed to get your example working by using a function instead of a > variable. See that version below. Note that in my stdio.h, 'stdout' is > defined as: > > #define stdout ((FILE*)(__iob_func()+sizeof(FILE))) > > sizeof(FILE) is 48. Thankyou! I wasn't aware that the function __iob_func() existed. That is good enough for my purposes and is now working in my environment too. Thanks a lot! BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-30 22:59 +0100 |
| Message-ID | <ucoe3l$2t4o2$1@dont-email.me> |
| In reply to | #173343 |
On 30/08/2023 20:46, Paul Edwards wrote: > On Wednesday, August 30, 2023 at 10:54:10 PM UTC+8, Bart wrote: > >> It's not clear which C library is being linked in here. BCC is designed >> to use MSVCRT.DLL (that is reflected in headers like stdio.h). > > I have my own msvcrt.dll, built using makefile.s64 or makefile.n64 > >> Because '__imp__iob' is not exported by msvcrt.dll; '_iob' is as a > > I believe it is - that's why I can use mingw64 and it works. __imp_ appears to be an artefact of the linking system on Windows, and may be to do with .lib and .a files. If I look inside mingw64's libmsvcrt.a, I can see names starting with __imp_. But inside msvcrt.dll itself, there are no __imp_ prefixes. I was surprised you can use __imp_ in a source file, but it's possible that some compilers, if you annotate a DLL imported name with __declspec(dllimport), will add that prefix when it writes .obj files. So that explains why you can just add it manually. My compiler normally links directly to .DLL files (but cannot statically link); there no .obj, .a, or .lib files involved, so that stuff isn't needed.
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2023-08-30 15:54 -0700 |
| Message-ID | <557bf807-40c7-404b-9242-c26975faa42fn@googlegroups.com> |
| In reply to | #173351 |
Hi Bart. Next error I have is: cc64 -c -out:cclib/cclib.obj cclib/cclib.i Compiling cclib/cclib.i to cclib/cclib.obj In function ccpartype On line 1315 in file cclib/cclib.i **** Code Gen Error: Block call after return **** You can see the code here: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cclib/cclib.c Change the first CC64 to XCC64 to activate the error. It was built with makefile.n64 one level up. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-31 00:17 +0100 |
| Message-ID | <ucoils$2tstj$1@dont-email.me> |
| In reply to | #173364 |
On 30/08/2023 23:54, Paul Edwards wrote:
> Hi Bart.
>
> Next error I have is:
>
> cc64 -c -out:cclib/cclib.obj cclib/cclib.i
> Compiling cclib/cclib.i to cclib/cclib.obj
> In function ccpartype On line 1315 in file cclib/cclib.i
>
> **** Code Gen Error: Block call after return ****
>
> You can see the code here:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cclib/cclib.c
>
> Change the first CC64 to XCC64 to activate the error.
>
> It was built with makefile.n64 one level up.
This is a tricky one. It can be invoked like this:
typedef struct {int a,b,c;} S;
S F(void) {
S x;
return x;
}
void G(void) {
F();
return;
F();
return;
}
'S' is a struct type that is other than 1/2/4/8 bytes in size. If you
make a call to a function that returns such a type, like my F() call
above, even if you don't use the return value, it must be just before
the final return.
Once one 'return' has been seen, you can't make another such call. This
is just due to primitive handling of such data types.
Such functions need to be adjusted to use a common return point, for
example:
void G(void) {
F();
goto retpoint;
F();
retpoint:
return;
If a return value is involved, copy it to a common variable before jumping.
(I couldn't find function ccpartype in your link.)
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2023-08-30 16:30 -0700 |
| Message-ID | <e1998f76-e729-45a3-8b19-c54023e679f8n@googlegroups.com> |
| In reply to | #173365 |
On Thursday, August 31, 2023 at 7:17:30 AM UTC+8, Bart wrote:
> Once one 'return' has been seen, you can't make another such call. This
> is just due to primitive handling of such data types.
>
> Such functions need to be adjusted to use a common return point, for
> example:
>
> void G(void) {
> F();
> goto retpoint;
> F();
> retpoint:
> return;
>
> If a return value is involved, copy it to a common variable before jumping.
Thanks for the workaround!
> (I couldn't find function ccpartype in your link.)
Names were shortened because I build on the mainframe (MVS) too:
C:\devel\pdos\pdcc>dir *.jcl
Volume in drive C has no label.
Volume Serial Number is 4E58-AF11
Directory of C:\devel\pdos\pdcc
2023-07-23 21:55 6,124 makemvs.jcl
Here is the original name:
C:\devel\pdos\pdcc\cclib>grep cc_parse_type cclib.c
cclib.c: member.type = cc_parse_type(reader);
cclib.c: cc_type cc_parse_type(cc_reader *reader)
cclib.c: param.type = cc_parse_type(reader);
cclib.c: expr.data.cast.type = cc_parse_type(reader);
cclib.c: var.type = cc_parse_type(reader); /* Now parse the type */
C:\devel\pdos\pdcc\cclib>cd include
C:\devel\pdos\pdcc\cclib\include>grep ccpartype '*'
cclib.h: #define cc_parse_type ccpartype
C:\devel\pdos\pdcc\cclib\include>
BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-31 11:58 +0100 |
| Message-ID | <ucprpd$38s6i$1@dont-email.me> |
| In reply to | #173364 |
On 30/08/2023 23:54, Paul Edwards wrote: > Hi Bart. > > Next error I have is: > > cc64 -c -out:cclib/cclib.obj cclib/cclib.i > Compiling cclib/cclib.i to cclib/cclib.obj BTW the -out option is not needed here. The output file uses the same filename and the same path, just the extension is changed. So the generated .obj file is in the same folder as the .c or .i source file. The same applies when generating executables; you can compile code remotely. Other C compilers may be different; gcc for example applies the right extension, but the object file (or executable) is written to the current directory. And others tend to copy gcc. (Sorry, this is part of a feud I have between my compiler, and the quirky way that gcc works. Apparently whatever gcc does is right, even when it's wrong. If gcc drives over a cliff, other compilers have to do the same!)
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2023-08-31 05:32 -0700 |
| Message-ID | <8e7740e0-c601-481f-ad11-2893b54fd44an@googlegroups.com> |
| In reply to | #173397 |
On Thursday, August 31, 2023 at 6:59:08 PM UTC+8, Bart wrote:
> BTW the -out option is not needed here. The output file uses the same
> filename and the same path, just the extension is changed.
Ok, thanks for the info.
Next problem I have encountered is this:
With this code:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cpplib/directs.c
Plus this modification:
C:\devel\pdos\pdcc>git diff .
diff --git a/pdcc/cpplib/directs.c b/pdcc/cpplib/directs.c
index 8674a696..bd515203 100644
--- a/pdcc/cpplib/directs.c
+++ b/pdcc/cpplib/directs.c
@@ -792,6 +792,13 @@ void _cpp_init_directives(cpp_reader *reader)
{
unsigned int i;
+printf("in init_directives\n");
+printf("element 0 is %p\n", directives[0].name);
+printf("element 0 alternate is %p\n", &directives[0]);
+printf("element 1 is %p\n", directives[1].name);
+printf("element 1 alternate is %p\n", &directives[1]);
+exit(0);
+
for (i = 0; i < DIRECTIVE_COUNT; i++)
{
cpp_unknown *unknown = cpp_find(reader, directives[i].name,
C:\devel\pdos\pdcc>
I see:
C:\devel\pdos\pdcc>pdcc -E abc.c
in init_directives
element 0 is 0000000000403368
element 0 alternate is 00000000004031F8
element 1 is 0200000000004033
element 1 alternate is 00000000004031F9
C:\devel\pdos\pdcc>type abc.c
int x;
C:\devel\pdos\pdcc>
I shouldn't be getting those high addresses.
The situation has been analyzed by the author of pdld, who says:
The problem seems to be cc64 wrongly accessing an address field.
If you look at .text section relocations in directs.obj, you can find relocation with "printf" with RVA 0x17A (that is the call part of the faulty "printf("element 1 is %p\n", directives[1].name);" line).
In .text section at that address the code is this:
...
48 83 ec 20 sub rsp,0x20
ff 34 25 29 00 00 00 push QWORD PTR ds:0x29 (the cc64 wrongly accessing an address field)
48 b9 19 02 00 00 00 movabs rcx,0x219
00 00 00
5a pop rdx
e8 00 00 00 00 call 0x1f (the call to printf at 0x17A)
...
The 0x29 is wrong and correctly it should be 0x28 what can be seen by looking at .data section at that address.
Are you able to comment on this?
Thanks. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-31 14:45 +0100 |
| Message-ID | <ucq5gr$3ahqh$1@dont-email.me> |
| In reply to | #173400 |
On 31/08/2023 13:32, Paul Edwards wrote:
> On Thursday, August 31, 2023 at 6:59:08 PM UTC+8, Bart wrote:
>
>> BTW the -out option is not needed here. The output file uses the same
>> filename and the same path, just the extension is changed.
>
> Ok, thanks for the info.
>
> Next problem I have encountered is this:
>
> With this code:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cpplib/directs.c
>
> Plus this modification:
>
> C:\devel\pdos\pdcc>git diff .
> diff --git a/pdcc/cpplib/directs.c b/pdcc/cpplib/directs.c
> index 8674a696..bd515203 100644
> --- a/pdcc/cpplib/directs.c
> +++ b/pdcc/cpplib/directs.c
> @@ -792,6 +792,13 @@ void _cpp_init_directives(cpp_reader *reader)
> {
> unsigned int i;
>
> +printf("in init_directives\n");
> +printf("element 0 is %p\n", directives[0].name);
> +printf("element 0 alternate is %p\n", &directives[0]);
> +printf("element 1 is %p\n", directives[1].name);
> +printf("element 1 alternate is %p\n", &directives[1]);
> +exit(0);
> +
> for (i = 0; i < DIRECTIVE_COUNT; i++)
> {
> cpp_unknown *unknown = cpp_find(reader, directives[i].name,
>
> C:\devel\pdos\pdcc>
>
>
> I see:
>
> C:\devel\pdos\pdcc>pdcc -E abc.c
> in init_directives
> element 0 is 0000000000403368
> element 0 alternate is 00000000004031F8
> element 1 is 0200000000004033
> element 1 alternate is 00000000004031F9
>
>
> C:\devel\pdos\pdcc>type abc.c
> int x;
>
> C:\devel\pdos\pdcc>
>
>
>
> I shouldn't be getting those high addresses.
>
>
> The situation has been analyzed by the author of pdld, who says:
>
> The problem seems to be cc64 wrongly accessing an address field.
>
> If you look at .text section relocations in directs.obj, you can find relocation with "printf" with RVA 0x17A (that is the call part of the faulty "printf("element 1 is %p\n", directives[1].name);" line).
>
> In .text section at that address the code is this:
> ...
> 48 83 ec 20 sub rsp,0x20
> ff 34 25 29 00 00 00 push QWORD PTR ds:0x29 (the cc64 wrongly accessing an address field)
> 48 b9 19 02 00 00 00 movabs rcx,0x219
> 00 00 00
> 5a pop rdx
> e8 00 00 00 00 call 0x1f (the call to printf at 0x17A)
> ...
>
> The 0x29 is wrong and correctly it should be 0x28 what can be seen by looking at .data section at that address.
>
>
> Are you able to comment on this?
No, sorry. I gave up on this stuff because I was being drawn into it so
much. 90% of it was having to grapple with complex C source code for
which I don't have the right tools for browsing and searching.
I realise the code generator on BCC is poor, and is buggy, which is why
I kept it as a private tool. (/My/ C code is very conservative; there it
works fine!)
What I will do however is this:
* I will take the BCC project and look at the possibility of replacing
the backend code generator with a new one.
* I can't directly use the one from my own compilers, as C is different:
I normally work with 64-bit intermediates throughout, C is mixed
32/64-bit, but mostly 32 bits
So I will do an evaluation first of how viable it will be, but if I
decide to attempt it, it will take some time so is not an immediate
solution.
That would be a better use of my time than trying to do ad hoc fixes and
patches for bugs I can't easily reproduce anyway.
Note a new backend won't fix any conformance issues. The problem with
(*F)()/F() is borderline; maybe that will fixed. The Block problem
should be. I don't want to touch the front end.
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2023-08-31 07:43 -0700 |
| Message-ID | <31bf11a1-03d5-4ed2-8af0-0d2aeb471292n@googlegroups.com> |
| In reply to | #173403 |
On Thursday, August 31, 2023 at 9:45:14 PM UTC+8, Bart wrote: > I realise the code generator on BCC is poor, and is buggy, which is why > I kept it as a private tool. (/My/ C code is very conservative; there it > works fine!) Ok, thanks. I'll see if I can rework the C code to be conservative. > So I will do an evaluation first of how viable it will be, but if I > decide to attempt it, it will take some time so is not an immediate > solution. Sure. No problem. And no expectations. This is already a decades-long endeavor anyway. It's more just trying to understand where we stand after this latest breakthrough. > That would be a better use of my time than trying to do ad hoc fixes and > patches for bugs I can't easily reproduce anyway. You should be able to reproduce my results. I have uploaded http://pdos.org/uc386.zip which has all the executables that get executed when running makefile.n64. Plus it has the source code itself, so that you don't need to go to sourceforge. Also note that since producing the above, I have committed a bit more development to sourceforge, but nothing related to or that affects this issue. > Note a new backend won't fix any conformance issues. The problem with > (*F)()/F() is borderline; maybe that will fixed. The Block problem > should be. I don't want to touch the front end. Sure. The new cc64 (if it arrives) will still be public domain though, right? Thanks. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-31 15:56 +0100 |
| Message-ID | <ucq9ni$3b3hm$1@dont-email.me> |
| In reply to | #173406 |
On 31/08/2023 15:43, Paul Edwards wrote: > On Thursday, August 31, 2023 at 9:45:14 PM UTC+8, Bart wrote: > >> I realise the code generator on BCC is poor, and is buggy, which is why >> I kept it as a private tool. (/My/ C code is very conservative; there it >> works fine!) > > Ok, thanks. I'll see if I can rework the C code to be conservative. > >> So I will do an evaluation first of how viable it will be, but if I >> decide to attempt it, it will take some time so is not an immediate >> solution. > > Sure. No problem. And no expectations. > > This is already a decades-long endeavor anyway. It's more just > trying to understand where we stand after this latest breakthrough. > >> That would be a better use of my time than trying to do ad hoc fixes and >> patches for bugs I can't easily reproduce anyway. > > You should be able to reproduce my results. > > I have uploaded http://pdos.org/uc386.zip which has all the > executables that get executed when running makefile.n64. > Plus it has the source code itself, so that you don't need to > go to sourceforge. > > Also note that since producing the above, I have committed > a bit more development to sourceforge, but nothing related > to or that affects this issue. > >> Note a new backend won't fix any conformance issues. The problem with >> (*F)()/F() is borderline; maybe that will fixed. The Block problem >> should be. I don't want to touch the front end. > > Sure. The new cc64 (if it arrives) will still be public domain > though, right? It can be. (Personally I don't care about that aspect at all.) I can confirm that I've started an overhaul of the project, which will have a working title of 'DD' to distinguish it from 'CC'. The first stage is to get it to generate a new intermediate (IL) code (perhaps within a week). If that looks promising, then I need to turn that into ASM code. That is likely to smaller, faster, fully ABI-conforming, and with hopefully fewer bugs.
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2023-08-31 08:38 -0700 |
| Message-ID | <25fdb458-7915-4506-b80f-69569e687368n@googlegroups.com> |
| In reply to | #173407 |
On Thursday, August 31, 2023 at 10:57:05 PM UTC+8, Bart wrote:
> > Sure. The new cc64 (if it arrives) will still be public domain
> > though, right?
> It can be. (Personally I don't care about that aspect at all.)
If you don't care, then please keep it public domain, because
that is the whole point - I care, and I am working with people
who care. And all the people I work with have attempted or
are still attempting to write a public domain C90-compliant
compiler, but nobody has reached cc64 level yet.
> I can confirm that I've started an overhaul of the project, which will
> have a working title of 'DD' to distinguish it from 'CC'. The first
> stage is to get it to generate a new intermediate (IL) code (perhaps
> within a week).
>
> If that looks promising, then I need to turn that into ASM code. That is
> likely to smaller, faster, fully ABI-conforming, and with hopefully
> fewer bugs.
Ok, cool.
Note that it was suggested to take this to email, but I
personally don't think it is off-topic. If you do, my email
address is mutazilah AT gmail DOT com.
I have a new problem regardless.
C:\devel\pdos\pdmake>pdmake -f makefile.n64
rm -f main.obj read.obj rule.obj variable.obj xmalloc.obj hashtab.obj ../pdpclib/x64supb.obj pdmake.exe
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o main.i main.c
cc64 -c -out:main.obj main.i
Compiling main.i to main.obj
rm -f main.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o read.i read.c
cc64 -c -out:read.obj read.i
Compiling read.i to read.obj
rm -f read.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o rule.i rule.c
cc64 -c -out:rule.obj rule.i
Compiling rule.i to rule.obj
rm -f rule.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o variable.i variable.c
cc64 -c -out:variable.obj variable.i
Compiling variable.i to variable.obj
rm -f variable.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o xmalloc.i xmalloc.c
cc64 -c -out:xmalloc.obj xmalloc.i
Compiling xmalloc.i to xmalloc.obj
rm -f xmalloc.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o ./hashtab/hashtab.i ./hashtab/hashtab.c
cc64 -c -out:hashtab.obj ./hashtab/hashtab.i
Compiling ./hashtab/hashtab.i to hashtab.obj
rm -f ./hashtab/hashtab.i
pdld -s -nostdlib --no-insert-timestamp --image-base 0x400000 -o pdmake.exe ../pdpclib/w32start.obj main.obj read.obj rule.obj variable.obj xmalloc.obj hashtab.obj ../pdpclib/x64supb.obj ../pdpclib/msvcrt.lib
C:\devel\pdos\pdmake>pdmake --help
before
C:\devel\pdos\pdmake>
C:\devel\pdos\pdmake>git diff .
diff --git a/pdmake/hashtab/hashtab.c b/pdmake/hashtab/hashtab.c
index 57184ed4..00e43d9b 100644
--- a/pdmake/hashtab/hashtab.c
+++ b/pdmake/hashtab/hashtab.c
@@ -18,6 +18,7 @@
#include <math.h>
#include <stddef.h>
+#include <stdio.h>
#include "hashtab.h"
@@ -85,6 +86,7 @@ static int rehash (struct hashtab *hashtab, size_t target_size)
{
struct hashtab old_hashtab = *hashtab;
struct hashtab_entry *entry;
+ double ggg;
size_t i;
@@ -96,6 +98,11 @@ static int rehash (struct hashtab *hashtab, size_t target_size)
}
hashtab->probe_limit = max (internal_log2 (hashtab->size), MINIMAL_PROBE_LIMIT);
+
+ printf("before\n");
+ ggg = hashtab->max_load_factor * hashtab->size;
+ printf("after\n");
+
hashtab->max_number_of_elements = ceil (hashtab->max_load_factor * hashtab->size);
/* Allocates size + probe_limit + 1 so no bounds checking needs to be done. */
C:\devel\pdos\pdmake>
A double multiplied by a long long is crashing.
If I cast the long long to int, it doesn't crash.
Code is all in sourceforge.
Note that it could be related to the assembler support
routines. We have converted some of your bcclib.asm
into intel syntax, which can be found here:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/x64supb.asm
And relevant stuff copied here, in case you can see
something we have done wrong in the conversion:
# These routines were copied (and then modified) from bcclib.asm generated
# by the public domain cc64, and are used for cc64
# (Converted to PDAS .intel_syntax noprefix by guessing.)
.globl m$ufloat_r64u32
m$ufloat_r64u32:
mov ecx, ecx # clear top half (already done if value just moved there)
cvtsi2sd xmm15, rcx
ret
.globl m$ufloat_r32u32
m$ufloat_r32u32:
mov ecx, ecx
cvtsi2ss xmm15, rcx
ret
.globl m$ufloat_r64u64
m$ufloat_r64u64:
cmp ecx, 0
jl fl1
#number is positive, so can treat like i64
cvtsi2sd xmm15, rcx
ret
fl1: #negative value
and rcx, QWORD PTR mask63[rip] #clear top bit (subtract 2**63)
cvtsi2sd xmm15, rcx
addsd xmm15, QWORD PTR offset64[rip] #(add 2**63 back to result)
ret
.globl m$ufloat_r32u64
m$ufloat_r32u64:
cmp ecx, 0
jl fl2
#number is positive, so can treat like i64
cvtsi2ss xmm15, rcx
ret
fl2: #negative value
and rcx, QWORD PTR mask63[rip] #clear top bit (subtract 2**63)
cvtsi2ss xmm15, rcx
addss xmm15, DWORD PTR offset32[rip] #(add 2**63 back to result)
ret
.section rdata
mask63:
.quad 0x7fffffffffffffff
offset64:
.quad 9223372036854775808 # 2**63 as r64
offset32:
.quad 9223372036854775808 # 2**63 as r32
Thanks. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-31 12:56 -0700 |
| Message-ID | <87sf7z7zqf.fsf@nosuchdomain.example.com> |
| In reply to | #173407 |
Bart <bc@freeuk.com> writes:
[...]
> I can confirm that I've started an overhaul of the project, which will
> have a working title of 'DD' to distinguish it from 'CC'. The first
> stage is to get it to generate a new intermediate (IL) code (perhaps
> within a week).
There's a common Unix file conversion tool called "dd". Do whatever you
like with that information.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-31 22:09 +0000 |
| Message-ID | <dc8IM.249422$f7Ub.232818@fx47.iad> |
| In reply to | #173427 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >Bart <bc@freeuk.com> writes: >[...] >> I can confirm that I've started an overhaul of the project, which will >> have a working title of 'DD' to distinguish it from 'CC'. The first >> stage is to get it to generate a new intermediate (IL) code (perhaps >> within a week). > >There's a common Unix file conversion tool called "dd". Do whatever you >like with that information. For consistency, since 'cc' stands for 'C Compiler', he should use 'dc', for 'D Compiler'. But that conflicts with the standard 'desktop RPN calculator' application, dc.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-01 10:12 +0200 |
| Message-ID | <ucs6e7$3mt8r$1@dont-email.me> |
| In reply to | #173446 |
On 01/09/2023 00:09, Scott Lurndal wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> Bart <bc@freeuk.com> writes: >> [...] >>> I can confirm that I've started an overhaul of the project, which will >>> have a working title of 'DD' to distinguish it from 'CC'. The first >>> stage is to get it to generate a new intermediate (IL) code (perhaps >>> within a week). >> >> There's a common Unix file conversion tool called "dd". Do whatever you >> like with that information. > > For consistency, since 'cc' stands for 'C Compiler', he should > use 'dc', for 'D Compiler'. But that conflicts with the standard > 'desktop RPN calculator' application, dc. > And there is also an existing language called D. (I don't know if there is a standard name for a D compiler.) "bc" is also taken, otherwise that might have been a good choice.
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2023-08-31 23:53 -0700 |
| Message-ID | <3f29b9e1-c742-481a-9c12-3160b98a3dbbn@googlegroups.com> |
| In reply to | #173406 |
On Thursday, August 31, 2023 at 10:43:25 PM UTC+8, Paul Edwards wrote:
> On Thursday, August 31, 2023 at 9:45:14 PM UTC+8, Bart wrote:
>
> > I realise the code generator on BCC is poor, and is buggy, which is why
> > I kept it as a private tool. (/My/ C code is very conservative; there it
> > works fine!)
> Ok, thanks. I'll see if I can rework the C code to be conservative.
It took a while, but I was successful:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cpplib/directs.c
/* cc64 goes haywire when this is a const - it treats the array as
a character array, so indexing goes up by 1 character instead of
element size. And sizeof returns the padded size, but the data
is stored without padding, which made diagnosing very difficult */
#ifdef __CC64__
#define const
#endif
static const directive directives[] = {
DIRECTIVE_TABLE
};
#ifdef __CC64__
#undef const
#endif
(note that this problem is unrelated to the problem I sent via
email - as far as I am aware, anyway).
BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-31 14:39 +0000 |
| Message-ID | <PC1IM.472122$xMqa.233853@fx12.iad> |
| In reply to | #173400 |
Paul Edwards <mutazilah@gmail.com> writes: >On Thursday, August 31, 2023 at 6:59:08=E2=80=AFPM UTC+8, Bart wrote: > >> BTW the -out option is not needed here. The output file uses the same=20 >> filename and the same path, just the extension is changed. > >Ok, thanks for the info. > >Next problem I have encountered is this: Please take it to email. This is not relevent to comp.lang.c.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-31 20:56 +0100 |
| Message-ID | <87r0njkmue.fsf@bsb.me.uk> |
| In reply to | #173405 |
scott@slp53.sl.home (Scott Lurndal) writes: > Paul Edwards <mutazilah@gmail.com> writes: >>Ok, thanks for the info. >> >>Next problem I have encountered is this: > > Please take it to email. This is not relevent to comp.lang.c. It is certainly niche, but it's all about C. I'd say these posts are among the most topical there have been in a while. As it happens, they don't interest me much, but that not the same thing at all. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-31 14:36 +0200 |
| Message-ID | <ucq1gd$39q14$1@dont-email.me> |
| In reply to | #173397 |
On 31/08/2023 12:58, Bart wrote: > On 30/08/2023 23:54, Paul Edwards wrote: >> Hi Bart. >> >> Next error I have is: >> >> cc64 -c -out:cclib/cclib.obj cclib/cclib.i >> Compiling cclib/cclib.i to cclib/cclib.obj > > > BTW the -out option is not needed here. The output file uses the same > filename and the same path, just the extension is changed. > > So the generated .obj file is in the same folder as the .c or .i source > file. The same applies when generating executables; you can compile code > remotely. > > Other C compilers may be different; gcc for example applies the right > extension, but the object file (or executable) is written to the current > directory. And others tend to copy gcc. > Putting object files (or other generated files) in the same directory as the source files is okay for small projects. If you've only got a half-dozen source files, it can be tidy to keep them all in the same directory. If you are doing something bigger you almost invariably want to keep the source tree and the generated files in separate directories. It makes it much easier to see what's changed, to clean out object files, to track source in a revision control system of some kind, to find the source files amongst all the generated files, etc. Details, of course, vary by person and project - too many directories and subdirectories makes it hard to keep an overview of the files, as does too few directories. This is known as "out of tree builds", and is the norm for most projects above a certain size. So whatever your default here - whether it is generating the object file in the same directory as the source file, or generating it in the current directory - it will be convenient in some cases, and completely wrong in other cases. So IMHO it's a good habit to have an "-out" (or equivalent) option in your build files - then you know exactly where things are going. People who use "make" have simple and common shortcuts for this. Since you prefer not to use "make" or any alternative build system, you might want to at least add an option to specify an output directory. Then, for example, "cc64 -c -outdir:build src/file.c" would put the output object file as "build/src/file.obj". You want to copy the directory structure in the build directory, since a project written by several people might coincidentally have matching filenames in different directories.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-31 15:30 +0100 |
| Message-ID | <ucq86h$3auvq$1@dont-email.me> |
| In reply to | #173401 |
On 31/08/2023 13:36, David Brown wrote:
> On 31/08/2023 12:58, Bart wrote:
>> On 30/08/2023 23:54, Paul Edwards wrote:
>>> Hi Bart.
>>>
>>> Next error I have is:
>>>
>>> cc64 -c -out:cclib/cclib.obj cclib/cclib.i
>>> Compiling cclib/cclib.i to cclib/cclib.obj
>>
>>
>> BTW the -out option is not needed here. The output file uses the same
>> filename and the same path, just the extension is changed.
>>
>> So the generated .obj file is in the same folder as the .c or .i
>> source file. The same applies when generating executables; you can
>> compile code remotely.
>>
>> Other C compilers may be different; gcc for example applies the right
>> extension, but the object file (or executable) is written to the
>> current directory. And others tend to copy gcc.
>>
>
> Putting object files (or other generated files) in the same directory as
> the source files is okay for small projects. If you've only got a
> half-dozen source files, it can be tidy to keep them all in the same
> directory.
>
> If you are doing something bigger you almost invariably want to keep the
> source tree and the generated files in separate directories. It makes
> it much easier to see what's changed, to clean out object files, to
> track source in a revision control system of some kind, to find the
> source files amongst all the generated files, etc. Details, of course,
> vary by person and project - too many directories and subdirectories
> makes it hard to keep an overview of the files, as does too few
> directories. This is known as "out of tree builds", and is the norm for
> most projects above a certain size.
>
> So whatever your default here - whether it is generating the object file
> in the same directory as the source file, or generating it in the
> current directory - it will be convenient in some cases, and completely
> wrong in other cases.
But putting it in the current directory is sloppy. The current location
can be arbitrary (or it might not be writeable):
c:\random>gcc \proj1\foo.c
c:\random>gcc \proj2\bar.c
Here, both compilations generate a.exe. But to cap that, both end up in
c:\random; the second overwrites the first, something you might be
unaware of.
If I do:
c:\random>gcc \proj1\foo.c
c:\random>gcc \proj2\bar.c
then there are three differences from gcc:
(1) The executables are called foo.exe and bar.exe respectively
(2) They are written to their respective folders
(3) The compiler will report exactly what it is doing so there
are fewer surprises:
Compiling \proj1\foo.c to \proj2\foo.exe
You can use -v with gcc, but it is not helpful!
> So IMHO it's a good habit to have an "-out" (or equivalent) option in
> your build files - then you know exactly where things are going.
>
> People who use "make" have simple and common shortcuts for this. Since
> you prefer not to use "make" or any alternative build system, you might
> want to at least add an option to specify an output directory. Then,
> for example, "cc64 -c -outdir:build src/file.c"
Actually I have exactly that option, called '-outpath', but in my main
compilers; I haven't put it into bcc because bcc is an older project.
[toc] | [prev] | [next] | [standalone]
Page 2 of 18 — ← Prev page 1 [2] 3 4 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web