Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exploit: Injective type constructors and abstract prove false #2250

Closed
andreasabel opened this issue Oct 11, 2016 · 3 comments
Closed

Exploit: Injective type constructors and abstract prove false #2250

andreasabel opened this issue Oct 11, 2016 · 3 comments

Comments

@andreasabel
Copy link
Member

@andreasabel andreasabel commented Oct 11, 2016

{-# OPTIONS --injective-type-constructors #-}

open import Common.Prelude
open import Common.Equality

abstract
  f : Bool  Bool
  f x = true

  same : f true ≡ f false
  same = refl

not-same : f true ≡ f false  ⊥
not-same ()

absurd : ⊥
absurd = not-same same
@andreasabel andreasabel self-assigned this Oct 11, 2016
carlostome pushed a commit to carlostome/agda that referenced this issue Oct 13, 2016
… return

AbstractDefn instead of Axiom for abstract definitions
@asr asr added this to the 2.5.2 milestone Dec 12, 2016
@gallais
Copy link
Member

@gallais gallais commented Aug 13, 2019

While working on #3959, I have found a way to revive this proof of false
using the INJECTIVE pragma:

{-# OPTIONS --safe #-}

open import Agda.Builtin.Bool
open import Agda.Builtin.Equality

data  : Set where

abstract
  f : Bool  Bool
  f x = true
  {-# INJECTIVE f #-}

  same : f true ≡ f false
  same = refl

not-same : f true ≡ f false  ⊥
not-same ()

absurd : ⊥
absurd = not-same same

@gallais gallais reopened this Aug 13, 2019
@gallais gallais self-assigned this Aug 13, 2019
@JacquesCarette
Copy link
Contributor

@JacquesCarette JacquesCarette commented Aug 13, 2019

I don't get it -- you chose to lie to Agda, in ways that are outside the logic (with a pragma), and tried to hide your track (with abstract), and you're somehow surprised that this gets you into trouble? Is the point that this shouldn't have happened under --safe?

@gallais
Copy link
Member

@gallais gallais commented Aug 13, 2019

Yes. The point is that --safe should reject any use of INJECTIVE just like
it rejects uses of TERMINATING.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants