Is Rust Used Safely by Software Developers?

Rust, an emerging programming language with explosive growth, provides a robust type system that enables programmers to write memory-safe and data-race free code. To allow access to a machine's hardware and to support low-level performance optimizations, a second language, Unsafe Rust, is embedded in Rust. It contains support for operations that are difficult to statically check, such as C-style pointers for access to arbitrary memory locations and mutable global variables. When a program uses these features, the compiler is unable to statically guarantee the safety properties Rust promotes. In this work, we perform a large-scale empirical study to explore how software developers are using Unsafe Rust in real-world Rust libraries and applications. Our results indicate that software engineers use the keyword unsafe in less than 30% of Rust libraries, but more than half cannot be entirely statically checked by the Rust compiler because of Unsafe Rust hidden somewhere in a library's call chain. We conclude that although the use of the keyword unsafe is limited, the propagation of unsafeness offers a challenge to the claim of Rust as a memory-safe language. Furthermore, we recommend changes to the Rust compiler and to the central Rust repository's interface to help Rust software developers be aware of when their Rust code is unsafe

iPerfDetector: Characterizing and Detecting Performance Anti-patterns in iOS Applications

Performance issues in mobile applications (i.e., apps) often have a direct impact on the user experience. However, due to limited testing resources and fast-paced software development cycles, many performance issues remain undiscovered when the apps are released. As found by a prior study, these performance issues are one of the most common complaints that app users have. Unfortunately, there is a limited support to help developers avoid or detect performance issues in mobile apps. In this thesis, we conduct an empirical study on performance issues in iOS apps written in Swift language. To the best of our knowledge, this is the first study on performance issues of apps on the iOS platform. We manually studied 235 performance issues that are collected from four open source iOS apps. We found that most performance issues in iOS apps are related to inefficient UI design, memory issues, and inefficient thread handling. We also manually uncovered four performance anti-patterns that recurred in the studied issue reports. To help developers avoid these performance anti-patterns in the code, we implemented a static analysis tool called iPerfDetector. We evaluated iPerfDetector on eight open source and three commercial apps. iPerfDetector successfully detected 34 performance anti-pattern instances in the studied apps, where 31 of them are already confirmed and accepted by developers as potential performance issues. Our case study on the performance impact of the anti-patterns shows that fixing the anti-pattern may improve the performance (i.e., response time, GPU, or CPU) of the workload by up to 80%

Software Engineering in the IoT Context: Characteristics, Challenges, and Enabling Strategies

L'abstract è presente nell'allegato / the abstract is in the attachmen

How swift developers handle errors

\u3cp\u3eSwift is a new programming language developed by Apple as a replacement to Objective-C. It features a sophisticated error handling (EH) mechanism that provides the kind of separation of concerns afforded by exception handling mechanisms in other languages, while also including constructs to improve safety and maintainability. However, Swift also inherits a software development culture stemming from Objective-C being the de-facto standard programming language for Apple platforms for the last 15 years. It is, therefore, a priori unclear whether Swift developers embrace the novel EH mechanisms of the programming language or still rely on the old EH culture of Objective-C even working in Swift. In this paper, we study to what extent developers adhere to good practices exemplified by EH guidelines and tutorials, and what are the common bad EH practices particularly relevant to Swift code. Furthermore, we investigate whether perception of these practices differs between novices and experienced Swift developers. To answer these questions we employ a mixed-methods approach and combine 10 semi-structured interviews with Swift developers and quantitative analysis of 78,760 Swift 4 files extracted from 2,733 open-source GitHub repositories. Our findings indicate that there is ample opportunity to improve the way Swift developers use error handling mechanisms. For instance, some recommendations derived in this work are not well spread in the corpus of studied Swift projects. For example, generic catch handlers are common in Swift (even though it is not uncommon for them to share space with their counterparts: non empty catch handlers), custom, developerdefined error types are rare, and developers are mostly reactive when it comes to error handling, using Swift's constructs mostly to handle errors thrown by libraries, instead of throwing and handling application-specific errors.\u3c/p\u3