Re: compile-file apparently returning wrong value for error-p

[ delayed response... ]

Eric Blossom <eb <at> comsec.com> writes:

> It appears that compile-file is incorrectly returning a value of T for
> error-p even though the output diagnostics indicate that the
> compilation produced only a warning.  [I'd also like to know how to
> get rid of the warning...]

The correct value for errorp given a full warning /is/ T, I'm afraid.

> ; file: /home/eb/build/autod/load/test.lisp
> ; in: DEFUN FLATTEN-FORMAT
> ;     (CL-PPCRE:REGISTER-GROUPS-BIND (HEAD CH (#'PARSE-INTEGER REPEAT) TAIL)
> ;                                  ("(.*)(.)\\(([0-9]+)\\)(.*)" COBOL-FMT)
> ;                                  (CONCATENATE 'STRING
> ;                                               HEAD
> ;                                               (MAKE-STRING REPEAT
> ;                                                            :INITIAL-ELEMENT
> ;                                                            (CHAR CH 0))
> ;                                               TAIL))
> ; --> LET MULTIPLE-VALUE-BIND MULTIPLE-VALUE-CALL FUNCTION WHEN COND IF PROGN 
> ; --> LET* LET IF 
> ; ==>
> ;   NIL
> ; 
> ; caught WARNING:
> ;   The binding of ARRAY is not a STRING:
> ;     NIL
> ;   See also:
> ;     The SBCL Manual, Node "Handling of Types"
>
> ; compiling top level form: 
> ; compilation unit finished
> ;   caught 1 WARNING condition
>
> (defun flatten-format (cobol-fmt)
>   "convert strings with repeat counts to canonical format.
> E.g., S9(5)V99 --> S99999V99"
>   (let ((ff (cl-ppcre:register-groups-bind
> 		(head ch (#'parse-integer repeat) tail)
> 		("(.*)(.)\\(([0-9]+)\\)(.*)" cobol-fmt)
> 	      (concatenate 'string
> 			   head
> 			   (make-string repeat :initial-element (char ch 0))
> 			   tail))))
>     (if ff (flatten-format ff)
> 	cobol-fmt)))

I'm not intimately familiar with cl-ppcre, but what I think is
happening is that register-groups-bind is binding CH to something like
(if match (something with match) nil), and SBCL is warning you about
the failure branch, which will cause a type mismatch if it's ever
executed.  To quieten the system, probably a (check-type ch string) in
the body will work.

Cheers,

Christophe

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt