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

#105450 — Problems with lcc-win32

Hello,

around 2011 I already tried to use lcc-win32 to compile Seed7.
Now I used lcc-win32 again, to compile Seed7. I found several things:

1. Probably around 2011 I produced a test program for lcc-win32. This program
seems to succeed with lcc-win32 from 2013. I attached testlcc.c just for
completenes.
2. 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.
3. A missing include file just triggers a warning. I had to change my test
programs to use something from the include file. This way I can recognize
when an include file is found by the C compiler.
4. I introduced a file that defines: _wchdir, _wgetcwd, _wmkdir, _wrmdir,
_wrename, _wremove and _wchmod. This functions are defined in your header
files, but missing in your run-time library. I can remember a discussion
with you about that in 2011.
5. I found out that an expression like:
int x = 0;
_Bool flag = argc != -1 ? x++, (_Bool) 1:(_Bool) 0;
triggers a compiler error (trap). See testlcc_2.c
I added the test above to my check program. This results in int beeing
used for boolean values.
6. I found several other things where lcc-win32 does not deliver the desired
result. See testlcc_3.c
7. When printing a double with %e or %f the precision seems to have an upper
limit, but this limit is not fix. I improved my code. Now I assume that
a precision up to 512 works always. Beyond that I do adjustments. I know
that such high precisions are strange, but Seed7 supports them and I have
testcases which failed with lcc-win32. With my fix this tests pass.
8. There is also a strange behavior with -inf. Lcc-win32 seems to generate
inf instead of -inf.
9. 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.

It would be really nice if this things could be fixed in lcc-win32.
There seem to be more bugs in lcc-win32, but it is hard to see them.

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


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


BTW.: I tried to use lcc-win64 also and failed even earlier.
When I have time I will send the problems I have with lcc-win64.

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]

#105451

On Sunday, March 5, 2017 at 4:12:50 PM UTC-6, mertes...@gmail.com wrote:
> Hello,
<snip>
> 
> BTW.: I tried to use lcc-win64 also and failed even earlier.
> When I have time I will send the problems I have with lcc-win64.

Not sure whether you tried, but it would be courteous to
send this sort of message privately to the maintainer.


-- 
Worms? in a can? this i gotta see

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

#105452

In article <c7239f0f-d376-4fb2-a0c5-6cd1389681a8@googlegroups.com>,
luser droog  <luser.droog@gmail.com> wrote:
>On Sunday, March 5, 2017 at 4:12:50 PM UTC-6, mertes...@gmail.com wrote:
>> Hello,
><snip>
>> 
>> BTW.: I tried to use lcc-win64 also and failed even earlier.
>> When I have time I will send the problems I have with lcc-win64.
>
>Not sure whether you tried, but it would be courteous to
>send this sort of message privately to the maintainer.

Totally disagree.  I am glad it was posted here; it makes for good reading.
Certainly more interesting that the usual fare of talking about prototyping
main() and (not) casting the return value of malloc().

