Custom Query (1630 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (31 - 33 of 1630)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Ticket Resolution Summary Owner Reporter
#847 fixed ##sys#foreign-pointer-argument is declared to accept a pointer only, but is possibly invoked with a boolean sjamaan
Description

When you use let-location or define-foreign-variable and declare a pointer type, you can set it to a NULL value by setting it to #f in Scheme and this works correctly. However, the scrutinizer thinks that's bad:

$ cat test.scm
(define-foreign-variable bar c-pointer)

(set! bar #f)

(let-location ((x c-pointer #f))
  ((foreign-lambda void "printf" c-string c-pointer) "%p\n" x))
$ csc -scrutinize test.scm
Warning: at toplevel:
  (test.scm:3) in procedure call to `##sys#foreign-pointer-argument', expected argument #1 of type `pointer', but was given an argument of type `boolean'

Warning: at toplevel:
  (test.scm:5) in procedure call to `##sys#foreign-pointer-argument', expected argument #1 of type `pointer', but was given an argument of type `boolean'

The underlying problem is that ##sys#foreign-pointer-argument is declared as accepting only pointer types (which is correct, it will barf otherwise), but the initializer/set value is #f, a boolean which is allowed as a value representing a NULL pointer. The if check in library.scm:1077 takes care of this situation, but the scrutinizer is unable to verify that the boolean isn't #t when it passes the if and takes the ##sys#foreign-pointer-argument branch (and it might be!). This output be seen more clearly when calling "csc -debug 2 test.scm".

We could do a few things here:

1) Add a ##core#the assertion that states the argument is definitely a pointer. That kind of kills the scrutinizer's effectiveness at warning, moving the error to runtime (it's also incorrect in case anything else is passed). 2) Map #t to #f (a NULL pointer eventually in the C translation). That's inconsistent with the rest of core. 3) Map #t to an error. This still moves the error to a runtime one but keeps the scrutinizer warnings for all non-boolean types. 4) Keep it the way it is. That will give bogus warnings on this kind of code. 5) Remove ##sys#foreign-pointer-argument from types.db or change it to accept a boolean. The former again gets rid of the advantage of having the scrutinizer and the latter is blatantly incorrect. 6) Change the ##sys#foreign-pointer-argument to accept booleans and only return C_SCHEME_FALSE and barf on C_SCHEME_TRUE. 7) Augment the type system with yet another special case for #f, adding a "false" type that is a subtype of "boolean".

I don't know which option I like most (or dislike least). 7 is definitely the most "thorough" option, similar to the special handling of null, pair and list(-of) types, but it raises the complexity of the scrutinizer another notch. Other acceptable solutions would probably either be 3 or 6, which both basically come down to the same thing. I think whatever we do, we should probably postpone it until after the next release unless someone comes up with a clever, noninvasive alternative of course :)

#1711 fixed ##sys#read with -keyword-style prefix transforms bare colon into empty symbol alicemaz
Description

##sys#read recognizes prefix keywords by ignoring the leading colon and suffix keywords by consuming the trailing colon and then dropping it upon confirming it's the last token in an identifier. I added another case that adds the colon back in the prefix case if no tokens follow

the main purpose of this is to allow : from chicken.type to be used in prefix mode. presently it is a syntax error

also I fix a silly case where multiple colons would be dropped for prefix keywords, matching the suffix behavior where one is semantically meaningful and the rest go on the identifier

tested on PLATFORM=linux. code block below shows 5.2.0 behavior with prefix, patched behavior with prefix, and suffix behavior for comparison (which is unchanged between versions)

alice@bellona:~/work/misc/typetest % cat src/typetest.scm
(define prefix :pre)
(define suffix suf:)
(define canonical #:can)
(define blank :)

(define qpre :|qpre|)
(define qsuf |qsuf|:)
(define qpreblank :||)
(define qsufblank ||:)

(define triplepre :::tp)
(define triplesuf ts:::)

(: typesig fixnum)
(define typesig 1)
alice@bellona:~/work/misc/typetest % ( chicken src/typetest.scm -keyword-style prefix -check-syntax -debug 1 | grep -v '^$' > /dev/tty ) > & /dev/null
[source]
(define prefix #:pre)
(define suffix |suf:|)
(define canonical #:can)
(define blank ||)
(define qpre #:qpre)
(define qsuf |qsuf:|)
(define qpreblank #:||)
(define qsufblank :)
(define triplepre #:tp)
(define triplesuf |ts:::|)
(|| typesig fixnum)
(define typesig 1)
alice@bellona:~/work/misc/typetest % ( dev-chicken src/typetest.scm -keyword-style prefix -check-syntax -debug 1 | grep -v '^$' > /dev/tty ) > & /dev/null
[source]
(define prefix #:pre)
(define suffix |suf:|)
(define canonical #:can)
(define blank :)
(define qpre #:qpre)
(define qsuf |qsuf:|)
(define qpreblank #:||)
(define qsufblank :)
(define triplepre #:|::tp|)
(define triplesuf |ts:::|)
(: typesig fixnum)
(define typesig 1)
alice@bellona:~/work/misc/typetest % ( dev-chicken src/typetest.scm -keyword-style suffix -check-syntax -debug 1 | grep -v '^$' > /dev/tty ) > & /dev/null
[source]
(define prefix |:pre|)
(define suffix #:suf)
(define canonical #:can)
(define blank :)
(define qpre |:qpre|)
(define qsuf #:qsuf)
(define qpreblank :)
(define qsufblank #:||)
(define triplepre |:::tp|)
(define triplesuf #:|ts::|)
(: typesig fixnum)
(define typesig 1)
#674 fixed ##sys#string->number gets called without prefixes in the reader felix winkelmann sjamaan
Description

Chicken core's reader calls ##sys#string->number on the number without the radix&exactness prefix.

This causes issues when for example you're reading something like the following: "#e1e500". The reader passes on "1.0e500" and then converts it to an exact number using inexact->exact, but that fails because flonums can't represent a number that large. I know it's probably a bit of an edge case, but this is more convenient input syntax than typing a 1 followed by 500 zeroes, which AFAIK is the only other way to enter an exact number like that.

Another approach would be to do like I now do in numbers trunk itself; string->number first analyses the prefix like Chicken core does, and then passes the radix *and* an extra argument indicating whether to force exactness (or inexactness?) to the procedure that handles the actual number parsing. This would be an easier fix, but I think this can't be done in a backwards-compatible way.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Note: See TracQuery for help on using queries.