Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #106122 > unrolled thread

More problems with lcc-win

Back to article view | Back to comp.lang.c

Contents

  More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 00:29 -0700
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 11:27 +0100
      Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 13:18 +0000
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 15:22 +0100
          Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:26 -0700
      Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:25 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 16:46 +0100
          Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-15 17:07 +0100
            Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 09:52 -0700
              Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 16:57 +0000
                Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 10:11 -0700
                  Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 18:17 +0000
              Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 17:21 +0000
                Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-15 18:42 +0100
                  Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 18:20 +0000
                    Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 18:59 +0000
                  Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-15 18:20 +0000
                    Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-15 19:39 +0100
                    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 12:44 -0700
                      Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-15 20:19 +0000
                        Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 10:03 +0100
                          Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-16 11:15 +0000
                            Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-16 11:32 +0000
                            Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 13:41 +0100
                    Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-16 08:52 +0100
                    Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 09:57 +0100
                  Re: More problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-16 13:53 +0000
                    Re: More problems with lcc-win jm.bourguet@gmail.com - 2017-03-16 07:14 -0700
                    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-16 08:59 -0700
                Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 12:43 -0700
                  Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 20:39 +0000
              Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:56 +0100
          Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 16:33 +0000
            Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 17:47 +0100
              Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 10:04 -0700
                Re: More problems with lcc-win jacob navia <jacob@jacob.remcomp.fr> - 2017-03-16 00:52 +0100
                  Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 18:02 -0700
                    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 18:23 -0700
                      Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 13:45 -0700
                        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:23 +0100
                          Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:29 +0100
                            Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:31 +0100
                            Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 17:01 -0700
                              Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-20 16:41 +0000
                                Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-20 18:32 +0100
                                  Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-20 18:18 +0000
                                    Re: More problems with lcc-win bart4858@gmail.com - 2017-03-20 12:31 -0700
                                      Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-20 21:05 +0100
                                        Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-20 20:45 +0000
                                      Re: More problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-20 20:18 +0000
                                      Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-21 09:56 +0100
                                        Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-21 21:08 +0000
                                          Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-21 22:19 +0100
                                            Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-22 06:29 +0000
                                          Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-21 16:12 -0700
                                            Re: More problems with lcc-win gordonb.s97bd@burditt.org (Gordon Burditt) - 2017-03-24 01:13 -0500
                                              Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-24 08:16 -0700
                                            Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-26 03:18 -0700
                                              Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-26 12:35 +0100
                                                Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:17 -0700
                                              Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-26 14:04 -0700
                                                Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:48 -0700
                                          Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-21 23:21 +0000
                                            Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-22 06:18 +0000
                                          Re: More problems with lcc-win gordonb.1neik@burditt.org (Gordon Burditt) - 2017-03-21 18:45 -0500
                                          Re: More problems with lcc-win jm.bourguet@gmail.com - 2017-03-22 01:02 -0700
                                          Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-22 10:35 +0100
                                          Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-22 13:21 +0000
                                            Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-22 14:08 +0000
                                              Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-22 15:37 +0000
                                          Re: More problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-22 21:09 +0000
                                      Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 13:09 +0000
                                        Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-21 21:15 +0000
                          Re: More problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-18 12:44 +1300
                          Re: More problems with lcc-win jameskuyper@verizon.net - 2017-03-17 16:59 -0700
                        Re: charsets Noob <root@127.0.0.1> - 2017-03-18 18:30 +0100
                  Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 10:18 +0100
              Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 15:06 -0700
                Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 22:23 +0000
                  Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 15:43 -0700
                    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:53 +0100
                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 08:35 -0700
                    Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 23:13 +0000
                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 06:28 -0700
                        Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-16 16:56 +0000
                          Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 14:53 -0700
                Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 16:18 -0700
                  Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-16 18:03 +0000
                    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-16 19:29 +0100
                      Re: More problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-16 21:38 +0000
                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-17 08:58 -0700
                  Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 09:45 -0700
                    Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-17 10:33 -0700
                      Re: More problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-17 14:20 -0400
                      Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-17 20:18 +0100
                        Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 00:44 -0700
                          Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-18 13:31 +0000
                            Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 15:54 -0700
                            Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-20 13:27 +0000
                          Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 15:15 +0100
                            Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 11:39 -0700
                              Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 20:11 +0100
                                Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-18 19:45 +0000
                                  Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-20 00:35 -0700
                                Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 14:22 -0700
                                  Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 22:46 +0100
                                    Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 16:12 -0700
                                    Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-18 18:01 -0700
                                      Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 03:21 +0100
                                        Re: More problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-19 15:32 +1300
                                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-19 02:17 -0700
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:25 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:49 +0100
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 11:28 +0100
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:35 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:44 +0100
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 13:06 +0100
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:43 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:43 +0100
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 13:19 +0100
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:50 -0700
    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:24 -0700
      Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 16:47 +0100
        Re: More problems with lcc-win jameskuyper@verizon.net - 2017-03-15 09:04 -0700
        Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 09:15 -0700
          Re: More problems with lcc-win gazelle@shell.xmission.com (Kenny McCormack) - 2017-03-15 19:59 +0000
        Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 16:32 +0000

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

#106199

Le 15/03/2017 à 23:43, mertesthomas@gmail.com a écrit :
> Am Mittwoch, 15. März 2017 23:23:10 UTC+1 schrieb Richard Heathfield:
>> On 15/03/17 22:06, mertesthomas wrote:
>> <snip>
>>>
>>> AFAIK the standard writers introduced fseeko and ftello, which works
>>> with offsets of type off_t. Off_t does not depend on the size of long
>>> and can be 32-bit or 64-bit.
>>
>> I can find no reference to these functions (fseeko and ftello) in my
>> copy of the Standard. Am I out of date again?
>
> See: http://pubs.opengroup.org/onlinepubs/009695399/functions/fseek.html
>
>

Look writing a posix library is not something I can do myself ok?

I built a C library and it took me an enormous effort, and I am fed up 
with it ok? The C99 standard is not fully implemented, I have bugs in 
the code generation as you see, there is a lot of work to do and fseek 
takes a long long and that problem is solved.

Thanks

[toc] | [prev] | [next] | [standalone]

#106250

