Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,248
    • Issues 4,248
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 391
    • Merge Requests 391
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #9236

Closed
Open
Opened Jun 24, 2014 by David Feuer@treeowlReporter

hGetContents leads to late/silent failures

A common newbie error:

withFile "file" ReadMode hGetContents >>= putStr

The problem, of course, is that the result of withFile "file" ReadMode hGetContents isn't forced until putStr is executed, at which point the file has already been closed. The Haskell report doesn't specify what it will find, and, at least in 7.6.3, it finds the string empty. The behavior that seems most correct to me would be to guarantee that if a file has not been completely read (or read up to an I/O error) when it is closed, then its contents should be reported as something like "Four score and seven years ag"++error "Forcing a suspended computation led to an attempted read from a handle that was already closed." My suggested fix is in a comment below.

Edited Mar 09, 2019 by David Feuer
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#9236