Swipl is now on msys2 - Reply 1

General
1

Great! But … :frowning: … where has the prompt gone?

2

There isn’t any readline support either, so still some work to do. In the meantime, use „start swipl“ instead of „swipl“, then a new command window is opened and you have a prompt.

1 Like
3

Below are the warnings in current swipl-devel if I compile under current msys2. I’ll check them one by one, though I fear my insight is too limited to be of great use.

[Edit: my sources were not up to date with swipl-devel. I’ll send an update in a separate response.]

4

Updated list of warnings, sorry for the confusion.

[197/953] Building C object src/CMakeFiles/swiplobjs.dir/pl-alloc.c.obj
In function 'tmp_realloc',
    inlined from 'stack_realloc' at C:/msys64/home/c7201178/swipl-devel/src/pl-alloc.c:1612:15:
C:/msys64/home/c7201178/swipl-devel/src/pl-alloc.c:1574:15: warning: 'realloc' called on a pointer to an unallocated object '18446744073709551608' [-Wfree-nonheap-object]
 1574 |   if ( (mem = realloc(sp, size+sizeof(size_t))) )
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[239/953] Building C object packages/clib/CMakeFiles/plugin_crypt.dir/bsd-crypt.c.obj
In function 'init_des',
    inlined from 'des_setkey' at C:/msys64/home/c7201178/swipl-devel/packages/clib/bsd-crypt.c:622:3,
    inlined from 'crypt' at C:/msys64/home/c7201178/swipl-devel/packages/clib/bsd-crypt.c:523:6:
C:/msys64/home/c7201178/swipl-devel/packages/clib/bsd-crypt.c:848:9: warning: 'init_perm.constprop' accessing 2048 bytes in a region of size 1024 [-Wstringop-overflow=]
  848 |         init_perm(IE3264, perm, 4, 8);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/msys64/home/c7201178/swipl-devel/packages/clib/bsd-crypt.c: In function 'crypt':
C:/msys64/home/c7201178/swipl-devel/packages/clib/bsd-crypt.c:848:9: note: referencing argument 1 of type 'C_block (*)[16]'
C:/msys64/home/c7201178/swipl-devel/packages/clib/bsd-crypt.c:910:1: note: in a call to function 'init_perm.constprop'
  910 | init_perm(C_block perm[64/CHUNKBITS][1<<CHUNKBITS], const unsigned char p[64],
      | ^~~~~~~~~
5

As for the realloc warning I don’t really see the problem. But then, most systems will use the memory mapping based implementation and I think MSYS can do that as well.

6

Actually, it can’t. It’s POSIX, not Windows. Anyway, I could make the realloc warning disappear, see the PR.

7

I made a second PR to make the warning in bsd-crypt.c disappear. Hope it makes sense.

8

I don’t think that is true. MSYS2 says:

MSYS2 is a collection of tools and libraries providing you with an easy-to-use environment for building, installing and running native Windows software

They use the MinGW GCC fork and provide the whole Windows API. AFAIK, the C runtime library that comes with it does have a couple more POSIX like functions.

That said, the SWI-Prolog code provides a set of functions that provide malloc() compatible functionality but uses memory mapping when possible such that the memory is really returned to the OS. That is used for the Prolog stacks and some other potentially large areas such as the buffer used to store findall/3 results. This has only been implemented to use mmap() though, not Windows VirtualAlloc().

Thanks. Did you push it? I do not see it.

9

Yes, indeed, VirtualAlloc would be needed instead of mmap.

I’ll check where the other PR got stuck.

10

Regarding the other warning (init_perm.constprop’ accessing 2048 bytes in a region of size 1024).

I can partially reproduce it on Linux, since bsd-crypt.c also includes a main for stand-alone use:

mkdir bsdcrypt
cd bsdcrypt
cp …/swipl-devel/packages/clib/bsd-crypt.c .
gcc -DMAIN bsd-crypt.c

matthias@DESKTOP-A2T8IFC:~/crypt$ gcc -DMAIN bsd-crypt.c
bsd-crypt.c: In function ‘init_des’:
bsd-crypt.c:848:9: warning: ‘init_perm’ accessing 2048 bytes in a region of size 1024 [-Wstringop-overflow=]
  848 |         init_perm(IE3264, perm, 4, 8);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bsd-crypt.c:848:9: note: referencing argument 1 of type ‘C_block (*)[16]’
bsd-crypt.c:910:1: note: in a call to function ‘init_perm’
  910 | init_perm(C_block perm[64/CHUNKBITS][1<<CHUNKBITS], const unsigned char p[64],
      | ^~~~~~~~~

I guess init_perm is “safe” in the sense that it is never invoked with pathological parameter settings, but the whole thing feels a bit awkward, see below for a simplified analogy.

int fun1(char buf[10])
{ for(int i=0; i<5; i++)
    buf[i]++;
  return 0;
}

int main()
{ char buf1[5];
  return fun1(buf1);
}

I’ll submit another PR (bit prettier than last time) for your consideration.

1 Like
11

I see. Just using int fun1(char *buf) should fix that. It makes not much sense to declare the size in the function and than call it with various sizes anyway.