text:
\subsection{Type safety in Go and the \code{unsafe}\xspace package}

Go is a statically typed language. That is, the type of variables in a Go program are known at compile time, enabling  the compiler to verify type inconsistencies and incompatible type conversions.
A compiled Go program is guaranteed to be type-safe which prevents a myriad of runtime issues, unless developers use the \code{unsafe}\xspace package.
As described in the official documentation shown in \Cref{fig:unsafe-background}, the \code{unsafe}\xspace package offers a step around the type safety of Go programs~\cite{Go:unsafe:online}.
The \code{unsafe}\xspace package is quite compact, containing only three functions and one Pointer type in its API, shown in the Index of \Cref{fig:unsafe-background}-A.
By using the \code{unsafe}\xspace package, developers have the flexibility needed to develop low-level code, such as full control over pointers (C-style), the ability to read and write arbitrary memory, access to object sizes, and the possibility to convert between any two types with compatible memory layouts (shown in \Cref{fig:unsafe-background}-B).
\rev{Compared to unsafe libraries from other programming languages like the \texttt{sun.misc.Unsafe} from Java and \texttt{unsafe Rust}, the Go \code{unsafe}\xspace package is still much more restricted. By using their respective unsafe APIs, in addition to breaking \revminor{type safety}, developers can violate method contracts in Java~\cite{Mastrangelo:2015:JavaUnsafe} or use inline assembly functions in Rust~\cite{Evans:2020:Rust}.}

\subsection{Risks of using the \code{unsafe}\xspace package}
\label{sub:backgrond-risk-unsafe}

In practical terms, breaking \revminor{type safety} means lifting the safety net that a compiler provides for developers in exchange for full-control of reading and writing memory.
This by itself, puts developers at a higher risk of making mistakes that will ripple through to the production environment.
\rev{For instance, converting between incompatible types may cause the program to eventually crash or misinterpret the memory layout of a variable causing unexpected program behavior.}
Aside from this, the \code{unsafe}\xspace package comes with a series of drawbacks described in its documentation~\cite{Go:unsafe:online}, that need to be taken into careful consideration by developers:

\noindent
\textbf{Non-Portability:}
A regular package in Go can be compiled to different CPU architectures and operating systems without any changes in the code.
Projects that use \code{unsafe}\xspace, however, may need to account for differences in the CPU architectures and it is up to developers to keep their packages portable.
For instance, by traversing an array of integers using \code{unsafe}\xspace, developers need to account for the integer size which differs in x86 and x64 architectures.
\rev{Another example is the reliance on system calls, which are accomplished by using both \texttt{syscall} with \code{unsafe}\xspace packages and are not often portable to different operating systems.}

\noindent
\textbf{Not Protected by the Compatibility Guideline:}
Programs that are written in Go have the guarantee to work in future versions of the programing language, as long as they follow the compatibility guideline established in Go 1~\cite{Go1andth70:online}.
However, using the \code{unsafe}\xspace package breaks this compatibility guarantee, as \code{unsafe}\xspace exposes the internal implementations of the language, which may change in future versions.
Hence, programs that rely on \code{unsafe}\xspace are not guaranteed to work in future implementations of Go.

\subsection{Invalid Pointer Conversion}
\label{sub:unsafe-misuse}

The \code{unsafe}\xspace package provides an extensive documentation on how to properly use the package and some of the pitfalls developers must avoid when breaking \revminor{type safety}~\cite{Go:unsafe:online}.
A pitfall that is well-described in the package documentation is the invalid pointer conversion.
As a rule of thumb, converting pointer addresses back to pointer variables is not valid in Go language.
Pointer memory addresses in Go are of the type \code{uintptr}\xspace (unsigned integer pointer), which is a simple integer type, holding no reference or pointer-semantics.
Since Go has a Garbage Collector that releases memory that is not referenced by any variable in the program, a variable \code{uintptr}\xspace holding the address of a pointer will not prevent the garbage collector \revminor{from releasing} the said pointer.
Consequently, there is no guarantee that a memory address (type \code{uintptr}\xspace) contains a valid Go pointer variable to be dereferenced~\cite{Go:unsafeptr:online}.

In some cases, however, there is a valid need to manipulate memory addresses and dereference them back to pointers.
For instance, to perform pointer arithmetic operations (C-style) to traverse an array as shown in \Cref{fig:unsafe-background}-C.
Developers need to be aware of the intricacies of manipulating low-level pointers in a language that contains a Garbage Collector, to prevent the Garbage Collector from releasing their variables in the middle of their operations.
We show in \Cref{fig:unsafe-background}-D an example on how to properly handle pointer arithmetics in Go.
In this case, developers should never store their \code{uintptr}\xspace into an intermediate variable (\code{u}), because at this point in the execution of a program the variable \code{p} can be released by the Garbage Collector.

This example shows that the pitfalls of handling \code{unsafe}\xspace are not always intuitive.  %
To make matters worse, the issues that arise from using the invalid pointer conversion are non-deterministic and are unlikely to be encountered during software testing when memory pressure tends to be small.

\subsection{Design decisions of APIs exposing \code{unsafe}\xspace}
\label{sub:design-decision}
\input{Discussion_officialAPIs}

\vspace{-0.1in}
\subsection{Performance benefits of \code{unsafe}\xspace casts}
\label{sub:performance-optimization}
\input{Discussion_optimization}

\vspace{-0.1in}
\subsection{Recommendations}
\label{sub:implications}
\input{Implications}

\vspace{-0.1in}
\subsection{Perspectives of the Go Team}
\label{sub:go-team}
\input{GoTeam_feedback}

\subsection{Study dataset}

To investigate the usage of \code{unsafe}\xspace on a large-set of popular Go projects,
we first started by querying the GitHub REST API\footnote{https://developer.github.com/v3/} to identify a representative set of open source Go project. To do so, we selected a set of the top 3,000 most starred Go repositories,
as the number of stars is an indicator of the project popularity within GitHub repositories~\cite{Borges:GitHubPopularity, Borges:GitHubPopularityFactors}.
Our dataset was collected on October 2nd, 2019.

Even within highly starred repositories, we may find inactive repositories or repositories not related to software development.
To get a representative set of high-quality and active Go software development projects, we follow the methodology recommended by  previous work~\cite{Kalliamvakou:2016:GitHubPerils} to further curate our dataset through the following criteria:
\begin{enumerate}
	\item We filter out 89 archived projects, as these projects are no longer maintained by their developers.
	Archived projects are identified via a flag in the project's metadata.
	 %
	\item We removed 371 inactive projects, by filtering out projects that have had no contribution 12 months prior to the data collection date (after October 2018).
	\item We removed 22 projects with less than 10 commits in total, as these projects tend to be too young and are not representative of the projects we aim to investigate.
	\item We also removed 56 educational repositories, which are fairly common on popular projects datasets. These projects are described as published books, programming courses or any learning material, which are invaluable to the community, but are not representative of typical Go software. We removed these by manually inspecting project descriptions of our entire dataset.
	\item Furthermore, 24 projects could not be cloned automatically by our scripts (e.g., invalid URL, project no longer available) and were removed from our study.
\end{enumerate}

This process yields a dataset composed of 2,438\xspace Go projects. \Cref{tab:stats-dataset} shows the summary statistic of the selected Go projects in our dataset.
As shown in \Cref{tab:stats-dataset}, our dataset contains very popular projects (median of 857 stars and 110 forks), with a relatively long development history (median of 3.5 years of development).
\rev{The dataset contains eight projects with less than 150 LOC (minimum of 77 LOC), but in its large majority are composed of medium to large software projects (median of 9,6 KLOC).
We do not focus on filtering projects based on their size, as we think the perils of breaking type safety affects projects of all sizes.}

\begin{table}[t]
	\centering
	\caption{Statistics of the projects in our dataset.}
	\vspace{-0.05in}
	\label{tab:stats-dataset}
	\input{tables/stats-dataset}
\end{table}

\vspace{-0.1in}
\subsection{Identifying \code{unsafe}\xspace usages}

To find whether projects make use of \code{unsafe}\xspace in their source-code, we build a parser for Go source code, using the support of Go's native \code{ast} package\footnote{https://golang.org/pkg/go/ast/}.
Our parser first analyzes the source code of each Go file (files with .go extension) in the selected projects and build an abstract syntax tree (AST) for each file.
Then, the parser inspects the AST of Go files and identifies the function calls and type references to \code{unsafe}\xspace.
First we run our parser at the latest snapshot of the projects obtained during our data collection.
In addition, we also want to understand how the usage of \code{unsafe}\xspace changes as the project evolves.
To that aim, we use our parser to analyze the snapshot of the first commit of each month in the projects' history, and
For this analysis, we only consider the default branch of each project, identified via the GitHub API.

\subsection{Classifying projects' domain}

To complement the analysis on the usage of \code{unsafe}\xspace, we investigate the domain of the projects that use the \code{unsafe}\xspace package, as the domain has a direct influence on the need for breaking \revminor{type safety}.
Intuitively, we expect projects that demand low-level implementation and optimizations, such as databases and file systems, to depend more on \code{unsafe}\xspace implementations than other type of projects such as data structure libraries and web applications.
To identify the projects' domain, we manually inspect the description and documentation in their GitHub page and classify each project into a dominant domain, e.g., database, compiler, web server, development tool.
The three-first authors classify the repositories using an open card-sort method~\cite{Fincher_2005OpenCardSort}, where labels are created during the labeling process and each new label is discussed among annotators and retroactively applied to previously classified projects.
When different labels were assigned to the same project we \revminor{discussed them} to reach a consensus.

\subsection{Classifying \code{unsafe}\xspace usage patterns}
\label{sub:classifying-patterns}

To investigate what developers aim to accomplish using \code{unsafe}\xspace in RQ2, we need to understand the most frequent usage patterns associated with the \code{unsafe}\xspace package.
Each usage pattern may offer a rationale that will help us understand the proximate reason as to why developers opted for breaking \revminor{type safety} in their projects.
To extract high-level usage patterns from the projects' source code, we resort to in-depth manual analysis of the code, documentation, and commit messages.
It is important to notice that this analysis is very time consuming, as annotators need to recognize the context in which \code{unsafe}\xspace is being used, search for clues that indicate the reason behind the \code{unsafe}\xspace in commit messages and code documentation.
Hence, we decide to perform such analysis on a statistically significant random sample of the projects that use \code{unsafe}\xspace.
This sample is drafted to provide us with a representative set of the projects that rely on unsafe with 5\% confidence interval at 95\% confidence level.

We expect some projects to contain hundreds of \code{unsafe}\xspace call-sites while most projects may use \code{unsafe}\xspace sporadically in their code, given the risks associated with the package.
We want to identify patterns across projects and avoid biasing our analysis towards projects that rely more extensively on \code{unsafe}\xspace in their implementation.
Hence, we perform a second sampling by randomly selecting a single file from each project to our analysis.

It is important to highlight that we opt to conduct this particular analysis at the file level as opposed to package-level for the following reasons:
1) Files are more fine-grained than packages and are expected to have a more cohesive structure where we could more easily derive the usage pattern;
2) We can analyze the context of usage of a single file, with support of \texttt{gitblame} to futher inspect commit messages, without the need \revminor{to inspect} method calls across different files, which would impose a prohibitive time cost to this analysis.

The first two authors independently labeled each file (one per project) using an open card-sort method~\cite{Fincher_2005OpenCardSort}.
Hence, similarly to the analysis of projects' domains, labels are created and assigned while inspecting the usage in source-code and git commits, and every new label is discussed among annotators and if necessary, retroactively applied to previously labelled usages.
We assess the agreement of both annotators using the Cohen-Kappa metric~\cite{Mary:2012:kappa} and both annotators discussed and merged the results.

\vspace{-0.1in}
\subsection{Identifying invalid pointer conversions}

\revminor{In RQ3, we investigate the risks to projects caused by using the \code{unsafe}\xspace package.}
As discussed in \Cref{sec:background}, a major pitfall of using unsafe pointers is being unaware of issues related to invalid pointer conversions.
This issue can lead to non-deterministic errors in programs, as the Garbage Collector may release unintended variables and causing the program to crash.
We want to investigate whether invalid pointer conversions do occur in the most popular Go projects.
To automatically identify suspicious cases of invalid pointer conversions, we resort to existing static analyzers, as this issue is well-documented and covered by a go code analyser: Vet~\cite{vetTheGo72:online}.
Go Vet was created by maintainers of the Go language and is shipped natively with Golang.
\rev{It identifies suspicious cases of invalid pointer conversion when run with the flag \texttt{unsafeptr}.
Go Vet parses the code and applies a set of heuristics based on known ill-formed expressions (such as the one in \Cref{fig:unsafe-background}), exporting every suspicious case as a json file.
As with any heuristic-based tool, Go Vet may miss cases that do not fall into the most known patterns of invalid pointer conversions.}

\vspace{-0.1in}
\subsection{Classifying \code{unsafe}\xspace related issues}

Another method for understanding the risks associated with \code{unsafe}\xspace usage is to investigate the issues open in Github related with the package use.
To analyze and classify the issues related to \code{unsafe}\xspace, we first mine all issues from the repository of all projects that use \code{unsafe}\xspace.
In GitHub, ``issue" is an umbrella term that encloses pull requests, bugs, questions to maintainers and requests for new features.
\rev{We find candidate issues for our analysis by applying a keyword search for ``unsafe" and two variations (``un-safe'' and ``not safe") in the issue title. }
The keyword approach is prone to false-positives, especially given that the key-words are used in several different contexts (e.g., multi-threading), hence, we need to filter out false-positives from this candidate set.
The first author manually inspected each issue and removed the false-positives.
Then the first two authors proceed to analyze the issue title, body and related commit code to group issues based on their similarities.
Similarly to the previously described methods, we resort to the open-card methodology~\cite{Fincher_2005OpenCardSort} and evaluate the interrated agreement using the Cohen-Kappa interrater method~\cite{Mary:2012:kappa}.
We discuss the disagreement in a second round to reach a consensus in the classification.
Note that the goal of this analysis is not to find all issues related to \code{unsafe}\xspace, but  rather to classify a sample of possible unsafe-related issues to provide qualitative insights about the problem related to use the \code{unsafe}\xspace package.

\vspace{-0.1in}
\subsection{Replication Package}