And since Jacob reads this newsgroup, there's no need for a private email.
(And many newsgroup types specifically object to the practice of "taking it
to email" - for good reason!)

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Reaganomics

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

#105456

Le 05/03/2017 à 23:46, luser droog a écrit :
> On Sunday, March 5, 2017 at 4:12:50 PM UTC-6, mertes...@gmail.com wrote:
>> Hello,
> <snip>
>>
>> BTW.: I tried to use lcc-win64 also and failed even earlier.
>> When I have time I will send the problems I have with lcc-win64.
>
> Not sure whether you tried, but it would be courteous to
> send this sort of message privately to the maintainer.
>
>
He sent me a messsage and I couldn't answer because I can't do that 
right now. I did not know what to say and I said nothing, what was worst.

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

#105464

On Sunday, March 5, 2017 at 5:49:15 PM UTC-6, jacob navia wrote:
> Le 05/03/2017 à 23:46, luser droog a écrit :
> > On Sunday, March 5, 2017 at 4:12:50 PM UTC-6, mertes...@gmail.com wrote:
> >> Hello,
> > <snip>
> >>
> >> BTW.: I tried to use lcc-win64 also and failed even earlier.
> >> When I have time I will send the problems I have with lcc-win64.
> >
> > Not sure whether you tried, but it would be courteous to
> > send this sort of message privately to the maintainer.
> >
> >
> He sent me a messsage and I couldn't answer because I can't do that 
> right now. I did not know what to say and I said nothing, what was worst.

I see. I thought it might be something like that,
but just in case...

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

#105453

On 05/03/2017 22:12, mertesthomas@gmail.com wrote:
>
> around 2011 I already tried to use lcc-win32 to compile Seed7.
> Now I used lcc-win32 again, to compile Seed7. I found several things:

You should post reports to the dedicated newsgroup comp.compilers.lcc


-- 
Bartc

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

#105455

Le 06/03/2017 à 00:32, BartC a écrit :
> On 05/03/2017 22:12, mertesthomas@gmail.com wrote:
>>
>> around 2011 I already tried to use lcc-win32 to compile Seed7.
>> Now I used lcc-win32 again, to compile Seed7. I found several things:
>
> You should post reports to the dedicated newsgroup comp.compilers.lcc
>
>

No, its OK.

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

#105454

Le 05/03/2017 à 23:12, mertesthomas@gmail.com a écrit :
> Hello,
>
> around 2011 I already tried to use lcc-win32 to compile Seed7.
> Now I used lcc-win32 again, to compile Seed7. I found several things:
>
> 1. Probably around 2011 I produced a test program for lcc-win32. This program
> seems to succeed with lcc-win32 from 2013. I attached testlcc.c just for
> completenes.

Thanks

> 2. 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.

Yeah. I can send you the lc code if you want. I can't do anything right now.

I am writing an ARM 64 version and it is starting to work. Great fun.

> 3. A missing include file just triggers a warning. I had to change my test
> programs to use something from the include file. This way I can recognize
> when an include file is found by the C compiler.

Well, that can be fixed easily. Will do next week. Transform the warning 
in error. But...

I am too liberal maybe? People like errors instead of warnings?

What if you have an unused include missing? Nothing happens. Now all 
those builds would crash. Is that better?

What do you think?

> 4. I introduced a file that defines: _wchdir, _wgetcwd, _wmkdir, _wrmdir,
> _wrename, _wremove and _wchmod. This functions are defined in your header
> files, but missing in your run-time library. I can remember a discussion
> with you about that in 2011.

Yes, and I wrote those. Reload because I do remember doing them but now 
I am not using windows.

> 5. I found out that an expression like:
> int x = 0;
> _Bool flag = argc != -1 ? x++, (_Bool) 1:(_Bool) 0;

> triggers a compiler error (trap). See testlcc_2.c

Look, it is a simple compiler. Should I care a lot about that?

If argc is different than -1?

Argc is the count of the argument list. Either it is empty (and then you 
have the name of the program at the zero position) or it is bigger than 
one, meaning that you have argc-1 arguments. But anyway you have the 
right to compare it with minus one of course. So "x" will be always 
incremented and the result of the expression should be 1 since you have 
a comma expression in the first arm of the : operator.

I will see if that expression crashes in the 64 bit version. If yes I 
will try to fix it in the future.

> I added the test above to my check program. This results in int beeing
> used for boolean values.

> 6. I found several other things where lcc-win32 does not deliver the desired
> result. See testlcc_3.c

> 7. When printing a double with %e or %f the precision seems to have an upper
> limit, but this limit is not fix. I improved my code. Now I assume that
> a precision up to 512 works always. Beyond that I do adjustments. I know
> that such high precisions are strange, but Seed7 supports them and I have
> testcases which failed with lcc-win32. With my fix this tests pass.

Nice isn't it? 512 digits precision. It costed me a lot of work, all in 
assembler (the 4 operations kernel). It was great fun. But the 32 bit 
version is no longer maintained.

> 8. There is also a strange behavior with -inf. Lcc-win32 seems to generate
> inf instead of -inf.

Bad boy... should correct that.

> 9. 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.
>

> It would be really nice if this things could be fixed in lcc-win32.
> There seem to be more bugs in lcc-win32, but it is hard to see them.
>

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.
The compiler is working and is a nice back end for language work.

And if Seed would work with the machine in ways you never thought possible?

> The test programs follow:

Thanks. I will run them whenever I have a minute. But I am writing that 
ARM64 port and I have to deliver the new version at the end of March.

The customer that pays for the port needs his software soon, so I can't 
do anything else for the time being.

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

#105457

On 05/03/2017 23:44, jacob navia wrote:

>> 3. A missing include file just triggers a warning. I had to change my
>> test
>> programs to use something from the include file. This way I can recognize
>> when an include file is found by the C compiler.
>
> Well, that can be fixed easily. Will do next week. Transform the warning
> in error. But...
>
> I am too liberal maybe? People like errors instead of warnings?

A missing include can be important. Here:

    printf("%s",
        "I am"
    # include "not.c"
        " a number."
    );

if "not.c" (containing '" not"') is not found, it will still compile but 
print the opposite to what was intended.

So some message is necessary; a warning is OK provided it's seen, but 
it's easier to miss.

-- 
bartc

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

#105460

jacob navia <jacob@jacob.remcomp.fr> writes:
> Le 05/03/2017 à 23:12, mertesthomas@gmail.com a écrit :
[...]
>> 3. A missing include file just triggers a warning. I had to change my test
>> programs to use something from the include file. This way I can recognize
>> when an include file is found by the C compiler.
>
> Well, that can be fixed easily. Will do next week. Transform the warning 
> in error. But...
>
> I am too liberal maybe? People like errors instead of warnings?
>
> What if you have an unused include missing? Nothing happens. Now all 
> those builds would crash. Is that better?
>
> What do you think?
[...]

In my opinion a missing include file should be a fatal error.  (If it's
unused, then don't include it.)  That's certainly what I'm used to, and
every compiler I've tried bails out immediately if a header is missing
(it won't even try to diagnose any following errors).  I suspect a lot
of users would be very surprised to see a missing include diagnosed with
a non-fatal warning.

Feel free to consider the fact that I'm not an lcc-win user in deciding
how to deal with this.

On the other hand, some kind of conditional include might be a useful
extension, perhaps something like:

    #include_if_exists <some_header.h>

and/or

    #if_header_exists <some_header.h>
    /* ... */
    #else
    /* ... */
    #endif

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

#105468

On 06/03/17 04:35, Keith Thompson wrote:
> jacob navia <jacob@jacob.remcomp.fr> writes:
>> Le 05/03/2017 à 23:12, mertesthomas@gmail.com a écrit :
> [...]
>>> 3. A missing include file just triggers a warning. I had to change my test
>>> programs to use something from the include file. This way I can recognize
>>> when an include file is found by the C compiler.
>>
>> Well, that can be fixed easily. Will do next week. Transform the warning 
>> in error. But...
>>
>> I am too liberal maybe? People like errors instead of warnings?
>>
>> What if you have an unused include missing? Nothing happens. Now all 
>> those builds would crash. Is that better?
>>
>> What do you think?
> [...]
> 
> In my opinion a missing include file should be a fatal error.  (If it's
> unused, then don't include it.)  That's certainly what I'm used to, and
> every compiler I've tried bails out immediately if a header is missing
> (it won't even try to diagnose any following errors).  I suspect a lot
> of users would be very surprised to see a missing include diagnosed with
> a non-fatal warning.

I agree entirely - I find it hard to imagine many use-cases for when a
specified #include file does not exist and yet the compilation can
reasonably continue without it.  I would say that when an include file
is missing, the compiler should stop there and then with the error
message - it is most likely to be an error on the part of the user.

(Of course, it's fine to have a missing include if that directive is
skipped by conditional compilation.)

> 
> Feel free to consider the fact that I'm not an lcc-win user in deciding
> how to deal with this.
> 
> On the other hand, some kind of conditional include might be a useful
> extension, perhaps something like:
> 
>     #include_if_exists <some_header.h>
> 
> and/or
> 
>     #if_header_exists <some_header.h>
>     /* ... */
>     #else
>     /* ... */
>     #endif
> 

I can see this second form having some merit, and it would provide more
flexibility than the first suggestion.  It would let you write things like:

#if_header_exists <super_enhanced_printf.h>
	#include <super_enhanced_printf.h>
	#define printf super_enhanced_printf
#else
	#include <stdio.h>
#endif

However, if someone is going to implement such a feature, then I would
strongly recommend implementing it as "__has_include" :

#if __has_include(<super_enhanced_printf.h>)
...

Several other compilers, including MSVC, gcc and clang, have this
feature already - it makes sense to use the same syntax for the same
feature.  Non-standard extensions should be standardised where possible!

<http://clang.llvm.org/docs/LanguageExtensions.html#__has_include>

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

#105471

On 03/06/2017 04:26 AM, David Brown wrote:
> On 06/03/17 04:35, Keith Thompson wrote:
...
>> In my opinion a missing include file should be a fatal error.  (If it's
>> unused, then don't include it.)  That's certainly what I'm used to, and
>> every compiler I've tried bails out immediately if a header is missing
>> (it won't even try to diagnose any following errors).  I suspect a lot
>> of users would be very surprised to see a missing include diagnosed with
>> a non-fatal warning.
> 
> I agree entirely - I find it hard to imagine many use-cases for when a
> specified #include file does not exist and yet the compilation can
> reasonably continue without it.  I would say that when an include file
> is missing, the compiler should stop there and then with the error
> message - it is most likely to be an error on the part of the user.

I agree. In my experience, a missing #include file should always be a
fatal error. Of course, unless you're still using C90, a missing
#include file will usually cause a fatal error somewhere else - if it
doesn't, that usually means you didn't need to #include it. However, I
can think of two main exceptions:

If #definition of a macro is optional, my code referring to that macro
will either check whether it's #defined, or will use it in a #if
condition carefully designed to depend upon the fact that if it is not
#defined, it will be replaced by a 0. If the #include file where it was
#defined cannot be found, such code will silently treat it the same as
if it were un#defined, rather than catastrophically failing. I would
want it to fail catastrophically in that case.

The other case is when an identifier with external linkage is declared
in a header file, and defined in a source code file. The definition
serves as a perfectly good declaration for the identifier, so you don't
need to #include the header to make that file compile properly. However,
 it still is a good idea to #include the header in the file where it is
defined, because if the type of the declaration is not compatible with
the type of the definition, a diagnostic is mandatory, and that's
something I definitely want to know about. If a missing #include file
was a non-fatal error, that wouldn't necessarily work as intended. It
might work, if the interface to the function involves types that are
also declared in that same header, but that's not always the case.

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

#105488

David Brown <david.brown@hesbynett.no> writes:

> On 06/03/17 04:35, Keith Thompson wrote:
>> jacob navia <jacob@jacob.remcomp.fr> writes:
>>> Le 05/03/2017 à 23:12, mertesthomas@gmail.com a écrit :
>> [...]
>>>> 3. A missing include file just triggers a warning. I had to change my test
>>>> programs to use something from the include file. This way I can recognize
>>>> when an include file is found by the C compiler.
>>>
>>> Well, that can be fixed easily. Will do next week. Transform the warning 
>>> in error. But...
>>>
>>> I am too liberal maybe? People like errors instead of warnings?
>>>
>>> What if you have an unused include missing? Nothing happens. Now all 
>>> those builds would crash. Is that better?
>>>
>>> What do you think?
>> [...]
>> 
>> In my opinion a missing include file should be a fatal error.  (If it's
>> unused, then don't include it.)  That's certainly what I'm used to, and
>> every compiler I've tried bails out immediately if a header is missing
>> (it won't even try to diagnose any following errors).  I suspect a lot
>> of users would be very surprised to see a missing include diagnosed with
>> a non-fatal warning.
>
> I agree entirely - I find it hard to imagine many use-cases for when a
> specified #include file does not exist and yet the compilation can
> reasonably continue without it.  I would say that when an include file
> is missing, the compiler should stop there and then with the error
> message - it is most likely to be an error on the part of the user.
>
> (Of course, it's fine to have a missing include if that directive is
> skipped by conditional compilation.)
>
>> 
>> Feel free to consider the fact that I'm not an lcc-win user in deciding
>> how to deal with this.
>> 
>> On the other hand, some kind of conditional include might be a useful
>> extension, perhaps something like:
>> 
>>     #include_if_exists <some_header.h>
>> 
>> and/or
>> 
>>     #if_header_exists <some_header.h>
>>     /* ... */
>>     #else
>>     /* ... */
>>     #endif
>> 
>
> I can see this second form having some merit, and it would provide more
> flexibility than the first suggestion.  It would let you write things like:
>
> #if_header_exists <super_enhanced_printf.h>
> 	#include <super_enhanced_printf.h>
> 	#define printf super_enhanced_printf
> #else
> 	#include <stdio.h>
> #endif
>
> However, if someone is going to implement such a feature, then I would
> strongly recommend implementing it as "__has_include" :
>
> #if __has_include(<super_enhanced_printf.h>)
> ...
>
> Several other compilers, including MSVC, gcc and clang, have this
> feature already - it makes sense to use the same syntax for the same
> feature.  Non-standard extensions should be standardised where possible!
>
> <http://clang.llvm.org/docs/LanguageExtensions.html#__has_include>

I didn't know about that.  Note that __has_include (along with the
related __has_include_next) is implemented in gcc, starting with
release 5 I think, but does not appear to be documented either in
the gcc manual or in the cpp manual.

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

#105506

On 06/03/17 17:37, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>

>> However, if someone is going to implement such a feature, then I would
>> strongly recommend implementing it as "__has_include" :
>>
>> #if __has_include(<super_enhanced_printf.h>)
>> ...
>>
>> Several other compilers, including MSVC, gcc and clang, have this
>> feature already - it makes sense to use the same syntax for the same
>> feature.  Non-standard extensions should be standardised where possible!
>>
>> <http://clang.llvm.org/docs/LanguageExtensions.html#__has_include>
>
> I didn't know about that.  Note that __has_include (along with the
> related __has_include_next) is implemented in gcc, starting with
> release 5 I think, but does not appear to be documented either in
> the gcc manual or in the cpp manual.
>

Yes, I also tried and failed to find it in the manual.  I remembered 
reading about it in the changenotes for gcc (though I had to look it up 
to see which version).

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

#105479

Le lundi 6 mars 2017 04:34:07 UTC+1, Keith Thompson a écrit :
> In my opinion a missing include file should be a fatal error.  

Shared.  I don't even like the long list of errors which sometimes follow an header not found.  They are by-product of the first error and thus pure noise.  As that noise come closer to the first place I see -- then end of the compilation log -- I've lost too much time finding out that the root cause was a previous signaled error.  (There are errors for which it is meaningful to continue the compilation and signal subsequent one, IMHO this is not one)

> Feel free to consider the fact that I'm not an lcc-win user in deciding
> how to deal with this.

Neither am I.

> On the other hand, some kind of conditional include might be a useful
> extension, perhaps something like:
> 
>     #include_if_exists <some_header.h>
> 
> and/or
> 
>     #if_header_exists <some_header.h>

C++ has added __has_include(<some_header.h>).  If you create an extension, I'd suggest looking at the previous art that was normalized in that language related to C, there has already been quite a lot of inspiration both way and as a user of both, the cases when the later one choose to do something more or less subtly differently than the precursor are painful (I'm thinking of inline, where the issue is made worse by the fact it often would have been meaningful in a shared header if the C definition had followed C++ one). The preprocessor is a case where this make even more sense as there is very few things there which are dependent on the language.

Yours,

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

#105485

On 06/03/17 15:54, jm.bourguet@gmail.com wrote:
> Le lundi 6 mars 2017 04:34:07 UTC+1, Keith Thompson a écrit :
>> In my opinion a missing include file should be a fatal error.
> 
> Shared.  I don't even like the long list of errors which sometimes
> follow an header not found.  They are by-product of the first error
> and thus pure noise.  As that noise come closer to the first place I
> see -- then end of the compilation log -- I've lost too much time
> finding out that the root cause was a previous signaled error.
> (There are errors for which it is meaningful to continue the
> compilation and signal subsequent one, IMHO this is not one)
> 
>> Feel free to consider the fact that I'm not an lcc-win user in
>> deciding how to deal with this.
> 
> Neither am I.
> 
>> On the other hand, some kind of conditional include might be a
>> useful extension, perhaps something like:
>> 
>> #include_if_exists <some_header.h>
>> 
>> and/or
>> 
>> #if_header_exists <some_header.h>
> 
> C++ has added __has_include(<some_header.h>).

C++ does not have "__has_include".  A number of C++ compilers (gcc,
clang, MSVC, perhaps others) have it as an extension - for gcc and clang
it works in C as well as C++, but I don't know about MSVC.

With that correction, I agree that it would be the best choice for such
an extension - as I already wrote in a previous post.

>  If you create an
> extension, I'd suggest looking at the previous art that was
> normalized in that language related to C, there has already been
> quite a lot of inspiration both way and as a user of both, the cases
> when the later one choose to do something more or less subtly
> differently than the precursor are painful (I'm thinking of inline,
> where the issue is made worse by the fact it often would have been
> meaningful in a shared header if the C definition had followed C++
> one). The preprocessor is a case where this make even more sense as
> there is very few things there which are dependent on the language.
> 
> Yours,
> 

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

#105490

David Brown <david.brown@hesbynett.no> writes:
[...]
> C++ does not have "__has_include".  A number of C++ compilers (gcc,
> clang, MSVC, perhaps others) have it as an extension - for gcc and clang
> it works in C as well as C++, but I don't know about MSVC.
[...]

__has_include is a new feature in the upcoming C++17 standard (which is
relevant here because it strengthens the argument for using the same
syntax if a similar feature is added to C).

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

#105508

On 06/03/17 17:42, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> C++ does not have "__has_include".  A number of C++ compilers (gcc,
>> clang, MSVC, perhaps others) have it as an extension - for gcc and clang
>> it works in C as well as C++, but I don't know about MSVC.
> [...]
>
> __has_include is a new feature in the upcoming C++17 standard (which is
> relevant here because it strengthens the argument for using the same
> syntax if a similar feature is added to C).
>

Ah, I didn't realise it would be in C++17.  I think "it's the syntax 
several compilers use for the same C extension" is a good enough 
argument for using it in a C compiler - but "it's the syntax C++ will 
use" makes it even stronger.

That perhaps also explains why it is not documented in the gcc manual - 
it is part of the C++ language, so needs no documentation in the 
compiler manual.  But assuming gcc also allows it in C and C++ prior to 
C++17, then it should be mentioned as an extension.

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

#105491

Le lundi 6 mars 2017 17:18:47 UTC+1, David Brown a écrit :
> On 06/03/17 15:54, jm.bourguet@gmail.com wrote:
> > Le lundi 6 mars 2017 04:34:07 UTC+1, Keith Thompson a écrit :
> >> In my opinion a missing include file should be a fatal error.
> > 
> > Shared.  I don't even like the long list of errors which sometimes
> > follow an header not found.  They are by-product of the first error
> > and thus pure noise.  As that noise come closer to the first place I
> > see -- then end of the compilation log -- I've lost too much time
> > finding out that the root cause was a previous signaled error.
> > (There are errors for which it is meaningful to continue the
> > compilation and signal subsequent one, IMHO this is not one)
> > 
> >> Feel free to consider the fact that I'm not an lcc-win user in
> >> deciding how to deal with this.
> > 
> > Neither am I.
> > 
> >> On the other hand, some kind of conditional include might be a
> >> useful extension, perhaps something like:
> >> 
> >> #include_if_exists <some_header.h>
> >> 
> >> and/or
> >> 
> >> #if_header_exists <some_header.h>
> > 
> > C++ has added __has_include(<some_header.h>).
> 
> C++ does not have "__has_include".

It is (or will be? and this time there will be very few changes and I doubt any will touch that, especially that it was normalizing an existing practice) part of C++17. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4640.pdf

Yours,

-- 
Jean-Marc

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

#105509

On 06/03/17 17:44, jm.bourguet@gmail.com wrote:
> Le lundi 6 mars 2017 17:18:47 UTC+1, David Brown a écrit :
>> On 06/03/17 15:54, jm.bourguet@gmail.com wrote:

>>> C++ has added __has_include(<some_header.h>).
>>
>> C++ does not have "__has_include".
>
> It is (or will be? and this time there will be very few changes and I doubt any will touch that, especially that it was normalizing an existing practice) part of C++17. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4640.pdf
>

Sorry about that - I had looked at C++14, not C++17.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web