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 1 of 7  [1] 2 3 4 5 6 7  Next page →

#106122 — More problems with lcc-win

I looked at the lcc-win32 source of fseeki64 (provided by Jacob
Navia) and it seems ok. At least it does not look like returning an
argument (like I can see in my tests). I looked also at the C
run-time library of lcc-win32. The disassembled code there seems to
correspond with the provided source code. Still I have problems
with fseeki64 even after a fresh install of lcc-win32. Maybe it is
an issue with the calling convention. I narrowed the problem of
fseeki64 down and it is part of the program testlcc_4.c (see below).
Could someone else also try testlcc_4.c with the 32-bit version of
lcc-win32?

Besides this there are still several issues with the 32-bit
version of lcc-win32:

- lc seems to have problems when the option -I contains spaces.
  E.g.: "-I\"C:\\Program Files (x86)/MariaDB/MariaDB C Client Library/include\"
  As a result lc is not able to find the include file mysql.h.
- A missing include file just triggers a warning.
- The functions _wchdir, _wgetcwd, _wmkdir, _wrmdir, _wrename,
  _wremove and _wchmod are missing from the run-time library.
  This functions are defined in the header files, but missing
  in the run-time library.
- An expression like:
    int x = 0;
    _Bool flag = argc != -1 ? x++, (_Bool) 1:(_Bool) 0;
  triggers a compiler error (trap). See testlcc_2.c
- Please compile testlcc_3.c with the 32-bit version of lcc-win32.
  When you run it you see more problems.
- There is a strange behavior with -inf. Lcc-win32 seems to
  generate inf instead of -inf.
- Lc requires that the linker options are at the end. Other
  compilers use options like: -Wl,linker-option to specify linker
  options. My handling of linker options does not work with the
  "linker options must be last" concept.

As suggested I tried to use the 64-bit version of lcc-win. The
64-bit version seems to have even more problems than 32-bit
version. In the 64-bit version of lcc-win I found the following
problems:
- The header stdio.h does not contain the prototype of wfopen().
- The header errno.h is missing definitions of ENOTDIR and
  ENAMETOOLONG.
- The header conio.h is missing.
- In include64/sys/stat.h the definition of S_ISCHR uses _S_IFCHR
  instead of S_IFCHR.
- The function _pclose is missing in the 64-bit run-time library.
- The function _wsystem is missing in both the 32-bit and 64-bit
  run-time library.
- Please run the test programs below also with the 64-bit version.

The test programs follow:

========== begin testlcc_2.c ==========
/* This program triggers an Compiler error (trap), when compiled with */
/* lcc-win32 version 3.8. Compilation date: Mar 29 2013 13:11:27. */
/* Compile command: lcc testlcc_2.c */

#include "stdio.h"

int main (int argc, char *argv[])
  {
    int x = 0;
  /* The compilation fails also, when parentheses are used: (x++, (_Bool) 1) */
    _Bool flag = argc != -1 ? x++, (_Bool) 1:(_Bool) 0;
    return 0;
  }
========== end testlcc_2.c ==========


========== begin testlcc_3.c ==========
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <float.h>
#include <math.h>

typedef int int32Type;
typedef unsigned int uint32Type;
typedef long long int64Type;
typedef unsigned long long uint64Type;

#define INT64TYPE_MAX   ((int64Type)  9223372036854775807)
#define INT64TYPE_MIN   ((int64Type) (-INT64TYPE_MAX - 1))

static void check1 (void)
  {
    uint64Type unsigned_result = 4U;

    if (unsigned_result > -(uint64Type) INT64TYPE_MIN) {
      printf(" ***** Error: %llu > %llu is true.\n",
             unsigned_result,
             -(uint64Type) INT64TYPE_MIN);
    }
  }

#define MAX_MEMSIZETYPE  0xFFFFFFFF
#define MAX_BIG_LEN      ((MAX_MEMSIZETYPE - 12 + 4) / 4)