Am Mittwoch, 15. März 2017 23:53:39 UTC+1 schrieb jacob navia:
> Le 15/03/2017 à 23:43, mertesthomas a écrit :
> > Am Mittwoch, 15. März 2017 23:23:10 UTC+1 schrieb Richard Heathfield:
> >> On 15/03/17 22:06, mertesthomas wrote:
> >> <snip>
> >>>
> >>> AFAIK the standard writers introduced fseeko and ftello, which works
> >>> with offsets of type off_t. Off_t does not depend on the size of long
> >>> and can be 32-bit or 64-bit.
> >>
> >> I can find no reference to these functions (fseeko and ftello) in my
> >> copy of the Standard. Am I out of date again?
> >
> > See: http://pubs.opengroup.org/onlinepubs/009695399/functions/fseek.html
> >
> >
> 
> Look writing a posix library is not something I can do myself ok?
> 
> I built a C library and it took me an enormous effort, and I am fed up 
> with it ok? The C99 standard is not fully implemented, I have bugs in 
> the code generation as you see, there is a lot of work to do and fseek 
> takes a long long and that problem is solved.
> 
> Thanks

Sorry to bring so much stress to you. I invested a considerable
amount of time to provide the test programs and the problem descriptions.
I don't expect that you fix the bugs for me. Its your product and you
decide. I am happy, when you shelve the test programs and problem
descriptions somewhere and look at them later, when you have less stress.
Of cause you could also ignore my stuff. In that case my time was
wasted. But I can live with that.

BTW. For the first time I succeeded compiling with lcc-win 64-bit.
Linking failed with:

con_win.obj .text: undefined reference to 'kbhit'
con_win.obj .text: undefined reference to 'getch'
fil_win.obj .text: undefined reference to '_open_osfhandle'
fil_win.obj .text: undefined reference to '_close'
fil_win.obj .text: undefined reference to 'fdopen'
pol_sel.obj .text: undefined reference to '__imp_select'
pol_sel.obj .text: undefined reference to '__WSAFDIsSet'
sql_post.obj .text: undefined reference to '__imp_ntohl'
sql_post.obj .text: undefined reference to '__imp_htons'
sql_post.obj .text: undefined reference to '__imp_htonl'
sql_post.obj .text: undefined reference to '__imp_ntohs'
stat_win.obj .text: undefined reference to '_wcsicmp'


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows. 

[toc] | [prev] | [next] | [standalone]

#106203

On 15/03/17 22:43, mertesthomas@gmail.com wrote:
> Am Mittwoch, 15. März 2017 23:23:10 UTC+1 schrieb Richard Heathfield:
>> On 15/03/17 22:06, mertesthomas wrote:
>> <snip>
>>>
>>> AFAIK the standard writers introduced fseeko and ftello, which works
>>> with offsets of type off_t. Off_t does not depend on the size of long
>>> and can be 32-bit or 64-bit.
>>
>> I can find no reference to these functions (fseeko and ftello) in my
>> copy of the Standard. Am I out of date again?
>
> See: http://pubs.opengroup.org/onlinepubs/009695399/functions/fseek.html

Ah, that explains it. That's the POSIX Standard, not the C Standard. 
Sorry for the confusion. (In this group, the vanilla word "standard" is 
taken to mean ISO/IEC 9899, not ISO/IEC 9945.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#106244

Am Donnerstag, 16. März 2017 00:14:04 UTC+1 schrieb Richard Heathfield:
> On 15/03/17 22:43, mertesthomas wrote:
> > Am Mittwoch, 15. März 2017 23:23:10 UTC+1 schrieb Richard Heathfield:
> >> On 15/03/17 22:06, mertesthomas wrote:
> >> <snip>
> >>>
> >>> AFAIK the standard writers introduced fseeko and ftello, which works
> >>> with offsets of type off_t. Off_t does not depend on the size of long
> >>> and can be 32-bit or 64-bit.
> >>
> >> I can find no reference to these functions (fseeko and ftello) in my
> >> copy of the Standard. Am I out of date again?
> >
> > See: http://pubs.opengroup.org/onlinepubs/009695399/functions/fseek.html
> 
> Ah, that explains it. That's the POSIX Standard, not the C Standard. 
> Sorry for the confusion. (In this group, the vanilla word "standard" is 
> taken to mean ISO/IEC 9899, not ISO/IEC 9945.)

I am not able to restrict my programs to the C standard.
The portability of Seed7 goes beyond the portability of C.
I created driver libraries to balance various differences:
Os access (POSIX vs. Win32), Unicode (UTF-8 vs. UTF-16),
graphics (X11 vs. GDI), sockets (BSD vs. winsock),
dynamic linking (.so vs. .dll), processes (fork vs. CreateProcess),
databases (MySql/MariaDb, SQLLite, PostgreSQL, Oracle and Odbc),
read directories (opendir vs. FindFirstFile), and much more.

Even in areas covered by standard C such as fseek there are
big differences. Depending on operating system and compiler
Seed7 uses fseek, fseeko, fseeko64 and fseeki64.

Some of the decisions (which function should be used, etc.)
are done in the makefile (every compiler-os combination has
its own makefile). Most of the decisions are done by a test
program (chkccomp.c) that tests properties of C compiler,
run-time and operating system. During the build process the
file version.h, which contains #define directives, is created.
When somebody has problems building Seed7 I can inspect the
file version.h to see the properties of his computer.

To show how much decisions must be done for a portable program
I have inserted my version.h file:
#define PATH_DELIMITER '/'
#define SEARCH_PATH_DELIMITER ':'
#define NULL_DEVICE "/dev/null"
#define USE_MMAP
#define AWAIT_WITH_SELECT
#define WITH_SQL
#define USE_TERMINFO
#define SIGNAL_HANDLER_CAN_DO_IO
#define CONSOLE_UTF8
#define OS_STRI_UTF8
#define _FILE_OFFSET_BITS 64
#define os_fseek fseeko
#define os_ftell ftello
#define os_off_t off_t
#define os_environ environ
#define USE_GETADDRINFO
#define ESCAPE_SHELL_COMMANDS
#define USE_BIG_RTL_LIBRARY
#define OBJECT_FILE_EXTENSION ".o"
#define LIBRARY_FILE_EXTENSION ".a"
#define C_COMPILER "clang"
#define CPLUSPLUS_COMPILER "clang -x c++"
#define GET_CC_VERSION_INFO "clang --version >"
#define CC_SOURCE_UTF8
#define CC_OPT_DEBUG_INFO "-g"
#define CC_OPT_NO_WARNINGS "-w"
#define CC_FLAGS "-ffunction-sections -fdata-sections -ftrapv"
#define CC_ERROR_FILDES 2
#define LINKER_OPT_NO_DEBUG_INFO "-Wl,--strip-debug"
#define LINKER_OPT_OUTPUT_FILE "-o "
#define LINKER_FLAGS "-Wl,--gc-sections"
#define SYSTEM_LIBS "-lm -ldl"
#define SYSTEM_CONSOLE_LIBS "-lncurses"
#define SYSTEM_DRAW_LIBS "-lX11"
#define C_COMPILER_VERSION "Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based on LLVM 3.4)"
#define UNISTD_H_PRESENT 1
#define HAS_SIGNAL 1
#define HAS_SIGACTION 1
#define SIGNAL_RESETS_HANDLER 0
#define likely(x)   __builtin_expect((x),1)
#define unlikely(x) __builtin_expect((x),0)
#define NORETURN __attribute__ ((noreturn))
#define MACRO_DEFS "#define likely(x)   __builtin_expect((x),1)\n#define unlikely(x) __builtin_expect((x),0)\n#define NORETURN __attribute__ ((noreturn))\n"
#define USE_DIRENT
#define FOPEN_SUPPORTS_CLOEXEC_MODE 1
#define HAS_FCNTL_SETFD_CLOEXEC 1
#define HAS_PIPE2 0
#define HAS_POPEN 1
#define POPEN_SUPPORTS_BINARY_MODE 0
#define POPEN_SUPPORTS_TEXT_MODE 0
#define POPEN_SUPPORTS_CLOEXEC_MODE 1
#define FTELL_SUCCEEDS_FOR_PIPE 0
#define STDOUT_IS_IN_TEXT_MODE 0
#define FILENO_WORKS_FOR_NULL 0
#define FSEEK_SUCCEEDS_FOR_STDIN 0
#define FOPEN_OPENS_DIRECTORIES 1
#define FWRITE_WRONG_FOR_READ_ONLY_FILES 0
#define REMOVE_FAILS_FOR_EMPTY_DIRS 0
#define OS_PATH_HAS_DRIVE_LETTERS 0
#define HOME_DIR_ENV_VAR {'H', 'O', 'M', 'E', 0}
#define EXDEV_IS_DEFINED
#define CHAR_SIZE 8
#define SHORT_SIZE 16
#define INT_SIZE 32
#define LONG_SIZE 64
#define LONG_LONG_SIZE 64
#define POINTER_SIZE 64
#define FLOAT_SIZE 32
#define DOUBLE_SIZE 64
#define WCHAR_T_SIZE 32
#define OS_OFF_T_SIZE 64
#define TIME_T_SIZE 64
#define TIME_T_SIGNED 1
#define SIZE_T_SIGNED 0
#define CHAR_SIGNED 1
#define BOOLTYPE _Bool
#define BOOLTYPE_STRI "_Bool"
#define INT8TYPE signed char
#define INT8TYPE_STRI "signed char"
#define UINT8TYPE unsigned char
#define UINT8TYPE_STRI "unsigned char"
#define INT16TYPE short int
#define INT16TYPE_STRI "short int"
#define UINT16TYPE unsigned short int
#define UINT16TYPE_STRI "unsigned short int"
#define INT32TYPE int
#define INT32TYPE_STRI "int"
#define UINT32TYPE unsigned int
#define UINT32TYPE_STRI "unsigned int"
#define INT32_SUFFIX(num) num
#define UINT32_SUFFIX(num) num ## U
#define INT32TYPE_LITERAL_SUFFIX ""
#define INT32TYPE_FORMAT ""
#define INT64TYPE long
#define INT64TYPE_STRI "long"
#define UINT64TYPE unsigned long
#define UINT64TYPE_STRI "unsigned long"
#define INT64_SUFFIX(num) num ## L
#define UINT64_SUFFIX(num) num ## UL
#define INT64TYPE_LITERAL_SUFFIX "L"
#define INT64TYPE_FORMAT "l"
#define INTPTR_T_DEFINED
#define RSHIFT_DOES_SIGN_EXTEND 1
#define TWOS_COMPLEMENT_INTTYPE 1
#define ONES_COMPLEMENT_INTTYPE 0
#define LITTLE_ENDIAN_INTTYPE 1
#define BIG_ENDIAN_INTTYPE 0
#define CHECK_INT_DIV_BY_ZERO 1
#define CHECK_INT_REM_BY_ZERO 1
#define CHECK_INT_REM_ZERO_BY_ZERO 1
#define OVERFLOW_SIGNAL SIGILL
#define OVERFLOW_SIGNAL_STR "SIGILL"
#define ROUND_HALF_TO_EVEN
#define PRINTF_SUPPORTS_VARIABLE_FORMATS 1
#define DOUBLE_MIN_EXP10 -308
#define DOUBLE_MAX_EXP10 308
#define MIN_PRINTED_EXPONENT_DIGITS 2
#define MAX_PRINTED_EXPONENT_DIGITS 3
#define FMT_E_FLT "%1.5e"
#define FLOAT_STR_LARGE_NUMBER 1.0e6
#define FMT_E_DBL "%1.14e"
#define DOUBLE_STR_LARGE_NUMBER 1.0e15
#define CAST_INT_TO_FLOAT_OKAY 1
#define HAS_LOG2 1
#define HAS_CBRT 0
#define CHECK_FLOAT_DIV_BY_ZERO 0
#define USE_NEGATIVE_ZERO_BITPATTERN 0
#define os_isnan isnan
#define OS_ISNAN_DEFINITION "#define os_isnan isnan\n"
#define HAS_EXP 1
#define HAS_EXP2 1
#define HAS_EXP10 0
#define FREXP_INFINITY_NAN_OKAY 1
#define FLOAT_ZERO_TIMES_INFINITE_OKAY 1
#define NAN_COMPARISON_OKAY 1
#define NAN_MULTIPLICATION_OKAY 1
#define NAN_DIVISION_OKAY 1
#define MAX_ODD_FLOAT 16777215.0
#define MAX_ODD_DOUBLE 9007199254740991.0
#define POW_OF_NAN_OKAY 1
#define POW_OF_ZERO_OKAY 1
#define POW_OF_ONE_OKAY 1
#define POW_EXP_NAN_OKAY 1
#define POW_EXP_MINUS_INFINITY_OKAY 1
#define POW_UNDERFLOW_WITH_SIGN 0
#define SQRT_FUNCTION_OKAY 1
#define PRINTS_NEGATIVE_ZERO 1
#define os_isinf isinf
#define FLOAT_TO_INT_OVERFLOW_SATURATES
#define INT_RANGE_IN_FLOAT_MAX 16777216
#define FLOAT_MANTISSA_FACTOR 16777216.0
#define FLOAT_MANTISSA_SHIFT 24
#define INT_RANGE_IN_DOUBLE_MAX 9007199254740992
#define DOUBLE_MANTISSA_FACTOR 9007199254740992.0
#define DOUBLE_MANTISSA_SHIFT 53
#define STRTOD_ACCEPTS_HEX_NUMBERS 1
#define ATOF_ACCEPTS_HEX_NUMBERS 1
#define STRTOD_ACCEPTS_DENORMAL_NUMBERS 1
#define ATOF_ACCEPTS_DENORMAL_NUMBERS 1
#define MALLOC_ALIGNMENT 4
#define UNALIGNED_MEMORY_ACCESS_OKAY 1
#define CASTING_GETS_A_UNION_ELEMENT 1
#define TRIGRAPH_SEQUENCES_ARE_REPLACED 0
#define STACK_GROWS_DOWNWARD
#define STACK_SIZE 0x1000000
#define USE_LOCALTIME_R
#define LOCALTIME_WORKS_SIGNED 1
#define DECLARE_OS_ENVIRON 1
#define USE_GET_ENVIRONMENT 0
#define INITIALIZE_OS_ENVIRON 0
#define HAS_GETRLIMIT 1
#define SOFT_STACK_LIMIT 0
#define HARD_STACK_LIMIT 0
#define HAS_WMEMCMP 1
#define HAS_WMEMCHR 1
#define HAS_WMEMSET 1
#define HAS_SETJMP 1
#define HAS_SIGSETJMP 1
#define HAS_SYMBOLIC_LINKS 1
#define HAS_READLINK 1
#define HAS_FIFO_FILES 1
#define HAS_POLL 1
#define MYSQL_INCLUDE "mysql/mysql.h"
#define SQLITE_INCLUDE "sqlite3.h"
#define POSTGRESQL_INCLUDE "libpq-fe.h"
#define POSTGRESQL_POSTGRES_H "postgres.h"
#define POSTGRESQL_PG_TYPE_H "catalog/pg_type.h"
#define ODBC_INCLUDE_SQLEXT
#define ODBC_INCLUDE "sql.h"
#define OCI_INCLUDE "db_oci.h"
#define OCI_DLL "libclntsh.so",
#define INCLUDE_OPTIONS "-I/usr/include/postgresql"
#define SYSTEM_DB_LIBS "-lmysqlclient\n-lsqlite3\n-lpq\n-lodbc"
#define read_buffer_empty(fp) ((fp)->_IO_read_ptr >= (fp)->_IO_read_end)
#define SEED7_LIB "seed7_05.a"
#define CONSOLE_LIB "s7_con.a"
#define DRAW_LIB "s7_draw.a"
#define COMP_DATA_LIB "s7_data.a"
#define COMPILER_LIB "s7_comp.a"
#define S7_LIB_DIR "/media/disk2_460GiB/home/tm/seed7_5/bin"
#define SEED7_LIBRARY "/media/disk2_460GiB/home/tm/seed7_5/prg"

When the compilation of the interpreter and the compiler succeeds
the Seed7 test suite (chk_all.sd7) is executed. In total the test
suite consists of 80000 lines. This test programs are interpreted
and compiled with various options (they are executed 11 times).

When the test suite fails because of a buggy C compiler or C
run-time library it costs some time to create a C test program
for this bug. Over the years I found several bugs in C compilers
and run-time libraries.

Sorry to digress...


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows. 

[toc] | [prev] | [next] | [standalone]

#106254

On 16/03/17 13:28, mertesthomas@gmail.com wrote:
> Am Donnerstag, 16. März 2017 00:14:04 UTC+1 schrieb Richard Heathfield:
>> On 15/03/17 22:43, mertesthomas wrote:
>>> Am Mittwoch, 15. März 2017 23:23:10 UTC+1 schrieb Richard Heathfield:
>>>> On 15/03/17 22:06, mertesthomas wrote:
>>>> <snip>
>>>>>
>>>>> AFAIK the standard writers introduced fseeko and ftello, which works
>>>>> with offsets of type off_t. Off_t does not depend on the size of long
>>>>> and can be 32-bit or 64-bit.
>>>>
>>>> I can find no reference to these functions (fseeko and ftello) in my
>>>> copy of the Standard. Am I out of date again?
>>>
>>> See: http://pubs.opengroup.org/onlinepubs/009695399/functions/fseek.html
>>
>> Ah, that explains it. That's the POSIX Standard, not the C Standard.
>> Sorry for the confusion. (In this group, the vanilla word "standard" is
>> taken to mean ISO/IEC 9899, not ISO/IEC 9945.)
>
> I am not able to restrict my programs to the C standard.

Nobody's saying you should. But in /this/ group we discuss standard C, 
not variants such as POSIX. I believe POSIX is topical in 
comp.unix.programmer.

> The portability of Seed7 goes beyond the portability of C.

Impressive (if true).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#106287

Am Donnerstag, 16. März 2017 17:56:11 UTC+1 schrieb Richard Heathfield:
> On 16/03/17 13:28, mertesthomas wrote:
> > Am Donnerstag, 16. März 2017 00:14:04 UTC+1 schrieb Richard Heathfield:
> >> On 15/03/17 22:43, mertesthomas wrote:
> >>> Am Mittwoch, 15. März 2017 23:23:10 UTC+1 schrieb Richard Heathfield:
> >>>> On 15/03/17 22:06, mertesthomas wrote:
> >>>> <snip>
> >>>>>
> >>>>> AFAIK the standard writers introduced fseeko and ftello, which works
> >>>>> with offsets of type off_t. Off_t does not depend on the size of long
> >>>>> and can be 32-bit or 64-bit.
> >>>>
> >>>> I can find no reference to these functions (fseeko and ftello) in my
> >>>> copy of the Standard. Am I out of date again?
> >>>
> >>> See: http://pubs.opengroup.org/onlinepubs/009695399/functions/fseek.html
> >>
> >> Ah, that explains it. That's the POSIX Standard, not the C Standard.
> >> Sorry for the confusion. (In this group, the vanilla word "standard" is
> >> taken to mean ISO/IEC 9899, not ISO/IEC 9945.)
> >
> > I am not able to restrict my programs to the C standard.
> 
> Nobody's saying you should. But in /this/ group we discuss standard C, 
> not variants such as POSIX. I believe POSIX is topical in 
> comp.unix.programmer.

Source code portability concerns POSIX and Windows (and possibly more).
In the operating system specific groups part of the discussion would
always be non topical.

> > The portability of Seed7 goes beyond the portability of C.
> 
> Impressive (if true).

Well, it is true, but I am biased.
The things mentioned before (the Seed7 build process and the
file version.h) should indicate good portability. But you can
prove yourself, if my claim is correct.

Even in the area of standard C there are several things to
consider for portable programming. There are different standards
(C90, C99) and not all C compilers/run-time libraries implement
all of a standard. So it is also necessary to find out how
much of the standard is implemented. Some defines of version.h
are for this purpose. E.g.:

#define SIGNAL_HANDLER_CAN_DO_IO
#define RSHIFT_DOES_SIGN_EXTEND 1
#define TWOS_COMPLEMENT_INTTYPE 1
#define ONES_COMPLEMENT_INTTYPE 0
#define LITTLE_ENDIAN_INTTYPE 1
#define BIG_ENDIAN_INTTYPE 0
#define ROUND_HALF_TO_EVEN
#define MALLOC_ALIGNMENT 4
#define TRIGRAPH_SEQUENCES_ARE_REPLACED 0


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#106204

mertesthomas@gmail.com writes:
[...]
> AFAIK the standard writers introduced fseeko and ftello, which works
> with offsets of type off_t. Off_t does not depend on the size of long
> and can be 32-bit or 64-bit.

fseeko() and ftello() are defined by POSIX, not by the ISO C standard.

Elsethread I suggested that a future ISO C standard should change
fseek() and ftell() to use a type other than long.  It looks like
fseeko() and ftello() are pretty much what I had in mind.

Ideally, I'd like to see fseek() and ftell() modified to match fseeko()
and ftello().  Changing the definition of an existing function could be
difficult, and implementations would undoubtedly have to support both
forms.

My second choice would be to adopt fseeko() and ftello() from POSIX
while leaving fseek() and ftell() as they are.

-- 
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]

