12:31 p.m.
Hi,
with latest git version under Ubuntu 18.04 I obtain a crash when running
the following script:
<hansl>
clear
set verbose off
function void simple (const int N[2::])
print "very simple"
end function
simple(1)
</hansl>
The shell prints:
<shell-output>
free(): double free detected in tcache 2
Aborted (core dumped)
<shell-output>
Hope that helps.
Artur
1:06 p.m.
Am 03.03.2021 um 13:31 schrieb atecon:
with latest git version under Ubuntu 18.04 I obtain a crash when
running the following script:
Confirmed with a recent snapshot on Windows. That one
looks pretty bad,
but...
function void simple (const int N[2::])
...it doesn't crash anymore for me when removing "const". And only
Artur
would put a const in front of an int ;-)
Actually, I believe it is not supported by hansl to do "const int": The
guide says "the const modifier may be used... for all the types that
support the pointer apparatus". And if you try the following function:
<hansl>
function void simplestar ( int *N)
print "very simple"
end function
</hansl>
you get the error message "unknown data type 'int *'". You have to use
"scalar *N" instead. And indeed, the variant "const scalar N[2::])"
works and doesn't crash.
But of course the above is a bad bug anyway, and "const int" should be
intercepted by gretl in the first place.
thanks
sven
1:49 p.m.
Am 03.03.2021 14:06 schrieb Sven Schreiber:
Am 03.03.2021 um 13:31 schrieb atecon:
>
> with latest git version under Ubuntu 18.04 I obtain a crash when
> running the following script:
Confirmed with a recent snapshot on Windows. That one looks pretty bad,
but...
Thanks for confirming this, Sven.
>
> function void simple (const int N[2::])
>
...it doesn't crash anymore for me when removing "const". And only
Artur
would put a const in front of an int ;-)
It also does not crash in case the lower bound is _not_ hit <function
void simple (const int N[1::])> ;-)
That is true. Writing const is such an automatism for me ;-) Even though
the pointer speed effect is negligible in this case, I still have the
"security effect" that the supposed to be constant parameter cannot be
overwritten ;-)
Actually, I believe it is not supported by hansl to do "const
int": The
guide says "the const modifier may be used... for all the types that
support the pointer apparatus". And if you try the following function:
<hansl>
function void simplestar ( int *N)
print "very simple"
end function
</hansl>
you get the error message "unknown data type 'int *'". You have to use
"scalar *N" instead. And indeed, the variant "const scalar N[2::])"
works and doesn't crash.
Yes, that sounds familiar to me.
But of course the above is a bad bug anyway, and "const
int" should be
intercepted by gretl in the first place.
Or may be not so given the other side effect I mentioned: the "security
effect" ;-)
Artur
2:38 p.m.
On Wed, 3 Mar 2021, Sven Schreiber wrote:
Am 03.03.2021 um 13:31 schrieb atecon:
>
> with latest git version under Ubuntu 18.04 I obtain a crash when
> running the following script:
Confirmed with a recent snapshot on Windows. That one looks pretty bad,
but...
>
> function void simple (const int N[2::])
>
...it doesn't crash anymore for me when removing "const". And only Artur
would put a const in front of an int ;-)
Actually, I believe it is not supported by hansl to do "const int": The
guide says "the const modifier may be used... for all the types that
support the pointer apparatus".
That's right. "const" doesn't have any effect when placed in front
of (non-pointerized) scalar arguments of any sort. Illustration:
<hansl>
function void simple (const int N[2::])
printf "very simple (%d)\n", N
# no error flagged here
N = 24
end function
function void dimple (const matrix m)
printf "very dimple\n"
# this does give an error
m = m + 5
end function
k = 7
simple(k)
print k # note: k is still 7
dimple(I(3))
</hansl>
I guess this is a buglet: either "const" should be disallowed for
plain scalar arguments, or else it should prevent changing the
argument inside the function (although the caller will not inherit a
change in any case).
Allin
3:16 p.m.
Am 03.03.2021 15:38 schrieb Allin Cottrell:
On Wed, 3 Mar 2021, Sven Schreiber wrote:
> Am 03.03.2021 um 13:31 schrieb atecon:
>>
>> with latest git version under Ubuntu 18.04 I obtain a crash when
>> running the following script:
> Confirmed with a recent snapshot on Windows. That one looks pretty
> bad,
> but...
>>
>> function void simple (const int N[2::])
>>
> ...it doesn't crash anymore for me when removing "const". And only
> Artur
> would put a const in front of an int ;-)
>
> Actually, I believe it is not supported by hansl to do "const int":
> The
> guide says "the const modifier may be used... for all the types that
> support the pointer apparatus".
That's right. "const" doesn't have any effect when placed in front of
(non-pointerized) scalar arguments of any sort. Illustration:
<hansl>
function void simple (const int N[2::])
printf "very simple (%d)\n", N
# no error flagged here
N = 24
end function
Ah, I never checked that but simply assumed that the const qualifier
would flag an error inside a function.
function void dimple (const matrix m)
printf "very dimple\n"
# this does give an error
m = m + 5
end function
k = 7
simple(k)
print k # note: k is still 7
dimple(I(3))
</hansl>
I guess this is a buglet: either "const" should be disallowed for
plain scalar arguments, or else it should prevent changing the
argument inside the function (although the caller will not inherit a
change in any case).
Yes, either case I guess. Personally I would favor that const is allowed
for all data types (but there may be good reason why not to do so).
Artur
3:32 p.m.
On Wed, 3 Mar 2021, atecon wrote:
Am 03.03.2021 15:38 schrieb Allin Cottrell:
>
> That's right. "const" doesn't have any effect when placed in front
of
> (non-pointerized) scalar arguments of any sort. Illustration:
>
> <hansl>
> function void simple (const int N[2::])
> printf "very simple (%d)\n", N
> # no error flagged here
> N = 24
> end function
Ah, I never checked that but simply assumed that the const qualifier would
flag an error inside a function.
> function void dimple (const matrix m)
> printf "very dimple\n"
> # this does give an error
> m = m + 5
> end function
>
> k = 7
> simple(k)
> print k # note: k is still 7
> dimple(I(3))
> </hansl>
>
> I guess this is a buglet: either "const" should be disallowed for
> plain scalar arguments, or else it should prevent changing the
> argument inside the function (although the caller will not inherit a
> change in any case).
Yes, either case I guess. Personally I would favor that const is allowed for
all data types (but there may be good reason why not to do so).
It's not so much that there's good reason NOT to do so -- rather
that there's little or no good reason to do so. Scalars are always
passed by value unless they're explicitly pointerized. So if you
mark a plain scalar argument as const, you're just tying your hands
as a function writer.
But... I guess in some contexts it could make sense as a guard
against forgetfulness: e.g. you get a scalar n as argument, then
forget that fact and assign a different value to n for some local
purpose, thereby losing track of the input value. (This should be
pretty much impossible in tightly modular code, but could be an
issue with a function of many lines.)
Allin
1:23 p.m.
On Wed, 3 Mar 2021, atecon wrote:
with latest git version under Ubuntu 18.04 I obtain a crash when
running the
following script:
<hansl>
clear
set verbose off
function void simple (const int N[2::])
print "very simple"
end function
simple(1)
</hansl>
Ah, I think this was a newly introduced bug, specific to tearing
down an invalid function call (in this case an out-of-bounds
argument). That's now fixed in git.
Allin
3:10 p.m.
Am 03.03.2021 14:23 schrieb Allin Cottrell:
On Wed, 3 Mar 2021, atecon wrote:
> with latest git version under Ubuntu 18.04 I obtain a crash when
> running the following script:
>
> <hansl>
> clear
> set verbose off
>
> function void simple (const int N[2::])
> print "very simple"
> end function
>
> simple(1)
> </hansl>
Ah, I think this was a newly introduced bug, specific to tearing down
an invalid function call (in this case an out-of-bounds argument).
That's now fixed in git.
Thank you, Allin. Works as intended now.
Artur
1774
days inactive
1774
days old
7 comments
3 participants
participants (3)
-
Allin Cottrell -
atecon -
Sven Schreiber