static void check2 (void)
  {
    int64Type exponent = 2;
    uint32Type base_size = 2;

    if ((uint64Type) exponent + 1 > MAX_BIG_LEN / base_size) {
      printf(" ***** Error: %llu > %u is true.\n",
             (uint64Type) exponent + 1,
             MAX_BIG_LEN / base_size);
    }
  }

typedef uint32Type memSizeType;

#define FMT_X32      "%x"
#define FMT_X64      "%llx"

#define BIGDIGIT_SIZE 32
#define BIGDIGIT_MASK              0xFFFFFFFF

typedef uint32Type bigDigitType;
typedef uint64Type doubleBigDigitType;

#define FMT_X_DIG FMT_X32
#define FMT_X_DIG2 FMT_X64

static void check3 (void)
  {
    doubleBigDigitType remainder = 0;
    bigDigitType quotientdigit = 1;
    bigDigitType divisordigit = 0;
    bigDigitType dividenddigit = 0x80000000;

  /* check3 */
    printf("Condition of while loop: 0x" FMT_X_DIG2 " > 0x" FMT_X_DIG2
           " evaluates to: %d\n",
       (doubleBigDigitType) divisordigit * quotientdigit,
       (remainder << BIGDIGIT_SIZE | dividenddigit),
           (doubleBigDigitType) divisordigit * quotientdigit >
          (remainder << BIGDIGIT_SIZE | dividenddigit));
    while ((doubleBigDigitType) divisordigit * quotientdigit >
          (remainder << BIGDIGIT_SIZE | dividenddigit)) {
      printf(" ***** Error: In while loop although the condition was 0.\n");
      remainder = 0x80000000;
    } /* while */
    printf("After while loop\n");
  } /* check3 */

static void check4 (void)
  {
    char buffer[128];
    char *res1 = "1.00000e+306";
    char *res2 = "1.00000e+307";
    char *res3 = "1.00000e+308";

    sprintf(buffer, "%1.5e", 1e306);
    if (strcmp(buffer, "1.00000e+306") != 0) {
      printf(" ***** Error: printf(\"%%1.5e\", 1e306); "
             "writes %s instead of %s\n", buffer, res1);
    }
    sprintf(buffer, "%1.5e", 1e307);
    if (strcmp(buffer, "1.00000e+307") != 0) {
      printf(" ***** Error: printf(\"%%1.5e\", 1e307); "
             "writes %s instead of %s\n", buffer, res2);
    }
    sprintf(buffer, "%1.5e", 1e308);
    if (strcmp(buffer, "1.00000e+308") != 0) {
      printf(" ***** Error: printf(\"%%1.5e\", 1e308); "
             "writes %s instead of %s\n", buffer, res3);
    }
  }

#define FMT_D      "%lld"

static void check5 (void)
  {
    uint64Type set1[16];
    uint64Type set2[16];
    int64Type position = 0;
    uint64Type result;

    set1[0] = 0x8;
    set2[15] = 0x1;
    result = set1[position - 0] ^ set2[position - -15];
    if (result != 9) {
      printf(" ***** Error: 0x" FMT_X64 " ^ 0x" FMT_X64
             " evaluates to 0x" FMT_X64 "\n",
             set1[position - 0], set2[position - -15], result);
    }
  }

static void check6 (void)
  {
    union {
      uint64Type i;
      double f;
    } dblTransfer;

    dblTransfer.f = strtod("-Infinity", NULL);
    if (dblTransfer.i != 0 && dblTransfer.i != 0xfff0000000000000) {
      printf(" ***** Error: strtod(\"-Infinity\", NULL) returns %1.14e\n",
             dblTransfer.f);
    }
  }

static void check7 (void)
  {
    union {
      uint64Type i;
      double f;
    } dblTransfer;

    dblTransfer.i = 0xfff8000000000000;
    if (dblTransfer.f == 1.0) {
      printf(" ***** Error: The comparison NaN == 1.0 evaluates to TRUE.\n");
    }
  }