#106258

Keith Thompson <kst-u@mib.org> writes:
>mertesthomas@gmail.com writes:
>[...]
>> AFAIK the standard writers introduced fseeko and ftello, which works
>> with offsets of type off_t. Off_t does not depend on the size of long
>> and can be 32-bit or 64-bit.
>
>fseeko() and ftello() are defined by POSIX, not by the ISO C standard.

The were defined by LFS and adopted by POSIX, IIRC.

http://www.unix.org/version2/whatsnew/lfs20mar.html

[toc] | [prev] | [next] | [standalone]

#106261

Le 16/03/2017 à 19:03, Scott Lurndal a écrit :
> Keith Thompson <kst-u@mib.org> writes:
>> mertesthomas@gmail.com writes:
>> [...]
>>> AFAIK the standard writers introduced fseeko and ftello, which works
>>> with offsets of type off_t. Off_t does not depend on the size of long
>>> and can be 32-bit or 64-bit.
>>
>> fseeko() and ftello() are defined by POSIX, not by the ISO C standard.
>
> The were defined by LFS and adopted by POSIX, IIRC.
>
> http://www.unix.org/version2/whatsnew/lfs20mar.html
>

I don't understand why the language must be complexified ad nauseaum.

Want to know where is the cursor position? Use fseek.