To facilitate verification and advancement of research in the field, we provide a replication package containing the list of projects analyzed, the data extracted from the projects, and the scripts used to process and analyze our RQs~\footnote{\url{https://zenodo.org/record/3871931}}.

\subsection{Data Selection}

To investigate the aforementioned research questions, we clone the most popular go projects from GitHub.
We first query the GitHub Request API to identify the top 3,060 most starred Go repositories, as the number of stars is a good indicator of the project popularity within GitHub repositories.

Even among the most popular projects we may find abandoned repositories.
As we want to evaluate the usage of \code{unsafe}\xspace on active projects, in particular when measuring the effects of compatibility breaks in future versions of Go, we further curate our dataset by removing projects that have not pushed any contribution for the last 12 months (September 2018).
This process yields a dataset composed of 2,590 go projects (see \Cref{tab:dataset}).

\begin{table}
	\caption{Composing the dataset for this investigation.
		We considered inactive projects, repositories that have not pushed any contribution in the last 12 months.}
	\label{tab:dataset}
	\input{tables/dataset}
\end{table}

\begin{figure}
	\includegraphics[width=\linewidth]{figures/dataset-stars}
	\caption{Distribution of projects' stars count of our dataset. Note the log scale on the x axis.}
	\label{fig:dataset-stars}
\end{figure}

\begin{figure}
	\includegraphics[width=\linewidth]{figures/dataset-age-months}
	\caption{Distribution of projects' age in months of our dataset.}
	\label{fig:dataset-age-months}
\end{figure}

\subsection{RQ1. Is \code{unsafe}\xspace used in open-source Go projects?}

\textbf{Motivation.}

\textbf{Approach.}
To find whether projects make use of \code{unsafe}\xspace in their source-code, we build a parser for Golang, using the support of Go's native \code{ast} package~\footnote{https://golang.org/pkg/go/ast/}.
Our parser inspects the AST of the parsed go file and identifies the function calls and type references to the \code{unsafe}\xspace package.
We run this parser in every go file present in our dataset of repositories, but filter out usages identified in the source-code of the project dependencies.
Until recently, a common practice in Go projects for managing dependencies was to include all dependencies in the projects structure, in a folder called "vendor".
Hence, we exclude all reports of \code{unsafe}\xspace usage originating from vendor folders.

\textbf{Results.}
In \Cref{tab:rq1:descriptive} we show that from the 2590 evaluated repositories, \textbf{618 (23.8\%) make use of \code{unsafe}\xspace directly in the project source-code}.
The extent in which projects use \code{unsafe}\xspace varies considerably, as shown in~\Cref{fig:rq1-distribution-projects}, the majority of projects (74\%) use \code{unsafe}\xspace sparsely in their code, with less than 100 calls to \code{unsafe}\xspace operations.
Yet, 77 projects in ou our dataset rely heavily at \code{unsafe}\xspace to program their routines, with more than 100 operations present in their source-code.

The \code{unsafe}\xspace API is very compact, composed of only one type definition (\code{Pointer}) and three exported functions (\code{SizeOf())}, \code{OffsetOf()}, \code{AlignOf()}).
The vast majority of \code{unsafe}\xspace operations used by open-source Go projects is concentrated in the \code{unsafe.Pointer} type (\Cref{tab:rq1-most-used-features}).
The functions are used less frequently and represent together just 2.23\% of used \code{unsafe}\xspace operations.

\diego{Update with the latest results}
We present the top-10 projects with the highest reliance on \code{unsafe}\xspace in \Cref{tab:rq1-top10-projects}.
Among the top-10, four projects are a framework for the cross-platform Qt\footnote{https://www.qt.io}, an open-source widget toolkit for creating graphical interfaces.
These projects provide bindings from Qt to a myriad of platforms, and need to work with low-level routines to accomplish such portability.
Overall, seven out of the top-10 projects deal with bindings to or from graphical interfaces: 4 from Qt, one binding to OpenGL, one widgets wrapper and a visual web-server.
\diego{Add here some more comments on why graphical interface application would need the flexibility of \code{unsafe}\xspace}

The Golang project itself makes an extensive use of \code{unsafe}\xspace for implementing low-level routines.
While discouraged by the official documentation and community, if used correctly \code{unsafe}\xspace can be properly applied to \diego{Add here where \code{unsafe}\xspace is mostly used in golang.}

\begin{table}
	\caption{Descriptive statistics on the projects that use \code{unsafe}\xspace. Our dataset is comprised by  }
	\label{tab:rq1:descriptive}
	\include{tables/rq1-descriptive}
\end{table}

\begin{figure}
	\includegraphics[width=\linewidth]{figures/rq1-projects-dist}
	\caption{Distribution of projects that make use of \code{unsafe}\xspace by the number of \code{unsafe}\xspace operation calls}
	\label{fig:rq1-distribution-projects}
\end{figure}

\begin{table}
	\caption{\code{unsafe}\xspace operations ranked by their usage.}
	\label{tab:rq1-most-used-features}
	\include{tables/rq1-most-used-features}
\end{table}

\begin{figure}
	\includegraphics[width=\linewidth]{figures/rq1-projects-dist-operation}
	\caption{Distribution of \code{unsafe}\xspace opertions in the 618 projects that use unsafe.}
	\label{fig:rq1-ditribution-projects-operations}
\end{figure}

\begin{table}
	\caption{Top 10 projects with highest number of \code{unsafe}\xspace method calls}
	\label{tab:rq1-top10-projects}
	\include{tables/rq1-projects}
\end{table}

\subsection{RQ2. How often does a project depend on packages that uses \code{unsafe}\xspace?}

\textbf{Motivation.} Packages that use \code{unsafe}\xspace are not guaranteed to be compatible with future versions of Go.
Golang maintainers reserve the right to update internal structures of the language that may impact how \code{unsafe}\xspace is implemented, hence, introducing breaking changes in future versions of the language.
In this question, we focus on investigating how many packages and projects would be affected if a breaking change is introduced in \code{unsafe}\xspace.
Answering this question may shed a light on the impact of future Go version in the ecosystem and inform language maintainers on how to better plan future changes to \code{unsafe}\xspace to mitigate the impact in Go projects.

\textbf{Approach.}
In Go, packages (libraries) are the reusable units among software projects.
Project dependencies are established by installing and importing third-party packages from the Go ecossystem.
One Go project may export dozens of reusable packages, and each package commonly reutilizes a handful of other packages from the same project (internal dependencies) and from external applications (external dependencies).
Hence, to understand the spread of \code{unsafe}\xspace usafe within Go application dependencies, we need to analyse this question at the package level.

In our dataset of 3k projects, we have a total of \todo{X} packages.
We list the dependencies of each package through the following native go command:

\code{go list -f "\{\{.ImportPath\}\}, \{\{.Imports\}\}" ./...}

This command exports all direct dependencies of all packages identified in all sub-directories in a project.
We use direct dependencies to build a package dependency graph, and analyze this graph to identify packages that depend on other packages that use \code{unsafe}\xspace.
We group this analysis per project, and consider a project \textit{dependent} of an \code{unsafe}\xspace package, if at least one of its own packages depend on a package that uses \code{unsafe}\xspace.
Furthermore, we also analyze the transitive dependencies of all packages in a project, that is, the dependencies of the dependencies of a project's packages (one level of indirection).
If a project has a transitive dependency that uses \code{unsafe}\xspace, we categorize the project as being \textit{transitively-dependent} of an \code{unsafe}\xspace package.

\diego{Add here a brief data analysis of the dependency graph: how many nodes, edges? Is the network highly connected? This could also go to the Discussion section.}

\textbf{Results.}
\todo{TBD}

\begin{figure}
	\includegraphics[trim={0 4cm 0 4cm}, clip, width=\linewidth]{figures/dependency-graph-affected-straight}
	\caption{Dependency graph showing only the dependencies to projects that use \code{unsafe}\xspace (24.5\% of the original graph edges).}
	\label{fig:dependency-graph-affected}
\end{figure}

\begin{table}
	\caption{Number of projects possibly affected by any breaking change in \code{unsafe}\xspace}
	\label{tab:rq2-affected-dependencies}
	\include{tables/rq2-affected-dependencies}
\end{table}

\subsection{RQ3. Do developers follow the good practices of \code{unsafe}\xspace documentation?}

\textbf{Motivation.}
Using \code{unsafe}\xspace operations is not necessarily a bad smell in the code.
The official documentation of \code{unsafe}\xspace describes at length how to safely use \code{unsafe}\xspace , by showing valid usage patterns and describing some of the pitfalls developers must avoid.
In this question, we explore if developers follow the recommendations of \code{unsafe}\xspace documentation and help identify scenarios in which the code is not guaranteed to behave as intended.
Answering this question will help us understand the typical mistakes developers make, and contribute to devise better tools to assist developers at using \code{unsafe}\xspace properly.

\textbf{Approach.}
Finding valid bad practices in the code is a difficult task.
Static analyzers are very useful to pinpoint bad practices and are used on a daily based by developers, but are prone to false reports and cannot guarantee recall (i.e., that the reports cover all issues in the code) in every scenario.
For this preliminary analysis, we focus on a particular pattern of misuse: \textbf{conversion of \code{uintptr} to \code{unsafe.Pointer}}, as this pattern is well-documented and covered by a native go code analyser: go vet~\cite{vetTheGo72:online}.
The command vet examines Go source-code to report suspicious statements under a variety of bad practices, and covers the aforementioned bad practice related to \code{unsafe}\xspace.

To analyse the projects that use \code{unsafe}\xspace with \code{go vet}, we use Go Report Card~\cite{schaaf-smith-goreportcard} web platform, which generates reports under a variety of code analysers.
To run this analyzer, we need to automatically compile the projects in our dataset.
As shown in previous studies~\todo{Add refs}, building hundreds of project is a challenging task as some projects require specific dependencies, environments or may not be suitable for independent automatically builts.
From the original set of 701 projects that use \code{unsafe}, we could automatically build and analyze 489 projects.

\textbf{Caveat/Threat to validity.}
The results presented in the preliminary analysis are based on reports generated from Go Report Card that are from 2 months to 1 year old.
Some of these reports may have been already fixed and some new cases may appear in the newest version of the projects' source-code.
This is far from ideal and should be addressed in the final version of this project.

I have tried to semi-manually update the reports, but I found a bug in the original code: the current version of \texttt{go vet}  is not working with the online version of Go Report Card.
I have issued a bug report~\footnote{https://github.com/gojp/goreportcard/issues/300} but could also later re-generate the reports locally, as my local version of Go Report Card seems to be working properly.

\textbf{Results.}
We present the overview of the results in~\Cref{tab:rq3-reports}.
From the set of 489 projects analyzed, \textbf{52 projects (10\%) were flagged with suspicious \code{unsafe.Pointer} usage.}
Most projects, however, have less than 20 cases of invalid conversions of \code{uintptr} to \code{unsafe.Pointer} (\Cref{fig:rq3-projects-dist}).

In~\Cref{tab:rq3-top10-unsafe-badpractices} we report the 10 projects with the highest number of reported  misues of \code{unsafe}\xspace.
We observe five projects with more than 100 cases of invalid conversion from \code{uintptr} to \code{unsafe.Pointer}, including sqlite with a surprising 6496 reports in their source-code.
\diego{We need to analyse this projects in details and explain here why such projects have such a high number of potential invalid conversions.}

\begin{table}
	\caption{Number of projects with at least one occurrence of suspicious \code{unsafe} usage}
	\label{tab:rq3-reports}
	\include{tables/rq3-reports}
\end{table}

\begin{figure}
	\includegraphics[width=\linewidth]{figures/rq3-projects-dist}
	\caption{Distribution of reported suspicious \code{unsafe.Pointer} }
	\label{fig:rq3-projects-dist}
\end{figure}

\begin{table}
	\caption{Top 10 projects with the highest number of reported suspicious \code{unsafe.Pointer} usage}
	\label{tab:rq3-top10-unsafe-badpractices}
	\include{tables/rq3-top10-unsafe-badpractices}
\end{table}

\subsection{RQ4. Does the use of \code{unsafe}\xspace change over time?}

\textbf{Motivation.}

\textbf{Approach.}

\textbf{Results.}

\subsection{How common is invalid pointer conversion in projects that use \code{unsafe}\xspace?}
\label{sub:rq3-invalid-pointer-conversion}

\noindent
\textbf{Approach:}
We run the tool Go Vet on all projects that use \code{unsafe}\xspace. We were able to automatically analyze 221 projects, due to problems during the project build.
Several projects use \code{unsafe}\xspace to integrate with external systems (C code and Operating Systems), hence, these projects in our dataset need external dependencies which cannot be automatically resolved with our building process. Once we run the tool Go Vet, we count the number of reported cases of invalid pointer.

\noindent
\textbf{Results:}
Regarding invalid usage of \code{unsafe}\xspace, initially the Go Vet tool reported invalid pointer conversions in 16 out of 221 analyzed projects (\Cref{tab:rq3-reports}).
\revminor{Upon close inspection, we found that cases found in two projects were false-positives, as the conversion to \code{uintptr}\xspace and back to pointer occurred in the same expression, as permitted by the official \code{unsafe}\xspace documentation~\cite{Go:unsafe:online}}.
Therefore, \textbf{14 out of 221 projects (6.6\%) had clear invalid pointer conversions}, with functions receiving a \code{uintptr}\xspace as parameter and converting it back to pointer inside the function or performing unsafe pointer arithmetics.
Albeit occurring in a minority of the investigated projects, this analysis shows that some popular projects still fall into the most well-documented pitfalls of using \code{unsafe}\xspace.
\revminor{We note that these results should be interpreted as a lower bound of invalid point conversions in these 211 projects.
That is, because Go Ver uses a set of patterns to identify invalid pointer conversion, the tool will likely miss cases that do not fall into the known patterns.
As a consequence, there could be more than 14 cases in the 221 analyzed projects, but there is no practical way to assess how many of such cases were not retrieved by the tool (false negatives).}

\begin{table}
	\centering
	\caption{Number of projects with invalid pointer conversions. We did not observe projects with a mix of false-positive and true-positive invalid pointer conversions.}
	\label{tab:rq3-reports}
	\include{tables/rq3-reports-local}
\end{table}

\subsection{What kind of unsafe-related issues projects that use \code{unsafe}\xspace have?}
\label{sub:rq3-issues}

\noindent
\textbf{Approach:}
After filtering issues through the keyword search in the title \revminor{("unsafe", "un-safe")}, we identify 286 issues from 119 projects.
Our manual inspection revealed that only 103 unsafe-related issues from 63 projects were in fact, related to the \code{unsafe}\xspace package.
We conduct our manual analysis on this set.
Again, we use Cohen-kappa inter-rater \cite{Mary:2012:kappa} to evaluate the labeling agreement between the two annotators. We found that both annotators had a moderate agreement (Cohen-kappa=0.55) after the first labelling round.
Later, both annotators discussed all divergences and reached a consensus in the classification.

\begin{table*}[tbh]
	\caption{Issues related to \code{unsafe}\xspace identified in 63 projects. We present both the number of issues (\#) and the number of projects in which they occur (\# proj.).}
	\label{tab:rq3-unsafe-related-issues}
	\include{tables/rq3-unsafe-related-issues}
\end{table*}

Our manual classification of the unsafe-related issues yields a scheme shown in \Cref{tab:rq3-unsafe-related-issues}.
We group the issues into 10 categories comprised of Bug Fixing and Project Maintenance issues.
We consider as Bug Fixing the issues that were open due to runtime errors or bugs found in the project code base.
Project maintenance, on the other hand, are issues created with the goal of improving the project, by adding new features or refactoring the code to improve the overall quality and reduce maintenance costs.
In the next paragraphs we discuss, with examples, each category of unsafe-related issues identified in our dataset of the 63 projects.
\\

\noindent
\textbf{Unsafe Restriction.}
The most common unsafe-related issue in our dataset, found in 20 projects, is related to external environmental restriction of the use of the \code{unsafe}\xspace package.
In most cases, this is related to the Google App Engine, a platform for cloud development that restricts the usage of \code{unsafe}\xspace for any Go code running in the platform~\cite{AppEngin9:online}, due to safety reasons.
For example, a developer in the project GJSON wrote: \snippet{I wanted to use this package within a Google App Engine project, and due to package "unsafe" being used, it is not compatible}~\cite{Removedu37:online}.
In many of these cases, the solution found for project maintainers was to provide a version of their package without \code{unsafe}\xspace dependency, or to remove the \code{unsafe}\xspace dependency in favor of a safer alternative.
\revminor{However, we also found cases where the usage of \code{unsafe}\xspace is so widespread in the project's code, the maintainers were not willing to remove it.}
In such cases, there is an encouragement that users fork the project repository to create a new safe-version of their packages, e.g., this developer wrote: \snippet{The atomic swap is used all over the place during transactions, so I don't think we'd want to take a change that removes it, but you could make a fork and replace unsafe with a mutex basically to make it less performant but safe}~\cite{googleap87:online}.

\noindent
\textbf{Runtime Errors.}
In 16 projects, we encounter issues that were created due to runtime errors caused by the misuse of \code{unsafe}\xspace package.
The most common type of runtime error, found in 6 projects, is related to crashing errors due to bad pointers, e.g. \snippet{Prometheus crashes and hangs on `fatal error: found bad pointer in Go heap}~\cite{Promethe40:online}.
Such errors can be caused by the Garbage Collector releasing unintended variables, mismanagement of operations that read and write memory and possibly other causes.
Another cause of crashing bugs in some projects were related to the conversion between different type layouts.
As a developer points out in an issue \snippet{I suspect the problem is that there is no guarantee that the alignment is correct after the pointer conversion}~\cite{Flakyuns29:online}.
The misuse of \code{unsafe}\xspace has also been reported to cause data corruption,  \snippet{Unsafe use of unsafe that leads to data corruption}~\cite{Usafeuse2:online} due to breaking string immutability in the string to bytes conversion.
Furthermore, we also found reports indicating that the program did not crash during execution but the wrong usage of \code{unsafe}\xspace has led the program to produce wrong results: \snippet{The combination of this version of siphash and use of unsafe.Pointer to obtain a byte slices caused back-to-back ast\#Term.Hash calls to return different values!}~\cite{Removeus35:online}.
These errors are difficult to diagnose and replicate: 5 of such issues mentioned problems to reproduce the runtime error due to the non-deterministic nature of the problem.
As a developer describes: \snippet{But someday, when using my JS package, I stumbled upon an unexpected behavior in one Lua function\footnotemark it is not even an error, just that the string.gsub function isn't behaving correctly}~\cite{strangee68:online}.
All such reports corroborate with the expected risks of breaking \revminor{type safety}, which may cause crashing errors, data corruption, wrong behavior and in many cases are difficult to diagnose and replicate.

\footnotetext{The Lua function was implemented in Go, through gopher-lua.}

\noindent
\textbf{Wrong Usage.}
We group in this category, 14 bugs found on 12 projects caught by maintainers or collaborators while inspecting the code, with no report of runtime issues.
The most common case, found in 5 projects, is related to slice conversion:
\snippet{While not likely to occur in the wild, changes to how GC inlines functions in 1.12 creates the possibility for data loss when serialization\_littleendian.go uses unsafe to change the type of slices}~\cite{Keephead73:online}.
Slice conversions also suffer from invalid pointer conversion issues, having the Garbage Collector release the slice in the midst of the conversion.
A commonly employed solution for this problem is to explicitly inform the runtime system to not release the slice header during the conversion, by calling the function \code{runtime.KeepAlive}.
However, \code{runtime.KeepAlive} is not always a valid solution~\cite{Go101:2020:KeepAlive} and can still yield memory corruption in some particular cases~\cite{GoPlay:online}. %
We also found issues related to traditional invalid pointer conversion, as described by a developer in an issue: \snippet{The following code is invalid because it puts a non-pointer value into a pointer-type, if the GC finds this non-pointer it will crash the program}~\cite{Invalidu72:online}.
Furthermore, a particular issue related to \code{unsafe}\xspace usage draws our attention.
The issue was reported as a security related in the project \code{nuclio}, where  convertion from string to bytes raised the possibility of exposing parameters from an internal library, as a developer reports: \snippet{Without going through their code this [issue] is likely due to buffer reuse, which is a race condition at the least and a security issue at the worst}~\cite{security31:online}.

\noindent
\textbf{Static/Dynamic Check Violation.}
In total, 7 issues from 6 projects were opened due to static and dynamic checks identifying suspicious usage of \code{unsafe}\xspace.
In 5 out of 7 cases, the issue was raised by the newest Go 1.14 version (released in February, 2020) which incorporated in the compiler a more robust invalid pointer conversion checker, which instruments the code to find violations to the \code{unsafe}\xspace rules dynamically.
For example, a developer reported:
\snippet{Go 1.14 introduces new runtime pointer checking, enabled by default in race mode which verify that the rules for using unsafe are followed}~\cite{runtimee32:online}.
This check is performed if the program is compiled with a race detector (flag \code{-race}) in Go 1.14 and emits a fatal error if a violation is found, forcing developers to fix the problem.
The other two cases were motivated by \code{go vet}, the static analyzer we used to identify invalid pointer conversions in our previous analysis.

\noindent
\textbf{Breaking Changes and Portability Issues.}
While less frequent, we also found issues related to breaking changes (3 projects), and related to portability issues (2 project).
\revminor{For instance, in 2011 a change in the function \code{sizeOf} of the package \code{unsafe}\xspace created several bugs in a project.}
As a developer describes \snippet{In tip, unsafe.Sizeof has been changed to return uintptr. This causes a variety of issues during the build of walk}~\cite{unsafeSi28:online}.
We also found portability issues related to projects that use \code{unsafe}\xspace when used in different Operating Systems.
For instance, in one issue a developer reported that \snippet{unsafe (marshaler and unmarshaler) test fails on big endian architectures}~\cite{KnownIss30:online}, indicating unsafe implementation worked on powerpc (32-bit) but did not work on s390x (64-bit) architectures.
These issues corroborate with the \code{unsafe}\xspace package documentation, which clearly states that portability and compatibility guarantees \revminor{do not hold} when using \code{unsafe}\xspace.

\noindent
\textbf{Project Maintenance.}
We report Project Maintenance issues related to \code{unsafe}\xspace grouped in four groups.
Such issues are not really bugs found in projects and do not represent a direct risk for the projects.
Instead, they represent tasks that are open by collaborators to improve project maintenabililty and are reported here in our study for completeness.
The most common issue, found in 12 projects, were created to suggest the removal of \code{unsafe}\xspace to mitigate the  risks of using \code{unsafe}\xspace, e.g., \snippet{Our benchmarks also show that there is no significant difference between safe and unsafe. This allows to remove optimizations with unsafe and simply rely on plain code generation}.~\cite{Nounsafe3:online}.
Moreover, we found 2 projects with issues related to isolating the \code{unsafe}\xspace dependency to a reduced number of packages in a project.
\rev{This indicates that some developers are keen to reduce the reliance on \code{unsafe}\xspace due to its inherent risks.}
\revminor{While there is an effort to keep \code{unsafe}\xspace usage at minimal levels in some projects, we also found that developers expand their API to support the \code{unsafe.Pointer} type ("Support for channels, maps and unsafe.Pointers"~\cite{Supportf3:online}).}
As shown in RQ2, developers frequently rely on \code{unsafe}\xspace for optimizations and we found issues open in 4 projects proposing a \revminor{refactoring} to more efficient code that uses \code{unsafe}\xspace.

\noindent
\textbf{Fix-patterns to unsafe related issues.} \revminor{We investigated the recurrence of fix-patterns that could be used to fix unsafe related issues automatically. We focused in identifying fix patterns related to issues of Wrong Usage and Runtime Errors, as these are closer to the traditional functional bugs. From the 32 issues, we found the majority of 24 issues to be entirely context-dependent. These fixes were related directly to the business logic of the program and are hard to generalize. The remaining 8 issues were fixed following fix-patterns related to unsafe type-casting, which we discussed in \Cref{sec:background}: developers should perform operations using a single expression to avoid having the GC release variables in use.  }

All the examined bug issues are exclusively caused by the use and misuse of \code{unsafe}\xspace.
The main takeaway from this analysis is that projects that do not break \revminor{type safety} and depend on type-safe third-party packages are free of encountering the issues we discussed in this analysis, such as crashing errors caused by bad pointers, have portability and compatibility issues or have their code restricted to deploy in different environments.

\conclusion{
	\textbf{Summary of RQ3:}
	We found suspicious cases of invalid pointer conversions in 14 out of 211 projects. More importantly, projects that use \code{unsafe}\xspace face several unsafe-related issues, from having their deployment restricted (20 projects), experiencing runtime errors that are hard to reproduce (16 projects), introducing bugs due to misuse of \code{unsafe}\xspace (12 projects).
}

\subsection{How often does a Go project use \code{unsafe}\xspace?}

\noindent\textbf{Approach:}
We run our parser to identify \code{unsafe}\xspace usages in every Go file present at the latest snapshot of projects in our dataset, but filter out usages identified in the source-code of the project dependencies.
\revminor{A commonly employed practice in Go projects for managing dependencies is to include all dependencies in the projects structure, in a folder called ``vendor''. }
Hence, we exclude all reports of \code{unsafe}\xspace usage originating from vendor folders.

\begin{table}
	\centering
	\caption{Statistics on the projects that use \code{unsafe}\xspace. }
	\vspace{-0.1in}
	\label{tab:rq1:descriptive}
	\include{tables/rq1-descriptive}
	\vspace{-0.1in}
\end{table}

\begin{figure*}
	\begin{subfigure}{.33\linewidth}
		\centering
		\includegraphics[trim=0 0 1.4cm  0, clip,width=\linewidth]{figures/rq1-projects-dist}
		\caption{\# of \code{unsafe}\xspace call-sites.}
		\label{fig:rq1-distribution-callsites}
	\end{subfigure}
	\begin{subfigure}{.33\linewidth}
		\centering
		\includegraphics[trim=0 0 1.4cm  0, clip,width=\linewidth]{figures/rq1-files-dist}
		\caption{\# of files with \code{unsafe}\xspace call-sites.}
		\label{fig:rq1-distribution-files}
	\end{subfigure}
	\begin{subfigure}{.33\linewidth}
		\centering
		\includegraphics[trim=0 0 1.4cm  0, clip,width=\linewidth]{figures/rq1-pkgs-dist}
		\caption{\# of packages that depend on \code{unsafe}\xspace.}
		\label{fig:rq1-distribution-packages}
	\end{subfigure}

	\caption{Distribution of \code{unsafe}\xspace usage in three granularity levels (call-site, files and packages) per project as a KDE density estimation plot. Note that the x-axis is logarithmic.}
	\label{fig:rq1-distribution-projects}
	\vspace{-0.1in}
\end{figure*}

\noindent\textbf{Results:}
\Cref{tab:rq1:descriptive} shows that from the 2,438\xspace evaluated Go projects, \textbf{592 (24\%) make use of \code{unsafe}\xspace directly in the project source-code}.
The extent in which projects use \code{unsafe}\xspace varies considerably.
In \Cref{fig:rq1-distribution-projects} we show the distribution of the \code{unsafe}\xspace usage in our dataset as a Kernel-density estimation plot, under three granularities: call-sites, files, and packages.
The call-sites plot accounts for every \code{unsafe}\xspace operation called in a project, the files indicate how many files depend on \code{unsafe}\xspace and the package plot shows how many modules in Go depend on \code{unsafe}\xspace.
As evidenced by the \Cref{fig:rq1-distribution-callsites} peak, the majority of projects (57\%) contains \revminor{fewer than 10 calls} to \code{unsafe}\xspace operations in their source-code.
Consequently, most projects concentrate their \code{unsafe}\xspace calls in at most 2 files and a single package, keeping the \code{unsafe}\xspace usage well-localized in the code (see the distribution shown in Figures \ref{fig:rq1-distribution-files} and \ref{fig:rq1-distribution-packages}).
Yet, we found that 69 projects (2.8\%) in our dataset rely heavily on \code{unsafe}\xspace in their project, with more than 100 call-sites present in their source-code.

\vspace{-0.1in}
\subsection{Does the usage of \code{unsafe}\xspace change as projects evolve?}

\noindent
\textbf{Approach:}
Since we want to analyze whether and how the usage of \code{unsafe}\xspace changed over the course of the project development, we examine the use of \code{unsafe}\xspace package at different snapshot of the projects history.
As our dataset contains in median projects with almost 4 years of development (see \Cref{tab:stats-dataset}), we focus on analyzing the trend of \code{unsafe}\xspace usage on the period between January 2015 to September 2019 (a month before our data collection time).
In addition, to perform a sound analysis of the usage of \code{unsafe}\xspace over the years, we only conduct this analysis on projects that fulfill the following criteria: 1) projects that have at least 10 \code{unsafe}\xspace operation calls at \revminor{the latest snapshot of their source code}, as these will show a more meaningful evolution of \code{unsafe}\xspace usage; and \rev{2) projects that were being actively developed during this entire period, i.e., projects with at least one commit pushed in each year. It is important to notice that we applied these criteria to avoid skewing our results towards a particular time frame.}
For instance, younger projects could skew our analysis as a higher number of projects would be accounted for in the most recent years.

\noindent
\textbf{Results:}
\rev{Figure~\ref{fig:rq1-trend-all} shows the evolution of the 270 projects in terms of number of packages and packages using \code{unsafe}\xspace (\Cref{fig:growth-packages}) together with the percentage of packages that rely on \code{unsafe}\xspace (\Cref{fig:growth-unsafe}).
In both plots, the thick line represents the mean value and the colored area shows the 95\% confidence interval of the data at each month.}

\rev{As shown in \Cref{fig:growth-packages}, the number of packages using \code{unsafe}\xspace grows similarly to the growth of total number of packages in a project.
As the number of packages increased by 3.5 times in our studied projects, the number of packages using unsafe also increased at a similar rate (3.7 times).
This indicates that the usage of \code{unsafe}\xspace evolves linearly as the project size increases, in the evaluated projects.
In addition, \Cref{fig:growth-unsafe} shows the proportion of packages using \code{unsafe}\xspace, which remains steadily around 17\% as projects evolve.
Our results paint a \revminor{mixed} picture; while the dependency of \code{unsafe}\xspace does not spread out to a larger proportion of packages, it has also not decreased as projects grow in average 3.5 times, since January 2015.}

\begin{figure}

	\begin{subfigure}{\linewidth}
		\centering
		\includegraphics[width=.75\linewidth]{figures/rq1-trend-npackages}
		\vspace{-0.1in}
		\caption{Evolution of 270 projects compared to their state in January 2015 (baseline) in terms of the number of packages and number of packages using \code{unsafe}\xspace.}
		\label{fig:growth-packages}
	\end{subfigure}

	\begin{subfigure}{\linewidth}
		\centering
		\includegraphics[width=.75\linewidth]{figures/rq1-trend-share}
		\vspace{-0.1in}
		\caption{Evolution of the percentage of packages that use \code{unsafe}\xspace in 270 projects.}
		\label{fig:growth-unsafe}
	\end{subfigure}
	\caption{Analysis of projects' evolution in terms of number of packages and the share of packages that rely on \code{unsafe}\xspace. }
	\label{fig:rq1-trend-all}
\end{figure}

\subsection{What domain of projects rely the most on \code{unsafe}\xspace?}

\noindent
\textbf{Approach:}
We want to understand whether there is a difference in the domain of projects that use \code{unsafe}\xspace sporadically, against projects that rely more heavily on breaking type-safety.
Hence, after categorizing the projects' domain, we group the projects that use \code{unsafe}\xspace into two groups:
in the first group we include all projects that use \code{unsafe}\xspace, and in the second group we focus on projects that rely heavily on \code{unsafe}\xspace, i.e., the 69 projects containing more than 100 \code{unsafe}\xspace call-sites.

\noindent
\textbf{Results:}
\rev{\Cref{fig:rq1-project-categories} shows the distribution of project domains of all projects in our dataset (left), percentage of projects per domain that use \code{unsafe}\xspace (middle) and the percentage of projects that contain more than 100 \code{unsafe}\xspace call-sites (right).
First, we observe that our dataset contains a predominance of Networking/Messaging projects in our dataset (440 projects), followed by Development Tools (227 projects) and Container/Virtual Machines (220 projects).
As our results show, \textbf{projects from 20 different domains make use of \code{unsafe}\xspace}.
The domains with the highest percentage of projects using \code{unsafe}\xspace are Bindings (89\%) and Blockchain (57\%) projects, followed by ML/Scientific Library (41\%).
Several other domains that are more directly related to providing tools for software development, such as Development Tools (33\%), Monitoring (31\%), Database/Storage (29\%), and Data Structures (29\%), have more than a quarter of their projects relying on \code{unsafe}\xspace to some extent. }

\rev{Most notably, \textbf{projects that rely heavily on \code{unsafe}\xspace (more than 100 call-sites) represent 35\% of all Binding projects in our dataset, the highest share in any category.}
Binding projects are projects that aim at bridging the Go language to libraries and platforms written in different programming languages.
These projects, such as Gotk3~\cite{gotk3:online} a bindings for the Graphical Interface framework GTK~\cite{gtk:online}, integrate with platforms not written in Go and use \code{unsafe}\xspace to implement functions that communicate with operating systems and C code.
Aside from Bindings projects, other domains have a handful of projects with more than 100 \code{unsafe}\xspace call-sites, such as Networking (7 projects) and Database (6 projects) domains.
Example of Networking and Database projects that rely heavily on \code{unsafe}\xspace are the Networking and Security service Cilium~\cite{Cilium:online} and the cloud-native SQL database CockroachDB~\cite{cockroachdb:online}.
Interestingly, only two domains do not have projects with more than 100 \code{unsafe}\xspace call-sites, which are Data structures and Blockchain.}

\begin{figure}
	\includegraphics[width=\linewidth]{figures/rq1-project-categories-perc}
	\caption{Distribution of the number of projects per domain (left), accounting for projects that depend on \code{unsafe}\xspace (middle), and projects that rely heavily on \code{unsafe}\xspace. \revminor{We highlight the averages across all project domains as dashed lines}.
	}
	\label{fig:rq1-project-categories}

\end{figure}

\conclusion{
\textbf{Summary of RQ1.}
Almost a quarter (24.28\%) of most popular Go projects in our dataset use \code{unsafe}\xspace directly.
The number of packages using \code{unsafe}\xspace accompanies the projects growth, with an average of 17.5\% of packages using \code{unsafe}\xspace.
In addition, project from several domains use \code{unsafe}\xspace to some extent, but Binding projects tend to rely heavily on \code{unsafe}\xspace. %
}

\subsection{What are the most used \code{unsafe}\xspace features?}

\noindent\textbf{Approach.}
The \code{unsafe}\xspace package is very compact, composed of one type definition (\code{Pointer}) and three exported functions (\code{SizeOf())}, \code{OffsetOf()}, \code{AlignOf()}).
To analyse the features used by developers, we group the analysis of \code{unsafe}\xspace usage conducted in the previous question by the four API components.

\begin{table}
	\centering
	\caption{The \code{unsafe}\xspace operations ranked by their usage in 592 Go projects.}
	\label{tab:rq2-most-used-features}
	\include{tables/rq2-most-used-features}
\end{table}

\noindent\textbf{Results.}
As shown in~\Cref{tab:rq2-most-used-features}, the \textbf{\code{unsafe.Pointer} is the most used feature from the \code{unsafe}\xspace API}, used by 96\% of projects that rely on \code{unsafe}\xspace and making the bulk of 97\% of all \code{unsafe}\xspace operation call-sites in our dataset.
The unsafe functions are used less frequently, representing together just 2.24\% of all \code{unsafe}\xspace operations call-sites, but are still used by a considerable number of projects.
The function \code{Sizeof}, used to retrieve the size of a variable type, is used by 36\% of all projects that rely on \code{unsafe}\xspace.

\begin{table*}[tbh]
	\caption{Usage patterns of \code{unsafe}\xspace, manually identified in 270 project files.}
	\label{tab:rq2-usage-patterns}
	\include{tables/rq2-usage-patterns}
\end{table*}

\subsection{What are the most common \code{unsafe}\xspace usages?}
\label{sub:rq2-unsage-usages}

\noindent
\textbf{Approach:}
Now, we proceed to understand the usage patterns of \code{unsafe}\xspace employed by Go projects.
From the 598 projects that use \code{unsafe}\xspace, we randomly select 270 to perform the manual analysis (see \Cref{sub:classifying-patterns}).
This number of projects provides us with a representative sample of the 598 projects that rely on unsafe with 5\% confidence interval at 95\% confidence level.
The first two authors labeled one file per project with its dominant use-case.

Our manual analysis yielded the hierarchical label structure shown in \Cref{tab:rq2-usage-patterns}, with six major groups of usage patterns.
We aimed to be as specific as possible in our labeling, so if a \textit{Communication} use-case can be attributed to a more specific category, say \textit{System Calls}, we label the file usage as dominated by \textit{System Calls}.
In the cases where the specific category could not be identified, we label them as their respective super category.
If neither examining the code or the commit messages we encountered sufficient information on the reason of the \code{unsafe}\xspace usage, we labeled the file as Unclear. %
We evaluate the labeling agreement with the Cohen-kappa interrater reliability~\cite{Mary:2012:kappa}. Cohen-kappa inter-rater reliability is a well-known statistical method that evaluates the inter-rater reliability agreement level for categorical scales. The result is a scale that ranges between -1.0 and 1.0, where a negative value means poorer than chance agreement, zero indicates exactly chance agreement, and a positive value indicates better than chance agreement.
\rev{It is also important to notice that to calculate the inter-rater reliability level, we only consider the exact matches of the most specific labeling (leaf nodes in the hierarchy), but grouped the project-specific cases into a single "Other" category before the agreement calculation.}
 \rev{In our analysis, we found that both authors have substantial agreement (kappa=0.65).} Finally, the two annotators discussed the divergencies to reach a consensus.

\noindent
\textbf{Results:}
Our findings, depicted in \Cref{tab:rq2-usage-patterns}, show that \textbf{developers mostly use \code{unsafe}\xspace for Communication to routines not written in Go (45.70\%) and to perform more efficient type casting in their programs (23.60\%)}.
Other patterns appear less common, such as inspecting the size of objects in memory (6.74\%), using \code{unsafe}\xspace to inspect object's metadata through reflection (3.75\%), to perform atomic operations (3.37\%) and general memory manipulation (3.37\%).
Also, in 3\% of the cases, we could not pinpoint a usage pattern based on the analysis of a single file, and in 8.24\% of the cases we deemed the usage pattern too project specific to be discussed here. %
In the next paragraphs, we dive in details on each group of \code{unsafe}\xspace pattern and explain, with examples, the likely rationale behind the breaking type-safety decisions.

\noindent
\textbf{Communication (System Call and CGO.)}
\rev{The most common usage pattern in our sample of 270 projects' files is the usage of \code{unsafe}\xspace as a mean to communicate to routines outside of Go language, which cannot be achieved in a type-safe manner.}
The communication to systems and programs outside of Go language requires developers to specify the memory address in which such programs can read and write, to specify parameters and receive their returned objects.
For system calls, the \code{syscall} package~\cite{Go:syscall:online} offers an API to different operating systems and often requires a \code{uintptr}\xspace with the address of a Go variable as parameters, as illustrated in Listing~\ref{lst:pattern-syscall}.

In turn, the package \code{cgo}\xspace offers a similar set of API for developers that need to integrate with C code~\cite{Go:cgo:online}.
Similarly to the system call use-case, programs that call C code need \code{unsafe}\xspace to write and read arbitrary memory and communicate with C code, as illustrated in Listing~\ref{lst:pattern-cgo}.
Furthermore, developers also cannot rely on the Garbage Collector from Go to release their C variables, and need to explicitly call the \code{C.free()} function to release the memory back to the system.

\rev{A possible explanation for the high frequency of patterns related to communication could be attributed to projects implementing Bindings.
To investigate this, we computed the frequency of patterns with and without the Binding projects and noted that our results still hold: the share of communication related patterns in non-binding projects changed slightly from 57.70\% to 45.02\%.
This shows that the use of \code{unsafe}\xspace as a method for interacting with other systems is prevalent also in non-Binding projects.
}

\begin{lstlisting}[caption=Example of using \code{unsafe} to set the name of a process, label=lst:pattern-syscall, float, belowskip=-7pt, aboveskip=-3pt]
// Unsafe pointer as a reference to a target name
ptr := unsafe.Pointer(&name_in_bytes[0])

// Setting a process name with the pointer ptr
_, _, errno := syscall.RawSyscall6(syscall.SYS_PRCTL,
    syscall.PR_SET_NAME, uintptr(ptr), 0, 0, 0, 0)
\end{lstlisting}

\begin{lstlisting}[caption=Example of using \code{unsafe} to call a function in C., label=lst:pattern-cgo, float, belowskip=-7pt]
func SetIcon(iconBytes []byte) {
    // Convert to a C char type
    cstr := (*C.char)(unsafe.Pointer(&iconBytes[0]))
    // Call the function from systray.h
    C.setIcon(cstr, (C.int)(len(iconBytes)))
}
\end{lstlisting}

\noindent
\textbf{Efficient Casting.}
In 23.60\% of the cases, developers use \code{unsafe}\xspace as a method of bypassing compiler checks and memory copy when casting a variable to a different type.
Naturally, while there are type-safe ways of converting between valid types, developers only opt for using \code{unsafe}\xspace to optimize runtime and memory allocation of certain functions.
The most common case of performance optimization is related to converting string to bytes and vice-versa.
Strings are immutable in Go, hence a regular type casting from a string variable requires copying the variable before the cast.
To bypass this variable copy, developers use \code{unsafe}\xspace to change the representation of a string into a slice of bytes as illustrated in Listing~\ref{lst:pattern-optimization}.
Since a slice of bytes can be mutated, this operation breaks the immutability of Strings as specified by the Go language, which can have far reaching consequences.

Another particular use-case for \code{unsafe}\xspace under this category  is the more efficient marshaling functions, which accounts for 4.12\% of the use-cases.
The standard marshaling functions are general-purpose and use reflection to identify the object to be marshalled, an operation that can be considered slow in performance critical applications.
By using \code{unsafe}\xspace, developers are able to implement their own customized and more efficient marshaling functions.

\begin{lstlisting}[caption=Example of unsafe conversion of bytes to string., label=lst:pattern-optimization, float, belowskip=-7pt, aboveskip=-3pt]
func String2Bytes(s string) []byte {
    sh := (*reflect.StringHeader)(unsafe.Pointer(&s))
    bh := reflect.SliceHeader{
        Data: sh.Data,
        Len:  sh.Len,
        Cap:  sh.Len,
    }
    return *(*[]byte)(unsafe.Pointer(&bh))
}
\end{lstlisting}

\noindent
\textbf{Reflection.}
Reflection allows developers to inspect and modify the metadata of types at runtime, simulating some of the dynamism of dynamic typed languages.
The \code{reflect} package~\cite{Go:reflect:online} requires developers to import \code{unsafe}\xspace to derreference an object accessed through reflection to a pointer.
This is done by design, to enforce developers to import \code{unsafe}\xspace when performing such unsafe operations and to prevent \code{reflect} from replicating some of the functionality of the \code{unsafe}\xspace package.

\noindent
\textbf{Atomic Operations}
\rev{Another use-case that occurred in 3.37\% of the cases is related to the package \code{sync/atomic}~\cite{Go:atomic:online}}.
The package provides low-level atomic functions for synchronization algorithms.
As the documentation of the package poses, using \code{sync/atomic} properly requires great care from developers to be used correctly.
This package offers a way to perform atomic operations with high-performance and without any memory allocation.
Currently, there is no safe alternative to perform compare and swap operations on Go objects without memory allocation~\cite{syncatomic:proposal:online}, which explains why the package gives support to \code{unsafe.Pointer} as opposed to a type-safe alternative (e.g., \code{interface}).

\noindent
\textbf{Address Manipulation.}
In 3.37\% of the use-cases, developers use \code{unsafe}\xspace to get the memory addresses and perform some arithmetic function.
Most of the cases we identified are related to using the memory address as a component of a hash function, similarly to the way Java implements the object \code{hashCode()} mechanism.

\begin{lstlisting}[caption={Code snippet of using \code{unsafe}\xspace as a method to generate hash key, taken from the project Olric.}, label=lst:pattern-architecture-info, float, belowskip=-7pt, aboveskip=-3pt]
func (db *Olric) getHKey(name, key string) uint64 {
    tmp := name + key
    return db.hasher.Sum64(*(*[]byte)(unsafe.Pointer(&tmp)))
}
\end{lstlisting}

\begin{lstlisting}[caption={Code snippet of using \code{unsafe}\xspace to infer the system architecture, taken from the project Telegraf.}, label=lst:pattern-architecture-info, float, belowskip=-7pt]
// Verifying the size of an integer i
if unsafe.Sizeof(i) == 4 {
    is32Bit = true
} else {
    is32Bit = false
}
\end{lstlisting}

\noindent
\textbf{Size of Object.}
In 6.74\% of the cases, the \code{unsafe}\xspace package is used to retrieve information about the object size, a use case that is often performed to get the architecture of the underlying system, such as CPU architecture and the system endianness.
For instance, in Listing~\ref{lst:pattern-architecture-info} we present a snippet where developers verify the size of an integer \code{i} to infer whether the operating system is 32-bits or not.
\\

\conclusion{
	\textbf{Summary of RQ2:}
	The bulk of \code{unsafe}\xspace usages are related to low-level routines that communicate to operating systems and C code (45.70\%), and to improve the performance of type casting (23.60\%).
	Less frequently, developers use \code{unsafe}\xspace to inspect the CPU architecture (4.49\%), inspect object's metadata at runtime (3.75\%), perform atomic operations (3.37\%) and to manipulate memory addresses (3.37\%).
}

\subsection{Unsafe Language Features}

\revminor{Some prior studies investigates how developers use low-level code features in different programming languages.}
Nagappan~et al.\xspace~\cite{Nagappan:2015:GoTo} investigate how developers use the \code{goto} statements in a representative sample of C programming files.
Motivated by the harmful stigma of \code{goto} statements, the authors qualitatively investigate how such command is used in modern C code. The investigation showed that developers nowadays limit themselves to use \code{goto} only in very specific circumstances, such as error handling and cleaning up resources, and that it does not appear to be harmful in practice.

Some other studies focus on investigating the usage of dynamic features on programming languages.
Mastrangelo~et al.\xspace~\cite{Mastrangelo:2019:Casting} investigated how and when developers use casting on thousands of Java projects.
The results show that casting is widely-used by Java developers and that half the casts are not guarded locally to ensure against runtime errors.
Similarly to our study, this investigation also cataloged a common set of use-case patterns that can help language maintainers and tool developers to better accommodate the most common usages of dynamic casting.
Callau~et al.\xspace~\cite{Callau_DynamicTypingSmallTalk} investigated how dynamic and reflective features are employed in SmallTalk, by surveying a thousand SmallTalk projects.
While SmallTalk is a dynamically-typed language, the authors reported that dynamic features are not widely used by SmallTalk developers.
\rev{In fact, the two most pervasively used features are the ones other static languages implement, indicating a more conservative approach with seemingly unsafe features than the ones we observed in popular Go projects.}

\rev{One of the works most closely related to ours is the investigation of unsafe APIs in Java by Mastrangelo~et al.\xspace~\cite{Mastrangelo:2015:JavaUnsafe}.
In their work, the authors investigated how developers use the \code{sun.misc.Unsafe}, a class that exposes low-level and unsafe features, violating Java safety guarantees.
Differently from the \code{unsafe}\xspace package in Go, the \code{sun.misc.Unsafe} API gives access to more than type safety violations, for instance, developers can violate method contracts by throwing a checked exception undeclared by a method.
Their investigation found that only a small share (1\%) of software artifacts use the unsafe API in their code directly.
In contrast, we found that 24\% of the most popular Go projects rely on unsafe to some extent, showing that using unsafe APIs seems to be more common in Go than in Java.}

\rev{Another closely related work investigated the use of Unsafe Rust~\cite{Evans:Rust:2020} in a large set of Rust libraries.
Unsafe Rust is in fact a language embedded in Rust, but it gives access to similar functionalities as the \code{unsafe}\xspace package, such as C-style pointer operations and access to arbitrary memory locations, which are not guaranteed by the compiler to be safe.
The authors have identified that 30\% of the Rust libraries use the keyword unsafe and more than half of them depend on another library that is unsafe.
This results are in line with the findings we observed in our study.
Our study contributes to this body of work, that investigate the practices of breaking \revminor{type safety}~\cite{Mastrangelo:2015:JavaUnsafe, Evans:2020:Rust} in programming languages and provides insights and recommendations to make programming languages more safe.}

\vspace{-0.1in}

\subsection{Mining Repositories of Usage of Language Features}

Several studies empirically investigate how developers use different language features through mining software repositories.
Mazinanian~et al.\xspace~\cite{Mazinanian:17:Lambdas} mined software repositories to investigate how Java developers use Lambda in their programs.
Similarly, Costa~et al.\xspace~\cite{Costa:17:Collections} profiled how developers select and tune their data structures in Java programs, showing that developers only rarely tune their data structures and prefer the standard implementations, despite having better performance variants available.
Krikava~et al.\xspace~\cite{Krikava:2019:ScalaImplicits} investigate the usage of implicits - a language feature that allows developers to reduce boilerplate code - in Scala programs.
The results showed a pervasive use of the feature in Scala projects hosted in GitHub. Guilherme and Weiyi~\cite{GuilhermeI:CPC2017} performed an empirical study to examine the prevalence of exception-handling anti-patterns in Java and C\# projects. Their findings showed that all studied projects contain exception handling anti-patterns in their source code. Wang~et al.\xspace~\cite{WangSANER2019} studied the evolution regular expressions over time from the different aspects. Their results showed that the use of regular expressions is stable in the development history of the studied GitHub projects.

The aforementioned work mines software repositories to quantitatively assess the level of adoption of language features from developers.
Our study shares part of this mining repository methodology, such as selecting studied projects, parsing the code to get quantitative results and manually analyze the usage patterns for a qualitative assessment.

\subsection{RQ1. Is \unsafe widely used in open-source Go projects?}
\label{sub:rq_usage}
\input{RQ_Usage}

\subsection{RQ2. \rev{What is \unsafe used for?}}
\label{sub:rq_usagepatterns}
\input{RQ_UsagePatterns}

\subsection{RQ3. What are the risks of using \unsafe?}
\label{sub:rq_badpractices}
\input{RQ_BadPractices}

\subsection{Internal validity}

Threats to internal validity are related to experimenter bias and errors.
To identify \code{unsafe}\xspace usages, we build a customized parser which could miss or introduce false positives in our analysis. To mitigate this threat,
we first took special care to identify all possible ways \code{unsafe}\xspace can be used in Go code, by inspecting import statements for \code{unsafe}\xspace in a number of projects. \revminor{Second, during our manual examination of the detected cases of \code{unsafe}\xspace to catalog the usage patterns, we only found a single case (1/270) of false positive, which give us a the confidence in the accuracy of our customized parser.}
Developers had defined a custom object named ``unsafe" and called a method from the object, filtered in by our parser.
Third, during our experiments, we did not observe any errors when conducting both the analysis on the last snapshot nor the historical analysis, which could indicate we could miss real \code{unsafe}\xspace usages (false negatives).
\revminor{Also, our parser is compatible with all Go version since Go 1.0.0.
Therefore, we believe the results yielded by our unsafe parser will hold.}
We also use the tool Go Vet to identify suspicious cases of invalid pointer conversions. While we have manually assessed that 2 out of 16 cases were false positives, the tool could miss real cases due to the complexity of statically analyzing the code.
Hence, our results with Go Vet should be interpreted as a lower bound of invalid pointer conversions.

Furthermore, we conduct two major manual analyses in our study, to investigate the most used usage patterns and to classify unsafe-related issues.
\rev{In the classification of the \code{unsafe}\xspace usage patterns, we include a single random file per project, hence, our analysis is based on the usage of a single randomly selected file from a representative sample of projects.
This ensured we performed a cross-project analysis and did not bias our usage pattern catalog towards a minority of projects that use \code{unsafe}\xspace extensively (100+ files).
To investigate the representativeness of our analysis, we fully classified all \code{unsafe}\xspace usages of 30 randomly selected projects of our dataset, accounting for 168 files that depend on \code{unsafe}\xspace.
\revminor{This sample analysis showed that 66\% of the projects contain only one \code{unsafe}\xspace usage pattern, and 86\% of the projects contain fewer than two usage patterns in their code-base.}
Furthermore, we observed a similar ranking as the one shown in \Cref{sub:rq2-unsage-usages} when analyzing the distribution of usages under a different perspective: the ranking of \code{unsafe}\xspace usages based on the percentage of projects with at least one case of the usage pattern.
Upon the results of our validation, we believe the ranking reported in RQ2 holds even under other (reasonable) sampling strategies.}

Regarding the analysis of unsafe-related issues, it is important to note that the categories of issues obtained in this analysis are not exhaustive or necessarily representative.
We only investigate issues that have the keyword "unsafe" in its title and hence are bound to miss many unsafe-related issues.
Hence, our analysis is a lower bound of possible unsafe-related issues, providing qualitative support to the risks of using \code{unsafe}\xspace entails to software projects.

\vspace{-0.1in}
\subsection{External validity}
Threats to external validity are related to the generalizability of our findings.
Our investigation focused on the most popular Go projects.
Go has established itself as a programming language for high-performance infrastructure projects and the projects in our dataset reflect that (e.g., there is a relative low number of front-end projects).
The \code{unsafe}\xspace package is used for low-level implementation and optimization, hence its prevalence is expected to decrease on less popular projects or on a more diverse set that may not have the pressure for high-performance code.
We argue that, while not fully generalizable to all Go software projects, our dataset contains the most influential projects of the current Go landscape. Also, in our analysis, we examine open-source Go projects that are hosted on GitHub. Thus, our results may not generalize to proprietary projects.
\section{Introduction}
\input{Introduction}

\section{Background}
\label{sec:background}
\input{Background}

\section{Methodology}
\label{sec:methodology}
\input{Methodology}

\section{Is \unsafe widely used in open-source Go projects?}
\label{sub:rq_usage}
\input{RQ_Usage}

\section{\rev{What is \unsafe used for?}}
\label{sub:rq_usagepatterns}
\input{RQ_UsagePatterns}

\vspace{-0.1in}
\section{What are the risks of using \unsafe?}
\label{sub:rq_badpractices}
\input{RQ_BadPractices}

\vspace{-0.1in}
\section{Discussion}
\label{sec:discussion}
\input{Discussion}

\vspace{-0.1in}
\section{Related Work}
\label{sec:related-work}
\input{Related_work}

\section{Threats to Validity}
\label{sec:threats}
\input{Threats_to_validity}

\section{Conclusion}
\label{sec:conclusion}
\input{Conclusion}

\appendices

\ifCLASSOPTIONcompsoc
\else
  \section*{Acknowledgment}
\fi

\vspace{-0.1in}
\section*{Acknowledgment}
The authors would like to thank Matthew Dempsky, for providing invaluable feedback and for communicating our work to members of the Go Team.

\ifCLASSOPTIONcaptionsoff
  \newpage
\fi

\bibliographystyle{abbrv}

redpajama_set_name: RedPajamaArXiv


text:
Flat-Earther 'Mad' Mike Hughes Is Being Sponsored by a Dating App to Nearly Get Himself Killed
By Brandon Specktor - Senior Writer 2019-08-09T21:00:26Z
'Mad' Mike Hughes — a self-taught rocket scientist and avowed flat-Earth conspiracy theorist — is launching himself into the sky again.
(Image: © Shutterstock)
"Mad" Mike Hughes, a self-taught rocketeer and flat-Earth conspiracy theorist, will once again attempt to launch himself into the sky over the Mojave Desert on a steam-powered rocket this Sunday (Aug. 11), hopefully reaching heights of 5,000 feet (1,500 meters) before parachuting safely back to the round, welcoming Earth. (What are you doing this weekend?)
The stunt, which is being sponsored by a "commitment-free dating app" and filmed as part of an upcoming Discovery Channel series featuring Hughes, gives the 63-year-old rocketeer a chance to outdo himself following a successful-yet-bumpy DIY launch he completed in March 2018.
Despite multiple setbacks and dust-ups with the Bureau of Land Management, Hughes rode his homemade rocket some 1,875 feet (572 m) into the air over Amboy, California, on March 24, 2018, before plummeting back to Earth at 350 mph (563 km/h). Hughes had to deploy two parachutes to save himself from smashing into the desert nose-first, finally walking away with just a sore back.
This Sunday's launch looks to be a bit riskier, with Hughes aiming to blast himself more than twice as high into the sky before dropping back to Earth at around 400 mph (643 km/h), according to a news release for the event. As with last year's launch, Hughes reportedly made his new steam-powered rocket at home in his garage — however, he will get some help this time in the form of a portable launchpad, instead of having to jury-rig a mobile home into a ramp (as he did last year).
Will Hughes be able to see the curvature of the Earth from his mile-high vantage point, thus crushing his stated belief that our planet is "shaped like a Frisbee?" Not unless his steam-powered contraption exceeds its reach by about seven-fold, carrying him 35,000 feet (10,700 m) up instead.
But proving or disproving the Earth's 100% verifiable roundness is not the goal of this stunt, anyway. As Hughes has said before, he will need to soar past the Kármán line — that contested boundary where the sky ends and space begins, roughly 62 miles (100 kilometers) over Earth — to personally see our apparently latke-shaped planet from space with his own eyes. To do that, Hughes told the Associated Press last year, he wants to build a "Rockoon," or rocket/gas-balloon-hybrid, which he can use to float high into the atmosphere before lighting the rocket's fuse and blasting up even farther. This Sunday's event puts him one small step closer to that ambition.
Truly, 2019 is an exciting time to love rocket science while believing that everything NASA says is a lie.
7 Ways to Prove Earth Is Round (Without Going to Space)
101 Images of a Round Earth Taken from Space
8 Times Flat-Earthers Tried to Challenge Science (And Failed)
Originally published on Live Science.

redpajama_set_name: RedPajamaCommonCrawl


Dads are simple creatures. They don't need much, except for a little encouragement and the occasional token of our appreciation. This Father's Day, say "Hey Dad, you're an awesome guy!" with something simple, and homemade. But, to be honest – if you don't have a gift figured out yet – you're kind of short on time. Don't fret. These DIY's are not only awesome (just like Dad) but also super quick and easy to make!
Chocolate covered pretzels. Go buy really good chocolate, good pretzels – and make them one.
Homemade Ketchup. Remember, Dad's a simple guy – homemade ketchup will blow his mind!
Shadow Photos. He'll definitely want this photo sitting on his desk at work! And another hanging on the wall. And on his phone.
Homemade BBQ Sauce. Dads and BBQ go together like wheatgrass and coconut water. That means he'll love it.
Collar Stays. You know those little tabs that he sticks into his collars to keep them straight? No? Trust me, he does. He'll love this!


"Projects With Popsicle Sticks: Popsicle sticks can be glued, taped, or even friction-fit together to create all sorts of cool objects and designs. Check out these awesome projects with popsicle sticks to see what you can make!"... "Projects With Popsicle Sticks: Popsicle sticks can be glued, taped, or even friction-fit together to create all sorts of cool objects and designs. Check out these awesome projects with popsicle sticks to see what you can make!"
Build Plank House Popsicle Sticks How To Build With Wood Scaffolding Build Plank House Popsicle Sticks Boat Headquarters Inc my outdoor plans sheds Tuff Shed Garden Ranch 10x14 Storage Sheds For Sale Homemade 12x14 Pole Shed Doors You can find plans property hardware and improvement stores, books and magazines along with the internet.
4/05/2011 · The boat has to displace at least 7 kg or water to stay afloat. Find the volume of water by Volume = mass/density. This has to be at least the volume of the boat, so design the boat around that.
If you find yourself faced with a summer full of crazy children running through your house, finding inexpensive and simple ways to entertain them can be like finding a gold mine in your basement.


There are a lot of things that lead to the death of Lara Croft caused by depletion of her Energy.
Lara can also be killed by traps. These may often cause instant death.
Lara can also receive damage by simply interacting with her surroundings.
This page was last modified on 3 July 2008, at 00:37.


both represents and provides professional advice to German and foreign clients in all fields of national, European and international industrial property rights, in particular in patent, design and trademark matters.
In conflicts concerning industrial property and in cases of infringement of industrial property, we support our clients in developing suitable attack and defence strategies, be it by means of out-of-court settlement or through legal action, taking into account the economic interests.
Our legal advice is based on the long-standing experience of our patent law firm, which was founded in 1959.


text:
Art & Glamour
Special Supplement
Mujib Barsho Celebration
Wednesday, January 20, 2021 ePaper
Tech Post
Nurul Islam Hasib
National,Back Page
Transgender people face discrimination in Asia, Pacific
Transgender people face discrimination in many countries in the Asia and the Pacific, despite laws to ensure equal rights of all individuals.Experts made the comment at the closing session of the 10th Asia Pacific Conference on Reproductive and Sexual Health and Rights (APCRSHR10) held in 14 session...
National,Front Page
Hasina, Modi summit gives new directions
Prime Minister Sheikh Hasina and her Indian counterpart Narendra Modi have given much-needed directions for the future cooperation between the neighbours in the virtual summit on Thursday amid pandemic, experts say."The summit showcases the close relationship between India and Bangladesh. It a...
Dhaka, Delhi revive historic links
Dhaka and New Delhi on Thursday revived the historic links between the neighbours by deciding to jointly commemorate the 50th anniversary of the 1971 Liberation War through several activities in India, Bangladesh and third countries.In their first summit amid the coronavirus pandemic, Bangladesh Pri...
Hasina-Modi historic summit today
Prime Minister Sheikh Hasina is set to hold talks with her Indian counterpart Narendra Modi on Thursday in the first-ever virtual summit amid Covid-19 pandemic that foreign minister Dr AK Abdul Momen termed as 'historic'.He told Bangladesh Post that they are expecting to sign 'at l...
Pandemic worsening gender-based violence
The pandemic is "exacerbating" the pre-existing gender-based violence (GBV) in the Asia-Pacific region and is "likely to deepen inequalities", UNFPA's technical specialist Sujata Tuladhar says.The pandemic is also limiting the GBV survivors' ability to distance themse...
Covid comes as a double blow to people with HIV
More than 80 percent of women living with HIV in the Asia Pacific Region have reported that they lacked access to sexual and reproductive health and rights services (SRHR), including contraception, during Covid-19 lockdowns.Proportion of young key populations in Asia Pacific who experienced delays o...
People with disabilities face greater SRHR challenges
It's not easy to talk about sexual and reproductive health and rights (SRHR) in the countries of Asia and the Pacific. But it becomes even more challenging for a person with a disability."Most countries in the Asia Pacific region have focused on improving people with disabilities' ...
Process to forge new FP partnership begins in Jan
The recommitment process of the FP2020 will kick off in January and run through the year with an aim to devise a new 'commitment-based' partnership model for family planning.The new partnership, which is expected to be launched formally at the International Conference on Family Planning ...
Dengue control: Dhaka North shows the way
It was a "big surprise" for Mohammed Noman that he did not feel the presence of mosquitoes in his area at Mohammadpur during the pandemic."This is for the first time in my three years of living in Dhaka I had such mosquito-free experience," he said.He observed that municipal ...
Indian 'air bubble' gives new life to Bangladeshi patients
It has been a 'painful' seven months wait for Mohammed Wahiduzzaman until Wednesday when he has been able to travel to India for medical treatment under a new 'air bubble' mechanism."I had my spine surgery in Chennai, but I could not follow that up properly. It was a pa...
Corona vaccines create doubts among people
A new study published in the Nature Medicine revealed potential global hesitance to accept a Covid-19 vaccine.A research team from The Barcelona Institute for Global Health (ISGlobal), an institution supported by 'la Caixa' Foundation, the City University of New York Graduate School of P...
Health workers face challenges to provide SRH services to Rohingyas
The Bangladesh government has ensured sexual and reproductive health (SRH) services to Rohingya refugees in Cox's Bazar camps, but the health workers are facing challenges to do the job.The challenges reported by most of the health workers were healthcare seeking behaviours of refugees, lack o...
Bangladesh ensures full abortion care to save Rohingya women
An international study has hailed the provision of 'comprehensive abortion care' for Rohingya women in Cox's Bazar camps, and said that it showed such care can be implemented in a humanitarian setting."The favourable legal environment of menstrual regulations (MR) in Banglade...
Good news for stranded Saudi returnees
Good news for the stranded Saudi Arabia returnees in Bangladesh – they will be able to join their works.Foreign minister Dr AK Abdul Momen told Bangladesh Post on Wednesday evening that both sides have decided to allow their respective national flag carriers to operate flights."We have v...
How does US explain Indo-Pacific strategy?
The Indo-Pacific Strategy (IPS) is a buzz-phrase today with different interpretations. President Donald Trump has made US engagement in the Indo-Pacific region a top priority of his administration. The Indo-Pacific region spans two regions of the Indian Ocean and the Pacific Ocean stretching fr...
Older people suffer from SRHR misperception
Older people mostly in low income countries suffer from 'misperception' of sexual and reproductive health and rights (SRHR), experts at an international conference said."There is a common misperception that older people are not sexually active, and so they do not need sexual health...
Bangladesh takes special FP plan for pandemic
Bangladesh has taken special measures to continue family planning (FP) services uninterrupted during the pandemic lockdown."A national preparation and response plan was prepared keeping in mind recent projections from UNFPA on the increase of unintended pregnancies with the continuation of loc...
Covid-19 slows slightly in Bangladesh
Bangladesh's rising coronavirus cases slowed down slightly in recent days, but the health ministry remained at "war-footing" to prevent any further waves.The Directorate General of Health Services on Friday registered 1,929 new cases while the figure was 2,158 on Thursday, 2,582 on...
Bangladesh loses a true friend
Pranab Mukherjee is no more. The 13th President of India and a towering figure in subcontinent politics, Mukherjee died on Monday at Army Hospital in Delhi where he was on ventilation support. He was 84. His death has created a huge vacuum not in India alone, as he was one of the "most te...
A serious burden on Bangladesh
It was an unprecedented humanitarian gesture when Bangladesh opened her door to the hundreds of thousands of Rohingyas fleeing 'ethnic cleansing' from the neighbouring Rakhine State on August 25, 2017.Prime Minister Sheikh Hasina, based on the country's own experience in the 1971 w...
Page 1 of 5, showing 20 results out of 90 total
Opinion Writers
Staff Correspondents
District Correspondents
Today's Arts
Editor-In-Chief: Sharif Shahab Uddin. Published By Rick Haque Sikder.
From Sena Kalyan Business Mart (2nd floor), 218/C, Bir Uttam Mir Shawkat Sarak (Tejgaon-Gulshan Link Road), Dhaka-1208.
Phone : 09617171194, +880248811775-6 Fax : +880-2-8878495.
Email : news@bangladeshpost.net
© 2021 Bangladesh Post. Any reproduction of our content from this site is a flagrant copyright infringement liable to legal action.


Why are green homes important?
Saving energy: Green buildings that achieve the Green Star certification in Australia produce 62% fewer greenhouse gas emissions and use 51% less potable water than average buildings. In India, homes certified by the Indian Green Building Council save 40-50% more energy than conventional buildings.
Improving wellbeing: Research shows that better indoor air quality (low concentrations of CO2 and pollutants, and high ventilation rates) can boost productivity by up to 8%.
Growing investments: For landlords and building owners, green buildings – both new and renovated – command a 7% increase in asset value over traditional ones.
What does a green home look like?
Green homes all look different. Some are designed to be environmentally friendly and sustainable right from the start – they are built to use less water and energy. But whether you live in a high rise, a bungalow, a log cabin or a mud home, you can still make it greener. See below for some ideas of what you can do. It's easy when you know how.
How can green homes save money?
Going green doesn't have to cost the earth. Lower energy bills mean more money in your pocket. According to the European Commission, global energy efficiency measures could save up to €410 billion on energy spending.
The average US household spends around $2,000 on energy bills each year and between 10 and 20% of that could be going to waste as a result of drafts, air leaks around openings and outdated heating and cooling systems. Making standard efficiency improvements like sealing up air leaks, putting in insulation or installing programmable thermostats could put an extra $400 in your pocket.
Taking a shower uses around 80% less water than a bath. That's a big saving on money, water and electricity over a year.
Why are green homes healthier homes?
Going green is good for you! Every year the cost to European societies of the illnesses caused by unhealthy buildings is €82 billion, so action is needed to address both health and climate. And it's not hard.
Natural light makes spaces healthier and cuts down on energy use. It reduces mould growth, improves sleep and boosts access to vitamin D.
We breathe around 11,000 litres of air a day, so quality matters. Using green materials, like carpets and paints with fewer toxins and chemicals, can really improve indoor air quality.
House plants remove toxins from the atmosphere, improve productivity and reduce stress. Whichever way you look at it, green is the healthiest colour.
Learn more about the health and wellbeing benefits of green buildings through our Better Places for People project research.
What can I do to make my home greener?
As our communities grow, so does our need for energy and water. Cutting consumption at home helps you and your neighbour, and saves precious natural resources.
Simple upgrades, like switching to a low carbon energy provider, will save energy and money.
Lighten up! Make the most of natural light, replace your bulbs with LEDs and switch lights off when you go out.
Stay cool. Save energy by using ceiling fans, rather than air conditioning, and lowering the temperature on your thermostat.
Using green materials like carpets and paints with fewer toxins and chemicals, can really improve indoor air quality. And as we breathe around 11,000 litres of air a day, quality matters.
Clean up by washing clothes on a cold setting and line drying your laundry.
Our homes can help us use energy and water efficiently. Investing in the latest smart tech appliances is a smart move.
How can I make my home or workplace green?
There are many ways to make buildings, whether homes, offices, factories or schools, greener. Visit the "How to make buildings green" page on our website to find out the multiple ways to do so.
You can also contact or visit the website of your local Green Building Council for more information. Find out if there is a GBC in your country by visiting the Member Directory on our website.
Join the conversation using the hashtags #HomeGreenHome and #WGBW2018.
I pledge to cut my energy use by 20% over a year. That's my #HomeGreenHome promise.
I'm going to tell my work colleagues about #WGBW2018 over a lunch and learn. That's my #HomeGreenHome promise.
I'm switching all my light bulbs to LEDs. That's my #HomeGreenHome promise.
I'm going to turn the thermostat down and save energy and money. That's my #HomeGreenHome promise.
Talk to your network about why green homes matter and urge them to join the #HomeGreenHome movement.
Host a #HomeGreenHome Open House event to raise awareness in your community. Think about inviting a local expert to share ideas.
Talk to your neighbours about how you might be able to work together to save water and energy.
Use your website or blog to make resources available on green housing issues in your region, like renovations, mortgages and smart technology.
If you're responsible for developing or retrofitting homes, think about ways you can make them greener.