int main (int argc, char *argv[])
  {
    printf("sizeof(int32Type): %u\n", sizeof(int32Type));
    printf("sizeof(int64Type): %u\n", sizeof(int64Type));
    check1();
    check2();
    check3();
    check4();
    check5();
    check6();
    check7();
    return 0;
  }
========== end testlcc_3.c ==========


========== begin testlcc_4.c ==========
/* For 32 bit compile with: lc -A testlcc_4.c
   and run the program. With version 3.8 of lcc-win32 it writes:
 ***** Error: 1 <= 308 is FALSE
 ***** Error: fseeki64(aFile, 54, 0) result: 54
-----------------------------------------------------------
   For 64 bit compile with: lc64 -A testlcc_4.c
   (the compiler complains about: missing prototype for fseeki64
   so fseeki64 seems to be missing in the header stdio.h) and run
   the program. With version 4.1 of lcc-win (64 bits) it writes:
 ***** Error: S_ISREG is not defined in <sys/stat.h>
 ***** Error: S_IFMT is not defined in <sys/stat.h>
 ***** Error: ENOTDIR is not defined in <errno.h>
 ***** Error: ENAMETOOLONG is not defined in <errno.h>
 ***** Error: EXDEV is not defined in <errno.h>
1 <= 308 is TRUE
 ***** Error: The S_IFREG bit of a regular file is not set.
-----------------------------------------------------------
   Afterwards the 64-bit program crashes because fseeki64() is
   missing in the run-time library.
*/

#include "stdio.h"
#include "stdlib.h"
#include "sys/stat.h"
#include "errno.h"

typedef int int32Type;
typedef unsigned int uint32Type;
typedef long long int64Type;
typedef unsigned long long uint64Type;

#define INT64TYPE_MAX   ((int64Type)  9223372036854775807)
#define INT64TYPE_MIN   ((int64Type) (-INT64TYPE_MAX - 1))

/* The compiler wrongly complain: overflow in constant expression */
static const int64Type minBaseOfExponent[] = {INT64TYPE_MIN};

typedef unsigned int strElemType;

static inline const strElemType *check1 (const strElemType *mem)
  {
    /* Why does the compiler complain: Different const qualifiers */
    return mem;
  }

static void check2 (uint32Type big1size, int64Type rshift)
  {
    if (big1size <= (uint64Type) rshift >> 5) {
      printf("%u <= %lld is TRUE\n",
             big1size, (uint64Type) rshift >> 5);
    } else {
      printf(" ***** Error: %u <= %lld is FALSE\n",
             big1size, (uint64Type) rshift >> 5);
    }
  }

static void check3 (void)
  {
    struct stat statStruct;

    if (stat("testlcc_4.c", &statStruct) == 0) {
      if ((statStruct.st_mode & S_IFREG) == 0) {
        printf(" ***** Error: "
               "The S_IFREG bit of a regular file is not set.\n");
      }
    }
  }

static void check4 (void)
  {
    FILE *aFile;
    int fseekResult;

    aFile = fopen("testlcc_4.c", "rb");
    if (aFile != NULL) {
      fseekResult = fseeki64(aFile, 54, 0);
      if (fseekResult != 0) {
        printf(" ***** Error: fseeki64(aFile, 54, 0) result: %d\n",
               fseekResult);
      }
      fclose(aFile);
    }
  }

int main (int argc, char *argv[])
  {
    strElemType strElem[2];

#ifndef S_ISREG
    printf(" ***** Error: S_ISREG is not defined in <sys/stat.h>\n");
#endif
#ifndef S_IFMT
    printf(" ***** Error: S_IFMT is not defined in <sys/stat.h>\n");
#endif
#ifndef ENOTDIR
    printf(" ***** Error: ENOTDIR is not defined in <errno.h>\n");
#endif
#ifndef ENAMETOOLONG
    printf(" ***** Error: ENAMETOOLONG is not defined in <errno.h>\n");
#endif
#ifndef EXDEV
    printf(" ***** Error: EXDEV is not defined in <errno.h>\n");
#endif
    check1(strElem);
    check2(1, 9876);
    check3();
    check4();
    return 0;
  }