Why make it more complicated than that?

If we can accept that C now prescribes a whole new threading concepts 
and libraries why it is impossible to fix ftell?

Just make that second argument 64 bits and the problem is solved.

[toc] | [prev] | [next] | [standalone]

#106286

jacobnavia <jacob@jacob.remcomp.fr> writes:
<snip>
> I don't understand why the language must be complexified ad nauseaum.
>
> Want to know where is the cursor position? Use fseek.
<snip>
> Just make that second argument 64 bits and the problem is solved.

It's complicated by existing code.  Both compiled code that has to link
against static or dynamic libraries and source code.  For example, it's
valid to declare

  int fseek();

and to go ahead and use it.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#106354

Am Donnerstag, 16. März 2017 19:29:35 UTC+1 schrieb jacobnavia:
> Le 16/03/2017 à 19:03, Scott Lurndal a écrit :
> > Keith Thompson <kst-u> writes:
> >> mertesthomas writes:
> >> [...]
> >>> AFAIK the standard writers introduced fseeko and ftello, which works
> >>> with offsets of type off_t. Off_t does not depend on the size of long
> >>> and can be 32-bit or 64-bit.
> >>
> >> fseeko() and ftello() are defined by POSIX, not by the ISO C standard.
> >
> > The were defined by LFS and adopted by POSIX, IIRC.
> >
> > http://www.unix.org/version2/whatsnew/lfs20mar.html
> >
> 
> I don't understand why the language must be complexified ad nauseaum.
> 
> Want to know where is the cursor position? Use fseek.

