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

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

Problems with lcc-win32

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

Contents

  Problems with lcc-win32 mertesthomas@gmail.com - 2017-03-05 14:12 -0800
    Re: Problems with lcc-win32 luser droog <luser.droog@gmail.com> - 2017-03-05 14:46 -0800
      Re: Problems with lcc-win32 gazelle@shell.xmission.com (Kenny McCormack) - 2017-03-05 22:57 +0000
      Re: Problems with lcc-win32 jacob navia <jacob@jacob.remcomp.fr> - 2017-03-06 00:49 +0100
        Re: Problems with lcc-win32 luser droog <luser.droog@gmail.com> - 2017-03-05 22:10 -0800
    Re: Problems with lcc-win32 BartC <bc@freeuk.com> - 2017-03-05 23:32 +0000
      Re: Problems with lcc-win32 jacob navia <jacob@jacob.remcomp.fr> - 2017-03-06 00:48 +0100
    Re: Problems with lcc-win32 jacob navia <jacob@jacob.remcomp.fr> - 2017-03-06 00:44 +0100
      Re: Problems with lcc-win32 BartC <bc@freeuk.com> - 2017-03-06 00:13 +0000
      Re: Problems with lcc-win32 Keith Thompson <kst-u@mib.org> - 2017-03-05 19:35 -0800
        Re: Problems with lcc-win32 David Brown <david.brown@hesbynett.no> - 2017-03-06 10:26 +0100
          Re: Problems with lcc-win32 James Kuyper <jameskuyper@verizon.net> - 2017-03-06 07:08 -0500
          Re: Problems with lcc-win32 Keith Thompson <kst-u@mib.org> - 2017-03-06 08:37 -0800
            Re: Problems with lcc-win32 David Brown <david.brown@hesbynett.no> - 2017-03-06 21:16 +0100
        Re: Problems with lcc-win32 jm.bourguet@gmail.com - 2017-03-06 06:54 -0800
          Re: Problems with lcc-win32 David Brown <david.brown@hesbynett.no> - 2017-03-06 17:18 +0100
            Re: Problems with lcc-win32 Keith Thompson <kst-u@mib.org> - 2017-03-06 08:42 -0800
              Re: Problems with lcc-win32 David Brown <david.brown@hesbynett.no> - 2017-03-06 21:19 +0100
            Re: Problems with lcc-win32 jm.bourguet@gmail.com - 2017-03-06 08:44 -0800
              Re: Problems with lcc-win32 David Brown <david.brown@hesbynett.no> - 2017-03-06 21:20 +0100
      Re: Problems with lcc-win32 mertesthomas@gmail.com - 2017-03-06 00:24 -0800
    Re: Problems with lcc-win32 jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-06 18:15 +0100
      Re: Problems with lcc-win32 (trimmed) jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-06 18:50 +0100
        Re: Problems with lcc-win32 (trimmed) mertesthomas@gmail.com - 2017-03-07 04:50 -0800
          Re: Problems with lcc-win32 (trimmed) jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-07 14:54 +0100
            Re: Problems with lcc-win32 (trimmed) mertesthomas@gmail.com - 2017-03-07 06:20 -0800
              Re: Problems with lcc-win32 (trimmed) scott@slp53.sl.home (Scott Lurndal) - 2017-03-07 15:02 +0000
                Re: Problems with lcc-win32 (trimmed) mertesthomas@gmail.com - 2017-03-07 08:00 -0800
                  Re: Problems with lcc-win32 (trimmed) jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-07 20:30 +0100
                    Re: Problems with lcc-win32 (trimmed) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-08 01:06 +0000
                      Re: Problems with lcc-win32 (trimmed) jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-08 12:17 +0100
                        Assigning a struct to an integer (Was: Problems with lcc-win32 (trimmed)) gazelle@shell.xmission.com (Kenny McCormack) - 2017-03-08 11:40 +0000
                        Re: Problems with lcc-win32 (trimmed) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-08 11:51 +0000
                Re: Problems with lcc-win32 (trimmed) Robert Wessel <robertwessel2@yahoo.com> - 2017-03-07 15:27 -0600
                  Re: Problems with lcc-win32 (trimmed) scott@slp53.sl.home (Scott Lurndal) - 2017-03-08 13:50 +0000
                  Re: Problems with lcc-win32 (trimmed) scott@slp53.sl.home (Scott Lurndal) - 2017-03-08 13:51 +0000