========== end testlcc_4.c ==========


========== begin testlcc_5.c ==========
/* Compile with: lc64 -c -g5 testlcc_5.c */
/* With version 4.1 of lc64 the compilation fails with:
t.globl __plccStackTrace
__plccStackTrac
Internal error 1012     line 34
t.globl
Internal error 2077     line 34
Internal error 2077     line 36
error:  (45) suffix/operands illegal for 'movq'
*/
/* Additionally there are errors like:
...testlcc_5.c 28  (51) '-8(%ebp)' incorrect base/index expression
...testlcc_5.c 29  (53) '-8(%ebp)' incorrect base/index expression
...testlcc_5.c 30  (57) '-8(%ebp)' incorrect base/index expression
...testlcc_5.c 31  (61) '-8(%ebp)' incorrect base/index expression
...testlcc_5.c 31  (62) Ambiguous instruction. Suffix missing?
*/

#include "stdio.h"

typedef unsigned long long uint64Type;

typedef struct optionStruct {
    uint64Type options;
  } optionRecord;

int main (int argc, char **argv)
  {
    optionRecord option = { 0, };
    return 0;
  }
========== end testlcc_5.c ==========


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] | [next] | [standalone]

#106124

Le 15/03/2017 à 08:29, mertesthomas@gmail.com a écrit :
>    For 64 bit compile with: lc64 -A testlcc_4.c
>    (the compiler complains about: missing prototype for fseeki64
>    so fseeki64 seems to be missing in the header stdio.h) and run
>    the program. With version 4.1 of lcc-win (64 bits) it writes:
>  ***** Error: S_ISREG is not defined in <sys/stat.h>
>  ***** Error: S_IFMT is not defined in <sys/stat.h>
>  ***** Error: ENOTDIR is not defined in <errno.h>
>  ***** Error: ENAMETOOLONG is not defined in <errno.h>
>  ***** Error: EXDEV is not defined in <errno.h>
> 1 <= 308 is TRUE
>  ***** Error: The S_IFREG bit of a regular file is not set.
> -----------------------------------------------------------
>    Afterwards the 64-bit program crashes because fseeki64() is
>    missing in the run-time library.

As I told you before, fseeki64 doesn't exist in the 64 bit version and 
has been replaced by fseek now, that returns a long long

You should also notice that you are under windows, that doesn't 
implement any of the POSIX bits you are trying to use. Since lcc-win is 
not posix under windows, those things are not implemented.

The st!mode member of the stats structure contains the file attributes 
as WINDOWS sets them.

You should seek with following definitions contained in win32.h:

  52 #define FILE_ATTRIBUTE_READONLY         0x00000001
  53 #define FILE_ATTRIBUTE_HIDDEN           0x00000002
  54 #define FILE_ATTRIBUTE_SYSTEM           0x00000004
  55 #define FILE_ATTRIBUTE_DIRECTORY        0x00000010
  56 #define FILE_ATTRIBUTE_ARCHIVE          0x00000020
  57 #define FILE_ATTRIBUTE_NORMAL           0x00000080
  58 #define FILE_ATTRIBUTE_TEMPORARY        0x00000100
  59 #define FILE_ATTRIBUTE_COMPRESSED       0x00000800

You could also add some defines to the stat.h file to make a translation.

Of course I could do the modifications for you, or you could buy a 
source license and fix everything you do not like.

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

#106131