That would be ftell. :-)

> Why make it more complicated than that?
> 
> If we can accept that C now prescribes a whole new threading concepts 
> and libraries why it is impossible to fix ftell?
> 
> Just make that second argument 64 bits and the problem is solved.

Not all run-time libraries would do this change immediate.
Some would do it and some would not do the change.
They would probably have good arguments to refuse this change.
You are not the only one who refuses a change. :-)
So the decision to make that second argument 64 bits would
trigger portability problems for many years.

Instead they decided to introduce the type off_t and the
functions ftello and fseeko. This way the old and the new way
can be kept separate. You can search source files for the
old or new seek functions. etc.

The situation is also complicated, because Microsoft decided
differently.

For all the possible seek functions I define macros.
For lcc-win64 I have defined:

#define os_off_t int64Type;
#define os_fseek fseek

I do not call fseek directly in my code.
Instead I call os_fseek. Practically I use a macro based
portability layer.

I can live with your decision regarding fseek, but other
things like wrong code or missing functions make problems.

Btw.: Have you seen my other message with the missing functions?


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#106360

Keith Thompson <kst-u@mib.org> writes:
> mertesthomas@gmail.com writes:
> [...]
>> AFAIK the standard writers introduced fseeko and ftello, which works
>> with offsets of type off_t. Off_t does not depend on the size of long
>> and can be 32-bit or 64-bit.
>
> fseeko() and ftello() are defined by POSIX, not by the ISO C standard.
>
> Elsethread I suggested that a future ISO C standard should change
> fseek() and ftell() to use a type other than long.  It looks like
> fseeko() and ftello() are pretty much what I had in mind.
>
> Ideally, I'd like to see fseek() and ftell() modified to match fseeko()
> and ftello().  Changing the definition of an existing function could be
> difficult, and implementations would undoubtedly have to support both
> forms.
>
> My second choice would be to adopt fseeko() and ftello() from POSIX
> while leaving fseek() and ftell() as they are.

On further thought, changing the declarations of fseek() and ftell()
would cause problems mixing code that uses the old and new versions.
There are probably ways to deal with that with clever linking, but
I now suggest that fseek() and ftell() should be left as they are
(and perhaps deprecated?), and fseeko(), ftello(), and off_t should
be adopted by a new C standard.

(Since lcc-win uses non-standard declarations for fseek() and ftell()
I wonder if that causes problems linking code compiled by lcc-win
with code compiled by other compilers.  Is that supported?)

-- 
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]

#106362

Am Freitag, 17. März 2017 17:45:48 UTC+1 schrieb Keith Thompson:
> Keith Thompson <kst-u> writes:
> > mertesthomas writes:
> > [...]
> >> AFAIK the standard writers introduced fseeko and ftello, which works
> >> with offsets of type off_t. Off_t does not depend on the size of long
> >> and can be 32-bit or 64-bit.
> >
> > fseeko() and ftello() are defined by POSIX, not by the ISO C standard.
> >
> > Elsethread I suggested that a future ISO C standard should change
> > fseek() and ftell() to use a type other than long.  It looks like
> > fseeko() and ftello() are pretty much what I had in mind.
> >
> > Ideally, I'd like to see fseek() and ftell() modified to match fseeko()
> > and ftello().  Changing the definition of an existing function could be
> > difficult, and implementations would undoubtedly have to support both
> > forms.
> >
> > My second choice would be to adopt fseeko() and ftello() from POSIX
> > while leaving fseek() and ftell() as they are.
> 
> On further thought, changing the declarations of fseek() and ftell()
> would cause problems mixing code that uses the old and new versions.
> There are probably ways to deal with that with clever linking, but
> I now suggest that fseek() and ftell() should be left as they are
> (and perhaps deprecated?), and fseeko(), ftello(), and off_t should
> be adopted by a new C standard.

Do you or others in this group have an influence about what will be
adopted by a new C standard?

In that case I would come up with some suggestions, what I would like
in a new C standard.

> (Since lcc-win uses non-standard declarations for fseek() and ftell()
> I wonder if that causes problems linking code compiled by lcc-win
> with code compiled by other compilers.  Is that supported?)

I guess that he does not care for code compiled by other compilers.
But this is just my guess.

Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#106371

On 03/17/2017 01:33 PM, mertesthomas@gmail.com wrote:
...
> Do you or others in this group have an influence about what will be
> adopted by a new C standard?

Not particularly. A proposed change to the standard can only be made by 
a committee member, though the member can pass on a proposal made by 
someone else. A small number of committee members used to regularly 
monitor this newsgroup (they paid more attention to comp.std.c), 
including the secretary of the committee. When that was the case, I 
think our discussions did have some influence - I've seen specific 
wording in new versions of the standard that exactly matched suggestions 
made in these newgroups. However, the committee members I knew about 
haven't posted to either news group in quite a while, so that might no 
longer be the case.

I haven't been able to find a current publicly-available list of the 
committee members, however you could try contacting the committee 
itself: <http://www.open-std.org/jtc1/sc22/wg14/www/contacts>

[toc] | [prev] | [next] | [standalone]

#106378

On Fri, 17 Mar 2017 10:33:53 -0700 (PDT)
mertesthomas@gmail.com wrote:

> Do you or others in this group have an influence about what will be
> adopted by a new C standard?

The C standard is a relative notion.

Any implementor of compiler or library for the C language may have an influence
in providing popular features.

For the ISO 9899 standard only the money of big companies paid for their
membership have an influence in adopting new features such as annex K promoted
by Microsoft for C11.

 
> In that case I would come up with some suggestions, what I would like
> in a new C standard.

Implement it and see if it's popular enough to be (de facto) standard.


> > (Since lcc-win uses non-standard declarations for fseek() and ftell()
> > I wonder if that causes problems linking code compiled by lcc-win
> > with code compiled by other compilers.  Is that supported?)

The real question you should ask yourself is if your code need to be portable.
If so then you should rely on a correct implementation of the C standard
library.

[toc] | [prev] | [next] | [standalone]