Page 2 of 2 — ← Prev page 1 [2]

#105466

On Monday, March 6, 2017 at 00:45:07 UTC+1 jacob navia wrote:
> Thanks. At least if they are hard for you, I can agree that they would 
> be also hard for me to see. I do not see any real show stopper however.

I have to disagree here. If you compile and run testlcc_3.c you will see
that lcc-win32 produces wrong code! Comparisons that are evaluated wrong.
A while loop that is entered although the condition is false.
This are show stoppers.
Gcc, clang, icc, cl (from M$), bcc32 and tcc have no problems like these.

Probably you have a test suite to test lcc-win32.
I think that your test suite should be improved, since
the Seed7 test suite finds errors in your lcc-win32.

> The compiler is working and is a nice back end for language work.

Not for me. I tried to code around the weaknesses of lcc-win32,
but this has limits. As long as the bugs are not fixed I cannot
use lcc-win32 as back end for Seed7, sorry. I have a makefile to
compile Seed7 with lcc-win32 and as soon as the Seed7 test suite
passes I will release it.

Sorry for my unfriendly criticism.

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]

#105493

Le 05/03/2017 à 23:12, mertesthomas@gmail.com a écrit :

> The test programs follow:
>
> ========== begin testlcc.c ==========
> /*  Compile with:
>  *  lc -O -g5 -A testlcc.c -o testlcc.exe
>  */
>
> #include "stdio.h"
>
> typedef enum {ILLEGALCHAR, EOFCHAR, LETTERCHAR, DIGITCHAR,
>     UNDERLINECHAR, SHARPCHAR, QUOTATIONCHAR, APOSTROPHECHAR,
>     LEFTPARENCHAR, PARENCHAR, SPECIALCHAR, SPACECHAR,
>     NEWLINECHAR} charClass;
>
> typedef int boolType;
>
> charClass ch_class[256 - EOF];
> boolType ch_op[256 - EOF];
>
> #define char_class(CHARACTER) ch_class [((int)(CHARACTER)) - EOF]
> #define op_char(CHARACTER)    ch_op    [((int)(CHARACTER)) - EOF]
>
> void get_ident (unsigned char *name, unsigned int length)
> {
>   printf("length:\n%d        # should be: 1\n", length);
>   printf("name[0]:\n'%c' (%d) # should be: '$' (36)\n",
>           name[0], name[0]);
>   printf("op_char(name[0]):\n%d        # should be: 1\n",
>           op_char(name[0]));
>   printf("char_class(name[0]):\n%2d       # should be: 10\n",
>           char_class(name[0]));
>   printf("char_class(name[0])==LEFTPARENCHAR:\n");
>   printf("%d        # should be: 0\n",
>           char_class(name[0])==LEFTPARENCHAR);
>   printf("op_char(name[0]) || "
>          "char_class(name[0])==LEFTPARENCHAR:\n");
>   printf("%d        # should be: 1\n",
>           op_char(name[0]) ||
>           char_class(name[0])==LEFTPARENCHAR);
>   printf("char_class(name[0])==PARENCHAR:\n");
>   printf("%d        # should be: 0\n",
>           char_class(name[0])==PARENCHAR);
>   printf("op_char(name[0]) || "
>          "char_class(name[0])==LEFTPARENCHAR || "
>          "char_class(name[0])==PARENCHAR:\n");
>   printf("%d        # should be 1\n",
>           op_char(name[0]) ||
>           char_class(name[0])==LEFTPARENCHAR ||
>           char_class(name[0])==PARENCHAR);
>   printf("length==1 && (op_char(name[0]) || "
>          "char_class(name[0])==LEFTPARENCHAR || "
>          "char_class(name[0])==PARENCHAR):\n");
>   printf("%d        # should be 1\n",
>           length==1 && (op_char(name[0]) ||
>                         char_class(name[0])==LEFTPARENCHAR ||
>                         char_class(name[0])==PARENCHAR));
> }
>
> int main (int argc, char *argv[])
> {
>   char_class('$') = SPECIALCHAR;
>   op_char('$') = 1;
>   get_ident("$", 1);
> }
> ========== end testlcc.c ==========

This test RUNS PERFECTLY WELL both with lcc-win32 or with lcc-win64.
You are not using the LATEST VERSION!
Please before reporting bugs download the latest version. I have 
corrected this bug.

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

This compiles OK with lcc-win64. The 32 bit compiler has a problem. 
Please use lcc-win64, the 32 bits version is no longer maintained.

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

This has a problem with test 1. The line

 >     if (unsigned_result > -(uint64Type) INT64TYPE_MIN)

emits a signed comparison and not an unsigned one. This is an error
and will be corrected in the next release.

This is the only bug I found in your tests.

Again, thanks for your input.

jacob

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

#105496 — Re: Problems with lcc-win32 (trimmed)

Le 06/03/2017 à 18:15, jacobnavia a écrit :
> Le 05/03/2017 à 23:12, mertesthomas@gmail.com a écrit :
>
>> The test programs follow:
>>
>> ========== begin testlcc.c ==========
[snip]
>
> This test RUNS PERFECTLY WELL both with lcc-win32 or with lcc-win64.
> You are not using the LATEST VERSION!
> Please before reporting bugs download the latest version. I have
> corrected this bug.
>
>>
>>
>> ========== begin testlcc_2.c ==========
>
> This compiles OK with lcc-win64. The 32 bit compiler has a problem.
> Please use lcc-win64, the 32 bits version is no longer maintained.
>
>>
>> ========== begin testlcc_3.c ==========
>> ========== end testlcc_3.c ==========
>>
>
> This has a problem with test 1. The line
>
>>     if (unsigned_result > -(uint64Type) INT64TYPE_MIN)
>
> emits a signed comparison and not an unsigned one. This is an error
> and will be corrected in the next release.
>
> This is the only bug I found in your tests.
>
> Again, thanks for your input.
>
> jacob
>

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

#105518 — Re: Problems with lcc-win32 (trimmed)

On Monday, March 6, 2017 at 18:50:31 UTC+1 jacobnavia wrote:
> Le 06/03/2017 à 18:15, jacobnavia a écrit :
> > Le 05/03/2017 à 23:12, mertesthomas a écrit :
> >
> >> The test programs follow:
> >>
> >> ========== begin testlcc.c ==========
> [snip]
> >
> > This test RUNS PERFECTLY WELL both with lcc-win32 or with lcc-win64.

Testlcc.c runs also perfectly well on my machine.
IIRC I already sent testlcc.c to you in 2011.
I attached testlcc.c just for completeness.

> > You are not using the LATEST VERSION!

The command lcc -v writes:
Logiciels/Informatique lcc-win32 version 3.8. Compilation date: Mar 29 2013 13:11:27

IIRC I downloaded lcc-win64 from:
https://www.cs.virginia.edu/~lcc-win32/
AFAIK lcc-win64 has also a 32 bit version, which I use.

[snip]
> >> ========== begin testlcc_2.c ==========
> >
> > This compiles OK with lcc-win64. The 32 bit compiler has a problem.
> > Please use lcc-win64, the 32 bits version is no longer maintained.

Lcc-win32 is no longer maintained?
My bug report is about lcc-win32.

