Aha — so it isn't really an issue with serialization at all. If I (now)
understand this correctly, when a function produces a contracted
higher-order result, it is the responsibility of the caller of the original
function to ensure that the result function is always applied to
appropriate arguments. That would explain why this version
blames intermediary:
#lang racket
(module server racket
(provide (contract-out
[adder (-> natural-number/c (-> natural-number/c
natural-number/c))]))
(struct adder (base)
#:property prop:procedure
(λ (this x)
(+ (adder-base this) x))))
(module intermediary racket
(require (submod ".." server))
(provide add5)
(define add5
(adder 5)))
(require 'intermediary)
(add5 'not-a-number)
I had previously intuited that the obligation would be on the caller of the
result function, whoever that might be.
When serialization is in the mix, is there a correct way for server to
protect itself from instances of adder being abused after they are
deserialized?
-Philip
On Sun, Jul 23, 2017 at 8:16 PM, Matthias Felleisen <matth...@ccs.neu.edu>
wrote:
>
> On Jul 23, 2017, at 8:54 PM, Philip McGrath <philip.mcgr...@gmail.com>
> wrote:
>
> I'm confused about why the following program is blaming the server for the
> client's misuse of an applicable struct instance. More generally, I've
> tried doing this in several different ways, and I can't figure out how to
> make applicable structs that are still protected by contracts after
> deserialization and blame the client module for misusing them.
>
> Thanks,
> Philip
>
> #lang racket
>
> (module server racket
> (require racket/serialize)
> (provide (contract-out
> [adder (-> natural-number/c (-> natural-number/c
> natural-number/c))]))
> (struct adder (base)
> #:property prop:procedure
> (λ (this x)
> (+ (adder-base this) x))
> #:property prop:serializable
> (make-serialize-info (λ (this) (vector (adder-base this)))
> #'deserialize-info:adder-v0
> #f
> (or (current-load-relative-directory)
> (current-directory))))
> (define/contract make-adder
> (-> natural-number/c (-> natural-number/c
> natural-number/c))
> adder)
>
>
>
>
> You defined make-adder with a contract. As far as it is concerned, its
> contract is with the surrounding module, which is server. Hence if it is
> misapplied, the server broke the contract of always protecting its entry
> channels (with a natural-number/c test).
>
>
>
>
>
> (define deserialize-info:adder-v0
> (make-deserialize-info make-adder
> (λ () (error 'adder
> "can't have cycles"))))
> (module+ deserialize-info
> (provide deserialize-info:adder-v0)))
>
>
> (require 'server racket/serialize)
>
> ((deserialize (serialize (adder 5))) 'not-a-number)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