#106429

Am Freitag, 17. März 2017 20:20:20 UTC+1 schrieb GOTHIER Nathan:
> On Fri, 17 Mar 2017 10:33:53 -0700 (PDT)
> mertesthomas wrote:
> 
> > Do you or others in this group have an influence about what will be
> > adopted by a new C standard?
> 
> The C standard is a relative notion.
> 
> Any implementor of compiler or library for the C language may have an influence
> in providing popular features.
> 
> For the ISO 9899 standard only the money of big companies paid for their
> membership have an influence in adopting new features such as annex K promoted
> by Microsoft for C11.

Ok, I see.
I will not spend time to create suggestions for a new C standard.
I have to live with the things that big companies want, instead of the
"right things" that would be useful. :)

This group narrows down to standard C, which is IMHO too narrow.

Portable programs with standard C are only possible in a small area.
What about (Not 100% sure since I am not completely up to date with C99):
- A 64-bit seek on a platform with a 32-bit long.
- Reading the contents of a directory (MS does not support opendir).
- Opening a file with a Unicode name (MS does not use UTF-8).
- Safe signal handling together with longjmp.
- Reading from a keyboard without echo.
- Get the properties (length, file type, etc.) of a file (stat)
- Any form of network connection (sockets, etc.).
- Specifying that an condition is likely true (helps the optimizer).
- Optionally checking for signed integer overflow.
- Using a 64-bit time_t (2038 will come).
- Cursor positioning at a console/terminal.
- Starting a sub-process.
- Draw graphics on the screen.

This is just a short list of things that came to my mind.
Actually there is much more that cannot be done with standard C.
I am almost sure that at least one person will consider the list from
above as off topic. :) Discussing C portability includes mentioning
things from Windows AND Posix. In the Windows groups they consider
Posix off topic and vice versa. So I think this group is the right
one for portability things. Am I the only person interested in
portable programs?

The list from above shows the things I am working on, to make Seed7
source code portable. There are alternate C source files for Windows
and Unix and there are tons of #define macros and #if statements in
the C part of the Seed7 run-time library.

And the source code portability of Seed7 already works: All the
things from above can be done portable in Seed7. And Seed7 programs
are automatically source code portable. Nothing like: Under Windows
you have to include this file and use that function.

For me this is where portability begins: The source code of a program
can be moved and it works without changing a single bit.


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#106436

On 18/03/2017 07:44, mertesthomas@gmail.com wrote:

> This group narrows down to standard C, which is IMHO too narrow.
>
> Portable programs with standard C are only possible in a small area.
> What about (Not 100% sure since I am not completely up to date with C99):

I guess you use some intermediate API to get around these problems? 
That's what I use with code that has to run on Windows and Linux. 
Actually that's what I use anyway even just on Windows, to provide a 
nicer interface.

> - A 64-bit seek on a platform with a 32-bit long.
> - Reading the contents of a directory (MS does not support opendir).

Yes, you need to use FindFirstfile/etc. Actually I was familiar with MS' 
functions first, which I then had to emulate on Linux, where it was 
harder (there is no automatic wildcard handling).

> - Opening a file with a Unicode name (MS does not use UTF-8).
> - Safe signal handling together with longjmp.
> - Reading from a keyboard without echo.

There is opposition to such features. I've discussed this on the Python 
group (non-line-buffered keyword i/o, non-echoing, non-blocking etc), 
nobody there was interested [in adding them to Python]. Maybe because no 
one writes terminal mode editors, IDEs, games, any of dozens of apps 
that need this stuff.

So you always need messy DIY solutions, such as based on 
ReadConsoleInputA in Windows, or tcgetattr in Linux.

> - Get the properties (length, file type, etc.) of a file (stat)
> - Any form of network connection (sockets, etc.).
> - Specifying that an condition is likely true (helps the optimizer).
> - Optionally checking for signed integer overflow.
> - Using a 64-bit time_t (2038 will come).

> - Cursor positioning at a console/terminal.