jacobnavia <jacob@jacob.remcomp.fr> writes:
>Le 15/03/2017 à 08:29, mertesthomas@gmail.com a écrit :
>>    For 64 bit compile with: lc64 -A testlcc_4.c
>>    (the compiler complains about: missing prototype for fseeki64
>>    so fseeki64 seems to be missing in the header stdio.h) and run
>>    the program. With version 4.1 of lcc-win (64 bits) it writes:
>>  ***** Error: S_ISREG is not defined in <sys/stat.h>
>>  ***** Error: S_IFMT is not defined in <sys/stat.h>
>>  ***** Error: ENOTDIR is not defined in <errno.h>
>>  ***** Error: ENAMETOOLONG is not defined in <errno.h>
>>  ***** Error: EXDEV is not defined in <errno.h>
>> 1 <= 308 is TRUE
>>  ***** Error: The S_IFREG bit of a regular file is not set.
>> -----------------------------------------------------------
>>    Afterwards the 64-bit program crashes because fseeki64() is
>>    missing in the run-time library.
>
>As I told you before, fseeki64 doesn't exist in the 64 bit version and 
>has been replaced by fseek now, that returns a long long

That's silly.  Any correctly written[*] program that compiles to 32-bit should also
compile to 64-bit without any source code changes.

[*] I.e. they don't cast pointers to/from int, but rather use
    the appropriate abstract type (e.g. uintptr_t).

>
>You should also notice that you are under windows, that doesn't 
>implement any of the POSIX bits you are trying to use. Since lcc-win is 
>not posix under windows, those things are not implemented.

So much for source code portability.

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

#106133

Le 15/03/2017 à 14:18, Scott Lurndal a écrit :
> That's silly.  Any correctly written[*] program that compiles to 32-bit should also
> compile to 64-bit without any source code changes.
fseeki64 was added to lcc-win in 32 bits to allow people to use files 
bigger than 2GB since fseek would not go beyond signed int.

This is no longer needed in 64 bit systems and please just

#define fseeki64 fseek

Maybe I should add that to stdio.h

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

#106136

jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> This is no longer needed in 64 bit systems and please just
>
> #define fseeki64 fseek
>
> Maybe I should add that to stdio.h

That would make the implementation non-conforming unless you hide the
macro definition in conforming mode.  (I don't know whether you intend
lcc-win to be 100% conforming.)

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

#106135

jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> As I told you before, fseeki64 doesn't exist in the 64 bit version and 
> has been replaced by fseek now, that returns a long long

Do you mean long rather than long long?

[...]

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

#106137

Le 15/03/2017 à 16:25, Keith Thompson a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
> [...]
>> As I told you before, fseeki64 doesn't exist in the 64 bit version and
>> has been replaced by fseek now, that returns a long long
>
> Do you mean long rather than long long?
>
> [...]
>

No, I was speaking of the second argument of fseek actually.
The standard mandates long but I can't use that since it is 32 bits.
So I changed the function to use a long long and everything is OK, no 
need for fseeki64

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

#106140

On 15/03/17 16:46, jacobnavia wrote:
> Le 15/03/2017 à 16:25, Keith Thompson a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> [...]
>>> As I told you before, fseeki64 doesn't exist in the 64 bit version and
>>> has been replaced by fseek now, that returns a long long
>>
>> Do you mean long rather than long long?
>>
>> [...]
>>
> 
> No, I was speaking of the second argument of fseek actually.
> The standard mandates long but I can't use that since it is 32 bits.
> So I changed the function to use a long long and everything is OK, no
> need for fseeki64

The standard says "int" for the return type of fseek:

	int fseek(FILE *stream, long int offset, int whence);

The return value is either 0 for success, or non-zero for failure.

As for the offset parameter, it's not a simple matter to decide the
type.  In 64-bit Linux, "long int" is 64 bits - so the standard version
works fine.  But in 64-bit Windows, "long int" is 32 bits - so if you
want a larger range, you need a "long long int".  But then your function
is no longer the same signature as the C standards mandate.  It will
work fine for most purposes - but it might cause problems for people who
declare the function manually rather than #including <stdio.h>, or if
someone uses it with a function pointer.

What does MSVC do in this case?  I would expect that the best choice is
to copy the behaviour of the nearest Windows has to a standard compiler.

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

#106145

David Brown <david.brown@hesbynett.no> writes:
> On 15/03/17 16:46, jacobnavia wrote:
>> Le 15/03/2017 à 16:25, Keith Thompson a écrit :
>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> [...]
>>>> As I told you before, fseeki64 doesn't exist in the 64 bit version and
>>>> has been replaced by fseek now, that returns a long long
>>>
>>> Do you mean long rather than long long?
>>>
>>> [...]
>>>
>> 
>> No, I was speaking of the second argument of fseek actually.
>> The standard mandates long but I can't use that since it is 32 bits.
>> So I changed the function to use a long long and everything is OK, no
>> need for fseeki64
>
> The standard says "int" for the return type of fseek:
>
> 	int fseek(FILE *stream, long int offset, int whence);
>
> The return value is either 0 for success, or non-zero for failure.

Both jacob and I managed to confuse fseek's second parameter with its
return type.  The return type is not an isse; it's just an int that
tells you whether it succeeded or failed.  But the standard makes the
second parameter of fseek, as well as the return type of ftell, long.

This is IMHO a flaw in the standard.  I could argue that 64-bit Windows
*should* have made long 64 bits, as 64-bit Linux does, but making it 32
bits is perfectly valid.

In C89/C90, long was the only reasonable choice, since it was the
longest signed integer type.  With the addition of long long in C99,
(and the increasing commonality of files bigger than 2 gigabytes), the
use of long for file offsets became a problem.

IMHO C99 *should* have defined a new typedef for the signed integer type
used by fseek() and ftell().  (Using size_t might have been another
alternative, and it would work for 64-bit Windows, but files can be
bigger than any supported objects, so size_t isn't really the right
type.)

[...]

> What does MSVC do in this case?  I would expect that the best choice is
> to copy the behaviour of the nearest Windows has to a standard compiler.

https://msdn.microsoft.com/en-us/library/75yw9bf3.aspx

It defines fseek() as the Standard does, with a long argument, and also
provides _fseeki64 which uses __int64 (int64_t would have made more
sense, but it might not have been supported when _fseeki64 was
introduced).  Given that long isn't wide enough to use as a file offset,
I think that's the best solution -- except that I'd suggest defining a
typedef for the offset type.

fgetpos() and fsetpos() avoid this problem by using type fpos_t, which
isn't necessarily an integer type (it's a struct in glibc), but those
functions are less flexible.  In particular, you can't seek to a
relative position, only to a position from an earlier call to fgetpos().

I would suggest:

1. For current implementations with 64-bit long, just define fseek()
   and ftell() as the standard specifies.

2. For current implementations with 32-bit long, or more generally
   where long isn't wide enough to use as a file offset, define
   fseek() and ftell() as the standard specifies and provide
   supplemental functions that use a wider integer type.

3. In a future standard, change fseek() and ftell() to use a
   wider type.  I suggest using a typedef, but long long might also
   be reasonable.  (long long must be at least 64 bits; 8 exabytes
   is *probably* enough for file offsets for the foreseeable future.)

Defining fseek() and ftell() to use long long is clearly
non-conforming in C90, C99, and C11.  Each implementer has to
decide how much of a problem that is.  (In the case of lcc-win,
I'm not a user, so I don't get a vote.)  It's unlikely to break any
non-contrived user code, since implicit conversions will quietly
handle most inconsistencies.

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

#106146

Keith Thompson <kst-u@mib.org> writes:

>
>IMHO C99 *should* have defined a new typedef for the signed integer type
>used by fseek() and ftell().  (Using size_t might have been another
>alternative, and it would work for 64-bit Windows, but files can be
>bigger than any supported objects, so size_t isn't really the right
>type.)

 off_t is the abstract type for file offsets in POSIX, enabling
LFS determined whether a 32-bit or 64-bit off_t was used.

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

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