[snip]
> >> ========== begin testlcc_3.c ==========
> >> ========== end testlcc_3.c ==========
> >>
> >
> > This has a problem with test 1. The line
> >
> >>     if (unsigned_result > -(uint64Type) INT64TYPE_MIN)
> >
> > emits a signed comparison and not an unsigned one. This is an error
> > and will be corrected in the next release.

Are you referring to lcc-win32 or lcc-win64?
As I said my bug report is about lcc-win32.

What is with the problem, when the option -I contains spaces.
E.g.: "-I\"C:\\Program Files (x86)/MariaDB/MariaDB C Client Library/include\"
It seems to just add "C:\Program" to the include search path.

What about that lcc-win32 seems to generate inf instead of -inf.

In the meantime I stumbled over the function fseeki64().
The call fseeki64(4, 54, 0) returns 54.
According to the definition a successful fseeki64() should return 0.
A nonzero value like 54 indicates an error, but errno is 0.
But the file exists and is larger than 54 bytes.
With other compilers/run-times seeking this file just works.

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]

#105519 — Re: Problems with lcc-win32 (trimmed)

Le 07/03/2017 à 13:50, mertesthomas@gmail.com a écrit :
> In the meantime I stumbled over the function fseeki64().
> The call fseeki64(4, 54, 0) returns 54.

????

fseek takes
1) File pointer (first arg)
2) offset
3) "FROM parameter

What is that "4" doing there?

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

#105520 — Re: Problems with lcc-win32 (trimmed)

On Tuesday, March 7, 2017 at 18:50:31 UTC+1 jacobnavia wrote: 
> Le 07/03/2017 à 13:50, mertesthomas a écrit :
> > In the meantime I stumbled over the function fseeki64().
> > The call fseeki64(4, 54, 0) returns 54.
> 
> ????
> 
> fseek takes
> 1) File pointer (first arg)
> 2) offset
> 3) "FROM parameter
> 
> What is that "4" doing there?

Sorry, I just copied my debug log, which contained the
file descriptor number (fd). The actual call of fseeki64()
uses a FILE pointer, as you said.

Probably fseeki64() tries to return the resulting offset
location, like lseek() does. But fseek() and fseeki64()
are defined different and they should return 0 on success.

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]

#105521 — Re: Problems with lcc-win32 (trimmed)

mertesthomas@gmail.com writes:
>On Tuesday, March 7, 2017 at 18:50:31 UTC+1 jacobnavia wrote:=20
>> Le 07/03/2017 =C3=A0 13:50, mertesthomas a =C3=A9crit :
>> > In the meantime I stumbled over the function fseeki64().
>> > The call fseeki64(4, 54, 0) returns 54.
>>=20
>> ????
>>=20
>> fseek takes
>> 1) File pointer (first arg)
>> 2) offset
>> 3) "FROM parameter
>>=20
>> What is that "4" doing there?
>
>Sorry, I just copied my debug log, which contained the
>file descriptor number (fd). The actual call of fseeki64()
>uses a FILE pointer, as you said.
>
>Probably fseeki64() tries to return the resulting offset
>location, like lseek() does. But fseek() and fseeki64()
>are defined different and they should return 0 on success.

Had to look that one up.  I see  it is a microsoft private
interface only required because they chose to make 'long'
32-bits on amd64/x86_64 systems.

The return value is described as:

   "If successful, fseek and _fseeki64 returns 0. Otherwise,
    it returns a nonzero value. On devices incapable of seeking,
    the return value is undefined. If stream is a null pointer,
    or if origin is not one of allowed values described below,
    fseek and _fseeki64 invoke the invalid parameter handler, as
    described in Parameter Validation. If execution is allowed to
    continue, these functions set errno to EINVAL and return -1."

So, if unsuccessful, it can return anything, and apparently does.

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

#105523 — Re: Problems with lcc-win32 (trimmed)