Same as the above (you'd think this is stuff was pretty fundamental).

> - Starting a sub-process.
> - Draw graphics on the screen.

A big one. I've managed it on Windows years ago, but don't have the 
inclination now to do battle with X windows. And I'm not into roping in 
huge third party libraries to do the job (and which wouldn't be that 
much easier).

> For me this is where portability begins: The source code of a program
> can be moved and it works without changing a single bit.

That was also my aim with my interpreted language. I think I also just 
about managed it with compiled code (ie. binary byte-code), which could 
run on Windows or Linux for console apps, but with a few issues..

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#106456

Am Samstag, 18. März 2017 14:32:02 UTC+1 schrieb Bart:
> On 18/03/2017 07:44, mertesthomas wrote:
> 
> > This group narrows down to standard C, which is IMHO too narrow.
> >
> > Portable programs with standard C are only possible in a small area.
> > What about (Not 100% sure since I am not completely up to date with C99):
> 
> I guess you use some intermediate API to get around these problems?

Yes.
Part of the intermediate API consists of macros.
Macros about the Unicode encoding used by functions of the os:
  OS_STRI_UTF8 and OS_STRI_WCHAR
Macros for functions: os_chdir, os_chmod, os_chown, os_closedir,
  os_fopen, os_fseek, os_fstat, os_ftell, os_getcwd, os_getenv,
  os_isinf, os_isnan, os_lstat, os_mkdir, os_opendir, os_pclose,
  os_poll, os_popen, os_readdir, os_remove, os_rename, os_rmdir,
  os_setenv, os_stat, os_system and os_utime
Macros for types: os_DIR, os_dirent_struct, os_fstat_struct,
  os_off_t, os_stat_struct and os_utimbuf_struct
Macros for variables: os_environ

Other parts of the API consists alternative C source files
for Unix and Windows. This two files have a common header
with function prototypes. Some of this headers with the
functions they define are:
cmd_drv.h: getUtf16Argv, freeUtf16Argv, getExecutablePath,
  getEnvironment, freeEnvironment, wgetenv and wsetenv
con_drv.h: conHeight, conWidth, conFlush, conCursor, conSetCursor,
  conText, conWrite, conClear, conUpScroll, conDownScroll,
  conLeftScroll, conRightScroll, conShut and conOpen
dll_drv.h: dllOpen and dllFunc
drw_drv.h: gkbGetc, gkbKeyPressed, gkbRawGetc, gkbWindow,
  gkbButtonPressed, gkbButtonXpos, gkbButtonYpos, drwPointerXpos,
  drwPointerYpos, drwArc, drwPArc, drwFArcChord, drwPFArcChord,
  drwFArcPieSlice, drwPFArcPieSlice, drwArc2, drwCircle,
  drwPCircle, drwClear, drwCopyArea, drwFCircle, drwPFCircle,
  drwFEllipse, drwPFEllipse, drwEmpty, drwFlush, drwFree,
  drwGet, drwGetImage, drwGetPixel, drwPixelToRgb, drwHeight,
  drwImage, drwLine, drwPLine, drwNewPixmap, drwNewBitmap,
  drwOpen, drwOpenSubWindow, drwPoint, drwPPoint,
  drwConvPointList, drwGenPointList, drwLngPointList,
  drwPolyLine, drwFPolyLine, drwPut, drwRect, drwPRect,
  drwRgbColor, drwBackground, drwColor, drwSetContent,
  drwSetPos, drwSetTransparentColor, drwText, drwToBottom,
  drwToTop, drwWidth, drwXPos and drwYPos
fil_drv.h: filInputReady, filPipe and setupFiles
kbd_drv.h: kbdGetc, kbdKeyPressed, kbdRawGetc and kbdShut
pcs_drv.h: pcsCmp, pcsEq, pcsExitValue, pcsFree, pcsHashCode,
  pcsIsAlive, pcsKill, pcsPipe2, pcsPty, pcsStart, pcsStr and
  pcsWaitFor
pol_drv.h: initPollOperations, polAddCheck, polClear, polCpy,
  polCreate, polDestr, polEmpty, polGetCheck, polGetFinding,
  polHasNext, polIterChecks, polIterFindings, polNextFile,
  polPoll and polRemoveCheck
tim_drv.h:timAwait, timMicroSec, timNow, alternate_localtime_r
  and alternate_utime

> That's what I use with code that has to run on Windows and Linux. 
> Actually that's what I use anyway even just on Windows, to provide a 
> nicer interface.
> 
> > - A 64-bit seek on a platform with a 32-bit long.
> > - Reading the contents of a directory (MS does not support opendir).
> 
> Yes, you need to use FindFirstfile/etc. Actually I was familiar with MS' 
> functions first, which I then had to emulate on Linux, where it was 
> harder (there is no automatic wildcard handling).

The usual Unix function for wild card matching (i think it is called
gmatch) is quite simple. Implementing opendir based on FindFirstfile
needs to check that no wildcard is provided to opendir. Btw. windows has
also a limitation for the maximum path length (260). My windows driver
library also circumvents this limitation (by using the prefix \\?\).

> > - Opening a file with a Unicode name (MS does not use UTF-8).
> > - Safe signal handling together with longjmp.
> > - Reading from a keyboard without echo.
> 
> There is opposition to such features. I've discussed this on the Python 
> group (non-line-buffered keyword i/o, non-echoing, non-blocking etc), 
> nobody there was interested [in adding them to Python]. Maybe because no 
> one writes terminal mode editors, IDEs, games, any of dozens of apps 
> that need this stuff.
> 
> So you always need messy DIY solutions, such as based on 
> ReadConsoleInputA in Windows, or tcgetattr in Linux.

Many people think that this (use different functions depending on
the operating system) is normal. They are so used to this behaviour
that they don't recognize that this is a bad way.

Well, I can just suggest to use Seed7 instead of Python for such
things.

> > - Get the properties (length, file type, etc.) of a file (stat)
> > - Any form of network connection (sockets, etc.).
> > - Specifying that an condition is likely true (helps the optimizer).
> > - Optionally checking for signed integer overflow.
> > - Using a 64-bit time_t (2038 will come).
> 
> > - Cursor positioning at a console/terminal.
> 
> Same as the above (you'd think this is stuff was pretty fundamental).
> 
> > - Starting a sub-process.
> > - Draw graphics on the screen.
> 
> A big one. I've managed it on Windows years ago, but don't have the 
> inclination now to do battle with X windows. And I'm not into roping in 
> huge third party libraries to do the job (and which wouldn't be that 
> much easier).

Third party libraries often require inversion of control, which I do
not want in the Seed7 graphic interface.

> > For me this is where portability begins: The source code of a program
> > can be moved and it works without changing a single bit.
> 
> That was also my aim with my interpreted language. I think I also just 
> about managed it with compiled code (ie. binary byte-code), which could 
> run on Windows or Linux for console apps, but with a few issues..

Are you speaking about byte-code portability (such as in Java)?
Seed7 has source code portability.

Both have advantages and disadvantages.
Seed7 allows ahead of time compilation to machine code.
Java has just in time compilation of byte-code.

Discussions about C vs. Java performance are usually highly
emotional. I consider C as significantly faster than Java. Therefore
I claim that Seed7 beats byte-code JIT compilation systems.


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#106556

>
>Yes, you need to use FindFirstfile/etc. Actually I was familiar with MS' 
>functions first, which I then had to emulate on Linux, where it was 
>harder (there is no automatic wildcard handling).

man 3 wordexp

Having used the programmatic wildcard handling on VMS (from which NT's
was, perhaps, derived), I'm firmly in the unix-way camp.

[toc] | [prev] | [next] | [standalone]

#106437

On Sat, 18 Mar 2017 00:44:53 -0700 (PDT)
mertesthomas@gmail.com wrote:

> For me this is where portability begins: The source code of a program
> can be moved and it works without changing a single bit.

In the real world the portability begins where money flow... programmers don't
live with only fresh water. ;-)

Actually the portability is a relative notion.

Source code need a specific compiler|interpreter which need a specific
operating system. Nothing is really 100 % portable, even humans have standard
two arms and two legs but not always a full brain. :o)

[toc] | [prev] | [next] | [standalone]

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web