#106149

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <kst-u@mib.org> writes:
>>IMHO C99 *should* have defined a new typedef for the signed integer type
>>used by fseek() and ftell().  (Using size_t might have been another
>>alternative, and it would work for 64-bit Windows, but files can be
>>bigger than any supported objects, so size_t isn't really the right
>>type.)
>
>  off_t is the abstract type for file offsets in POSIX, enabling
> LFS determined whether a 32-bit or 64-bit off_t was used.

It's not an abstract type.  POSIX requires it to be a signed integer
type, and lseek() returns (off_t)-1 on error.

> http://www.unix.org/version2/whatsnew/lfs20mar.html#3.3

I suppose a future C standard could adopt type off_t from POSIX and use
it for fseek() and ftell().  (POSIX uses it for lseek().)

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

#106153

Keith Thompson <kst-u@mib.org> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>>IMHO C99 *should* have defined a new typedef for the signed integer type
>>>used by fseek() and ftell().  (Using size_t might have been another
>>>alternative, and it would work for 64-bit Windows, but files can be
>>>bigger than any supported objects, so size_t isn't really the right
>>>type.)
>>
>>  off_t is the abstract type for file offsets in POSIX, enabling
>> LFS determined whether a 32-bit or 64-bit off_t was used.
>
>It's not an abstract type.  POSIX requires it to be a signed integer
>type, and lseek() returns (off_t)-1 on error.

I wasn't using abstract as a term of art, but rather abstracting the
type from a particular fundamental integer type.

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

#106150

On 15/03/17 16:52, Keith Thompson wrote:

<snip>

> But the standard makes the
> second parameter of fseek, as well as the return type of ftell, long.
>
> This is IMHO a flaw in the standard.

I disagree. I think there is a flaw in some implementations.

> I could argue that 64-bit Windows
> *should* have made long 64 bits, as 64-bit Linux does, but making it 32
> bits is perfectly valid.

Although 32-bit long is perfectly valid, I would agree that Microsoft 
should have extended long to 64 bits. In fact, IIRC I argued at the time 
that 'long long' was an unnecessary introduction, as a bigger long would 
do exactly the same job and would require no changes to the Standard.

> In C89/C90, long was the only reasonable choice, since it was the
> longest signed integer type.  With the addition of long long in C99,
> (and the increasing commonality of files bigger than 2 gigabytes), the
> use of long for file offsets became a problem.

Yes, but it's a problem that could easily have been avoided by making 
long 64 bits (or longer, if need be) and ignoring long long completely.

<snip>

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

#106151

On Wed, 15 Mar 2017 17:21:48 +0000
Richard Heathfield <rjh@cpax.org.uk> wrote:

> Yes, but it's a problem that could easily have been avoided by making 
> long 64 bits (or longer, if need be) and ignoring long long completely.

Wrong since 32-bit long code would be invalid redefining long to be 64-bit or
more. The committee guideline aims at no breaking existing code with new rules.

However the committee would have been more inventive to choose a better syntax than
long long such as extra|super long for example.

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

#106154

GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>On Wed, 15 Mar 2017 17:21:48 +0000
>Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> Yes, but it's a problem that could easily have been avoided by making 
>> long 64 bits (or longer, if need be) and ignoring long long completely.
>
>Wrong since 32-bit long code would be invalid redefining long to be 64-bit or
>more. The committee guideline aims at no breaking existing code with new rules.

Unix and later linux had no problems defining 'long' as 64-bits on
64-bit capable architectures.   Logically, windows should have followed
suit.

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

#106159

On 15/03/17 18:20, Scott Lurndal wrote:
> GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>> On Wed, 15 Mar 2017 17:21:48 +0000
>> Richard Heathfield <rjh@cpax.org.uk> wrote:
>>
>>> Yes, but it's a problem that could easily have been avoided by making
>>> long 64 bits (or longer, if need be) and ignoring long long completely.
>>
>> Wrong since 32-bit long code would be invalid redefining long to be 64-bit or
>> more. The committee guideline aims at no breaking existing code with new rules.
>
> Unix and later linux had no problems defining 'long' as 64-bits on
> 64-bit capable architectures.   Logically, windows should have followed
> suit.

Thanks, Scott. I don't see GOTHIER Nathan's articles, so I wouldn't have 
picked up on his incorrect correction if you hadn't replied to him.

The long int type was /never/ defined as exactly 32 bits by ISO. It was 
only ever defined as /at least/ 32 bits. There is no requirement on 
implementations to keep it that short, and any code that relies on long 
int being /exactly/ 32 bits is already broken. The Committee does not 
consider it a priority to avoid breaking code that is already broken.

Implementations can and do change integer sizes. As you rightly point 
out, Unix and Linux have moved to a 64-bit long int type, and even 
Microsoft moved from 16-bit int to 32-bit int when they introduced 
whichever C compiler version it was that shipped with Visual C++ 2.0. 
This horrified their application developers, whose code was littered 
with hard-coded 2 where they should have written sizeof i. Nevertheless, 
it was the right decision.

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

#106155

On 15/03/2017 17:42, GOTHIER Nathan wrote:
> On Wed, 15 Mar 2017 17:21:48 +0000
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> Yes, but it's a problem that could easily have been avoided by making
>> long 64 bits (or longer, if need be) and ignoring long long completely.
>
> Wrong since 32-bit long code would be invalid redefining long to be 64-bit or
> more. The committee guideline aims at no breaking existing code with new rules.

Why? I thought C types weren't defined as exact widths. So long merely 
had to be at least as wide as int, and at least 32 bits.

Making long 64 bits oughtn't to have broken any properly written programs.

Now the common situation when 'int' is 32 bits, is that 'long long' is 
64 bits; what's the point of 'long'?

-- 
bartc

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

#106156

On Wed, 15 Mar 2017 18:20:20 +0000
BartC <bc@freeuk.com> wrote:

> Why? I thought C types weren't defined as exact widths. So long merely 
> had to be at least as wide as int, and at least 32 bits.
> 
> Making long 64 bits oughtn't to have broken any properly written programs.
> 
> Now the common situation when 'int' is 32 bits, is that 'long long' is 
> 64 bits; what's the point of 'long'?

Indeed, C integers are defined by minimal values then any 32-bit long would be
compatible with 64-bit long like for 64-bit Linux implementations and 32-bit
integers would be optimized with redefined int. I'm afraid my answer was too
quick.

Anyway even the best make mistakes... in committee. :o)

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

#106167

BartC <bc@freeuk.com> writes:
[...]
> Now the common situation when 'int' is 32 bits, is that 'long long' is 
> 64 bits; what's the point of 'long'?

The point is that int is at least 16 bits (and encouraged to be the
"natural" size for the machine in some vaguely defined sense), long is
at least 32 bits, and long long is at least 64 bits.  You can write a
lot of code relying only on those guarantees.

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

#106173

On 15/03/2017 19:44, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> Now the common situation when 'int' is 32 bits, is that 'long long' is
>> 64 bits; what's the point of 'long'?
>
> The point is that int is at least 16 bits (and encouraged to be the
> "natural" size for the machine in some vaguely defined sense), long is
> at least 32 bits, and long long is at least 64 bits.  You can write a
> lot of code relying only on those guarantees.

The COMMON situation is that int is 32 bits and long long is 64 bits. 
Then when would you use long? It's no longer an in-between value, and 
it's no longer even longer than int, if that's how it was used.

And when int is 16 bits, then what's the point of 'short'.

Here's the current set of int types and their typical widths on x86 and ARM:

  char              8
  short            16
  int              32
  long             ??
  long long        64

And when int is 16 bits:

  char              8
  short            ??
  int              16
  long             32
  long long        64

Notice the odd one out in each case...

I think it could have been handled better.

-- 
Bartc

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

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

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

csiph-web