On Tuesday, March 7, 2017 at 16:02:09 UTC+1 schrieb Scott Lurndal wrote:
> mertesthomas writes:
> >On Tuesday, March 7, 2017 at 18:50:31 UTC+1 jacobnavia wrote:=20
> >> Le 07/03/2017 =C3=A0 13:50, mertesthomas a =C3=A9crit :
> >> > In the meantime I stumbled over the function fseeki64().
> >> > The call fseeki64(4, 54, 0) returns 54.
> >>=20
> >> ????
> >>=20
> >> fseek takes
> >> 1) File pointer (first arg)
> >> 2) offset
> >> 3) "FROM parameter
> >>=20
> >> What is that "4" doing there?
> >
> >Sorry, I just copied my debug log, which contained the
> >file descriptor number (fd). The actual call of fseeki64()
> >uses a FILE pointer, as you said.
> >
> >Probably fseeki64() tries to return the resulting offset
> >location, like lseek() does. But fseek() and fseeki64()
> >are defined different and they should return 0 on success.
> 
> Had to look that one up.  I see  it is a microsoft private
> interface only required because they chose to make 'long'
> 32-bits on amd64/x86_64 systems.
> 
> The return value is described as:
> 
>    "If successful, fseek and _fseeki64 returns 0. Otherwise,
>     it returns a nonzero value. On devices incapable of seeking,
>     the return value is undefined. If stream is a null pointer,
>     or if origin is not one of allowed values described below,
>     fseek and _fseeki64 invoke the invalid parameter handler, as
>     described in Parameter Validation. If execution is allowed to
>     continue, these functions set errno to EINVAL and return -1."
> 
> So, if unsuccessful, it can return anything, and apparently does.

Yes, you are right that according to the documentation from Microsoft
an unsuccessful fseeki64() can return anything.
But we are not talking about fseeki64() implemented by Microsoft.
I did not even link with the msvcrt library.
AFAIK this fseeki64() is part of the lcc-win32 runtime.

And there is just no reason why it should be unsuccessful.
The file is a regular file, it exists, it has been opened successfully,
it is not used or locked by another process. 

When I use MinGW, Cygwin, Clang, cl (stand alone compiler from Visual C),
bcc32 (from Borland) or tcc (Tiny C) with the corresponding runtime
library (maybe some of them use msvcrt, but I never explicitly link with it)
the same calls of fseeki64() succeed.

For that reasons I guess that there might be a bug
in the lcc-win32 version of fseeki64().

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]

#105526 — Re: Problems with lcc-win32 (trimmed)

Hi

As I said, impossible for me to debug that.

Here is the code for fseeki64. Could you please compile that and see if 
it works?

Thanks
------------------------------------------------------fseeki64.c
#include <windows.h>
#include <errno.h>
#include <stdio.h>
long long fseeki64(FILE *f,long long offset,int origin)
{
     if (f == NULL)
         return -1;
     fflush(f);
     void *handle = (HANDLE)_get_osfhandle(_fileno(f));
     long result;
     long long r;
     LARGE_INTEGER Offset;

     if (handle == (HANDLE)-1) {
         errno = EBADF;
         return -1;
     }
     if (origin != 0 && origin != 1 && origin != 2) {
         errno = EINVAL;
         return -1;
     }
     memcpy(&Offset,&offset,sizeof(long long));
     SetLastError(0);
     result = SetFilePointerEx(handle,Offset,(PLARGE_INTEGER)&r,origin);
     if (result == 0) {
         errno = GetLastError();
     }
     return !result;
}
----------------------------------------------------------------------

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

#105550 — Re: Problems with lcc-win32 (trimmed)

jacobnavia <jacob@jacob.remcomp.fr> writes:
<snip>
> Here is the code for fseeki64. Could you please compile that and see if it works?
>
> Thanks
> ------------------------------------------------------fseeki64.c
> #include <windows.h>
> #include <errno.h>
> #include <stdio.h>
> long long fseeki64(FILE *f,long long offset,int origin)
> {
>     if (f == NULL)
>         return -1;
>     fflush(f);
>     void *handle = (HANDLE)_get_osfhandle(_fileno(f));
>     long result;
>     long long r;
>     LARGE_INTEGER Offset;
>
>     if (handle == (HANDLE)-1) {
>         errno = EBADF;
>         return -1;
>     }
>     if (origin != 0 && origin != 1 && origin != 2) {
>         errno = EINVAL;
>         return -1;
>     }
>     memcpy(&Offset,&offset,sizeof(long long));
>     SetLastError(0);
>     result = SetFilePointerEx(handle,Offset,(PLARGE_INTEGER)&r,origin);
>     if (result == 0) {
>         errno = GetLastError();
>     }
>     return !result;
> }
> ----------------------------------------------------------------------

That's a strange bit of code.  The strangest thing is the memcpy.  I
can't see why you'd do that rather than write

  long result = SetFilePointerEx(handle, offset, NULL, origin);

Presumably there is a prototype in scope so offset will be converted to
LARGE_INTEGER as if by assignment.  If there is no prototype then

  long result = SetFilePointerEx(handle, (LARGE_INTEGER)offset, NULL, origin);

would do, I think.  Am I missing something?

-- 
Ben.

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

#105566 — Re: Problems with lcc-win32 (trimmed)

Le 08/03/2017 à 02:06, Ben Bacarisse a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
> <snip>
>> Here is the code for fseeki64. Could you please compile that and see if it works?
>>
>> Thanks
>> ------------------------------------------------------fseeki64.c
>> #include <windows.h>
>> #include <errno.h>
>> #include <stdio.h>
>> long long fseeki64(FILE *f,long long offset,int origin)
>> {
>>     if (f == NULL)
>>         return -1;
>>     fflush(f);
>>     void *handle = (HANDLE)_get_osfhandle(_fileno(f));
>>     long result;
>>     long long r;
>>     LARGE_INTEGER Offset;
>>
>>     if (handle == (HANDLE)-1) {
>>         errno = EBADF;
>>         return -1;
>>     }
>>     if (origin != 0 && origin != 1 && origin != 2) {
>>         errno = EINVAL;
>>         return -1;
>>     }
>>     memcpy(&Offset,&offset,sizeof(long long));
>>     SetLastError(0);
>>     result = SetFilePointerEx(handle,Offset,(PLARGE_INTEGER)&r,origin);
>>     if (result == 0) {
>>         errno = GetLastError();
>>     }
>>     return !result;
>> }
>> ----------------------------------------------------------------------
>
> That's a strange bit of code.  The strangest thing is the memcpy.  I
> can't see why you'd do that rather than write
>
>   long result = SetFilePointerEx(handle, offset, NULL, origin);
>
> Presumably there is a prototype in scope so offset will be converted to
> LARGE_INTEGER as if by assignment.  If there is no prototype then
>
>   long result = SetFilePointerEx(handle, (LARGE_INTEGER)offset, NULL, origin);
>
> would do, I think.  Am I missing something?
>

Look, I wrote that function under 32 bits windows, some 15 years ago at 
least. What I remember is that LARGE_INTEGER was a STRUCTURE of two 
fields: high and low, of 32 bits each. You can't assign a structure to 
an integer even if they are the same length.

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

#105567 — Assigning a struct to an integer (Was: Problems with lcc-win32 (trimmed))

In article <o9op2i$amm$1@dont-email.me>,
jacobnavia  <jacob@jacob.remcomp.fr> wrote:
...
>fields: high and low, of 32 bits each. You can't assign a structure to 
>an integer even if they are the same length.

Yes, you can.  This program works as expected (yes, it may not be
"portable" as that term is used in this group, but I don't care.  I doubt
Jacob does either).

#include <stdio.h>

int main(void)
{
    struct foo { int a,b; } bar;
    long long verylong;

    bar.a = bar.b = 1;		/* Try various values here */
    verylong = * (long long *) &bar;
    printf("verylong = %lld\n",verylong);
    printf("sizeof int = %d, sizeof long = %d, sizeof long long = %d\n",
	sizeof(int), sizeof(long), sizeof(long long));
}

-- 
[Donald] Trump didn't have it all handed to him by his parents,
like Hillary Clinton did.

	- Some dumb cluck in Ohio; featured in Michael Moore's "Trumpland" -

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

#105568 — Re: Problems with lcc-win32 (trimmed)

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 08/03/2017 à 02:06, Ben Bacarisse a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> <snip>
>>> Here is the code for fseeki64. Could you please compile that and see if it works?
>>>
>>> Thanks
>>> ------------------------------------------------------fseeki64.c
>>> #include <windows.h>
>>> #include <errno.h>
>>> #include <stdio.h>
>>> long long fseeki64(FILE *f,long long offset,int origin)
>>> {
>>>     if (f == NULL)
>>>         return -1;
>>>     fflush(f);
>>>     void *handle = (HANDLE)_get_osfhandle(_fileno(f));
>>>     long result;
>>>     long long r;
>>>     LARGE_INTEGER Offset;
>>>
>>>     if (handle == (HANDLE)-1) {
>>>         errno = EBADF;
>>>         return -1;
>>>     }
>>>     if (origin != 0 && origin != 1 && origin != 2) {
>>>         errno = EINVAL;
>>>         return -1;
>>>     }
>>>     memcpy(&Offset,&offset,sizeof(long long));
>>>     SetLastError(0);
>>>     result = SetFilePointerEx(handle,Offset,(PLARGE_INTEGER)&r,origin);
>>>     if (result == 0) {
>>>         errno = GetLastError();
>>>     }
>>>     return !result;
>>> }
>>> ----------------------------------------------------------------------
>>
>> That's a strange bit of code.  The strangest thing is the memcpy.  I
>> can't see why you'd do that rather than write
>>
>>   long result = SetFilePointerEx(handle, offset, NULL, origin);
>>
>> Presumably there is a prototype in scope so offset will be converted to
>> LARGE_INTEGER as if by assignment.  If there is no prototype then
>>
>>   long result = SetFilePointerEx(handle, (LARGE_INTEGER)offset, NULL, origin);
>>
>> would do, I think.  Am I missing something?
>
> Look, I wrote that function under 32 bits windows, some 15 years ago
> at least. What I remember is that LARGE_INTEGER was a STRUCTURE of two
> fields: high and low, of 32 bits each. You can't assign a structure to
> an integer even if they are the same length.

Ah, right, that's exactly the kind of thing I thought I might be
missing.  It did not seem likely that on a system with long long ints
you'd have LARGE_INTEGER be anything else (because it sounds like an
integer type), but the interface presumably dates from a time when MS C
did not have 64-bit integers.

It seems that nowadays it's a union so C99 provides a neat way to use
the interface:

  SetFilePointerEx(handle, (LARGE_INTEGER){.QuadPart = offset}, NULL, origin);

It's a shame that MS chose a name that suggests an integer type, but
that can't be helped.

-- 
Ben.

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

#105530 — Re: Problems with lcc-win32 (trimmed)

On Tue, 07 Mar 2017 15:02:00 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>mertesthomas@gmail.com writes:
>>On Tuesday, March 7, 2017 at 18:50:31 UTC+1 jacobnavia wrote:=20
>>> Le 07/03/2017 =C3=A0 13:50, mertesthomas a =C3=A9crit :
>>> > In the meantime I stumbled over the function fseeki64().
>>> > The call fseeki64(4, 54, 0) returns 54.
>>>=20
>>> ????
>>>=20
>>> fseek takes
>>> 1) File pointer (first arg)
>>> 2) offset
>>> 3) "FROM parameter
>>>=20
>>> What is that "4" doing there?
>>
>>Sorry, I just copied my debug log, which contained the
>>file descriptor number (fd). The actual call of fseeki64()
>>uses a FILE pointer, as you said.
>>
>>Probably fseeki64() tries to return the resulting offset
>>location, like lseek() does. But fseek() and fseeki64()
>>are defined different and they should return 0 on success.
>
>Had to look that one up.  I see  it is a microsoft private
>interface only required because they chose to make 'long'
>32-bits on amd64/x86_64 systems.


In MS's defense, _fseeki64 has been part of their 32-bit C library for
a long time.  The notion that the file offset could be limited to 32
bits was broken a decade before C89 was finished.

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

#105572 — Re: Problems with lcc-win32 (trimmed)

Robert Wessel <robertwessel2@yahoo.com> writes:
>On Tue, 07 Mar 2017 15:02:00 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>mertesthomas@gmail.com writes:
>>>On Tuesday, March 7, 2017 at 18:50:31 UTC+1 jacobnavia wrote:=20
>>>> Le 07/03/2017 =C3=A0 13:50, mertesthomas a =C3=A9crit :
>>>> > In the meantime I stumbled over the function fseeki64().
>>>> > The call fseeki64(4, 54, 0) returns 54.
>>>>=20
>>>> ????
>>>>=20
>>>> fseek takes
>>>> 1) File pointer (first arg)
>>>> 2) offset
>>>> 3) "FROM parameter
>>>>=20
>>>> What is that "4" doing there?
>>>
>>>Sorry, I just copied my debug log, which contained the
>>>file descriptor number (fd). The actual call of fseeki64()
>>>uses a FILE pointer, as you said.
>>>
>>>Probably fseeki64() tries to return the resulting offset
>>>location, like lseek() does. But fseek() and fseeki64()
>>>are defined different and they should return 0 on success.
>>
>>Had to look that one up.  I see  it is a microsoft private
>>interface only required because they chose to make 'long'
>>32-bits on amd64/x86_64 systems.
>
>
>In MS's defense, _fseeki64 has been part of their 32-bit C library for
>a long time.  The notion that the file offset could be limited to 32
>bits was broken a decade before C89 was finished.

Which is why unix did LFS in the mid 90's.

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

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

#105573 — Re: Problems with lcc-win32 (trimmed)

Robert Wessel <robertwessel2@yahoo.com> writes:
>On Tue, 07 Mar 2017 15:02:00 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>mertesthomas@gmail.com writes:
>>>On Tuesday, March 7, 2017 at 18:50:31 UTC+1 jacobnavia wrote:=20
>>>> Le 07/03/2017 =C3=A0 13:50, mertesthomas a =C3=A9crit :
>>>> > In the meantime I stumbled over the function fseeki64().
>>>> > The call fseeki64(4, 54, 0) returns 54.
>>>>=20
>>>> ????
>>>>=20
>>>> fseek takes
>>>> 1) File pointer (first arg)
>>>> 2) offset
>>>> 3) "FROM parameter
>>>>=20
>>>> What is that "4" doing there?
>>>
>>>Sorry, I just copied my debug log, which contained the
>>>file descriptor number (fd). The actual call of fseeki64()
>>>uses a FILE pointer, as you said.
>>>
>>>Probably fseeki64() tries to return the resulting offset
>>>location, like lseek() does. But fseek() and fseeki64()
>>>are defined different and they should return 0 on success.
>>
>>Had to look that one up.  I see  it is a microsoft private
>>interface only required because they chose to make 'long'
>>32-bits on amd64/x86_64 systems.
>
>
>In MS's defense, _fseeki64 has been part of their 32-bit C library for
>a long time.  The notion that the file offset could be limited to 32
>bits was broken a decade before C89 was finished.

My issue was with MS choosing to define 'long' as 32-bits, when it
makes much more sense for long and pointers to be the same size,
particularly when building applications for both 32-bit and 64-bit
operating environments.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web