DEV Community: VanPonasenkov

C - Unsafe!

VanPonasenkov — Wed, 13 Apr 2022 22:13:52 +0000

Introduction

You've probably heard many times by now that is C is not a memory safe language, and that is absolutely correct. Buffer overflows all over the place, memory leaks, and SEGFAULT had even become a taboo. In this small article we're gonna show you some unsafe C code, and we're going to rewrite it in Rust.

The problem

Consider this code:

// lifetimetest.c

#include <stdio.h>
#include <string.h>

char*
longest(char* a, char* b)
{
    if(strlen(a) > strlen(b)){
        return a;
    }
    return b;
}

main(void)
{
    char a[] = "Hello";
    char b[] = "KosherFoods";
    char* res;

    res = longest(a, b);
    printf("%s", res);
}

Here we define the function longest which takes two character pointers (Essentially strings) and it returns the longer string.

if you compile and run this program:
$ gcc lifetimetest.c -o lft.out && ./lft.out
you should get this output:
KosherFoods
Which is what we expected

now let's rewrite this program slightly

#include <stdio.h>
#include <string.h>

char*
longest(char* a, char* b)
{
    if(strlen(a) > strlen(b)){
        return a;
    }
    return b;
}

main(void)
{
    char a[] = "Hello";
    char* res;
    {
        char b[] = "KosherFoods";
        res = longest(a, b);
    }

    printf("%s", res);
}

Here we moved b into a different scope
if you compile and run this program:
$ gcc lifetimetest.c -o lft.out && ./lft.out
you should get this output:
KosherFoods
Nothing peculiar so far.

Let's rewrite the program once again!

#include <stdio.h>
#include <string.h>

char*
longest(char* a, char* b)
{
    if(strlen(a) > strlen(b)){
        return a;
    }
    return b;
}

main(void)
{
    char a[] = "Hello";
    char* res;
    {
        char b[] = "KosherFoods";
        res = longest(a, b);
    }
    char ohnoo[] = "Plan 9 from User Space";
    printf("%s", res);
}

Here we declared a new string variable after the second scope
if you compile and run this program:
$ gcc lifetimetest.c -o lft.out && ./lft.out
you should get this output:
Plan 9 from User Space
But.... How could this Happen?

Explanation

In C, strings are essentially character arrays, and the variables that "store" those strings are just pointers to the start of the array.

So longest doesn't return the copy of the string, but rather, the pointer to the start of the string in memory. With this in mind let's continue. When we declare the variable b in the inner scope it gets put in the memory of that scope, but once the scope closes it gets freed, this means that any other variable can be put in the memory where b once was. so res still points to let's say 0x000004 (Where b once was), but now 0x000004 is the start of the ohnoo string.

Rewrite in Rust

Let's discuss a couple of things before moving on to the implementation. In Rust there is a term "Lifetime", it's means, well.. the lifetime of a reference and it prevents dangling references. with that in mind let's continue.

First let's implement the longest function:

fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
    if a.len() > b.len() {
        a
    } else {
        b
    }
}

Here 'a is the lifetime specifier, which means that both of these parameters must live at least as long as 'a, with this in mind let's continue.

Consider this code:

fn main() {
    let a = String::from("APCHIHBALONGERSTRING");
    let result: &str;
    {
        let b = String::from("Banana");
        result = longest(a.as_str(), b.as_str());
        println!("Longest: {}", result);
    }
}

If we type:
$ cargo run
we should get the following output:

Finished dev [unoptimized + debuginfo] target(s) in 0.01s
Running `target/debug/lifetime_test`
Longest: APCHIHBALONGERSTRING

as you can the rust compiler didn't complain.
Now let's try using the lower lifetime borrow in the higher lifetime:

fn main() {
    let a = String::from("APCHIHBALONGERSTRING");
    let result: &str;
    {
        let b = String::from("Banana");
        result = longest(a.as_str(), b.as_str());
    }
    println!("Longest: {}", result);
}

If we type:
cargo run
We should get the following output:

Compiling lifetime_test v0.1.0 (/home/ernest/projects/lifetime_test)
error[E0597]: `b` does not live long enough
  --> src/main.rs:14:38
   |
14 |         result = longest(a.as_str(), b.as_str());
   |                                      ^^^^^^^^^^ borrowed value does not live long enough
15 |     }
   |     - `b` dropped here while still borrowed
16 |     println!("Longest: {}", result);
   |                             ------ borrow later used here

For more information about this error, try `rustc --explain E0597`.
error: could not compile `lifetime_test` due to previous error

This happens because we borrow the reference to b, but later we drop it (By exiting the scope) thus making the use of result in the outer scope (Higher lifetime) invalid.
As a result, we can't get the same undefined behaviour as we did in C, unless you're explicitly using the unsafe keyword.

Conclusion

In this article we provided an example of why C is dangerous and tricky to use. We've provided an example of the same Rust code and showed how Rust deals with such problems.

Note

Whilst i like Rust and i think it is great for low level things like: Audio libraries, video game engines, web servers, etc., i still don't think it's a good idea to rewrite even parts of the operating systems in Rust

Suck Less - Minimalism and Simplicity

VanPonasenkov — Sun, 03 Apr 2022 21:00:38 +0000

Introduction:

Have you ever heard about suckless and their philosophy? If no, then this article is just for you!

Brief Talk:

Suckless is a famous community in the GNU/Linux world, primarily because of their philosophy and software.

The name is essentially a call-out to software developers that their software, well.. Should Suck Less. But what does it mean to suck less? Let's find out.

History:

Suckless started out as a local community of developers in 2002, which eventually grew and became more wide-known in 2006-2012. Nowadays it's a relatively large community among GNU/Linux folks and is admired by many.

Achievements:

Their main achievements are programs such as: DWM (Dynamic Window Manager), ST (Simple Terminal), II (Irc It), etc.

What makes them so good is that they provide the bare minimum for a functioning app, and let the user easily extend/configure the functionality by directly changing the source code.

A great example of this would be the previously mentioned DWM. It contains only 2000 Significant Lines of Code (I.E meaningful lines of code. So things like curly braces, empty new lines, don't count as such) which makes it very easy to change the code without breaking stuff. Its existing functionality is configured via the "config.h" file, and extended via patching (or diffing) the "dwm.c" file.

Philosophy:

They adhere to the Unix Philosophy of doing one thing, and doing it well.

They focus on simplicity, clarity and keeping things minimal.

They believe that most coders these days think that writing more lines of code results in bigger progress, bigger progress means bigger skill, suckless states that it's simply a delusion. What they say instead is that minimalism sets attainable goals and as such, makes development and extending easier.

A Quote from their own website:

Ingenious ideas are simple. Ingenious software is simple. Simplicity is the heart of the Unix philosophy. The more code lines you have removed, the more progress you have made. As the number of lines of code in your software shrinks, the more skilled you have become and the less your software sucks.

Miscellaneous:

They host a list of software that sucks (Which is bad, duh), and a list of software that rocks (Which is good, duh).
Suckless also gives coding style guidelines which are supposed to make your code more readable.

Summary

To wrap things up, let's recap on things that make your software suck less:

Simplicity, Clarity and Minimalism
Extensibility
Doing one thing, and doing it well

Thanks for Reading!

Links and Further Reading:

https://suckless.org
https://suckless.org/coding_style
https://suckless.org/philosophy/
https://suckless.org/rocks/
https://suckless.org/sucks/

Exceptions - A Bad Turn of Fate

VanPonasenkov — Wed, 23 Mar 2022 18:22:02 +0000

Introduction

You've all heard about exceptions. They are the basis of error handling in most modern OOP languages, examples being Java, JS, C++ . But are they as friendly as they are presented to us? let's find out in this article.

Origins of Exceptions

The Idea of exceptions originated back in the 1960/70's in early implementations of lisp, most notably in Lisp 1.5, where the ERRSET function was used for controlled execution of fallible code. Later lisp versions built on top of this idea, adding the TRY and CATCH primitives. But at that point it had already caught on and other programming languages were starting to implement it as well.

Exceptions in Modern Programming Languages

Exceptions in Java, C++, C#, etc., are represented using default or custom exception classes, which can be created and thrown by the programmer. This allows for a very easy and cheap (In terms of productivity) error handling pattern, but is it as good as people say it is?

Criticism of Exceptions

There are lots of criticism for this error handling pattern, but let's point out a few most significant ones.

NO-OP exception handlers. What i mean by this are exception handlers which are made solely for the purpose of mandatory exception checking. An Example of this behaviour would be:

try {
  code_that_might_fail();
}
catch(Exception e) { // no code here }

Whilst they aren't too bad if you use them a couple of times here and there, once the codebase becomes bigger they make the program harder to read. It becomes more apparent after writing Java for some time, Because Java forces you to handle every possible exception point and it becomes a liability.

Developing from the previous point, it's hard to catch all exceptions without an IDE. If you aren't using a full-fledged IDE, or if you're using something simple like VIM or Emacs, your development time will increase as a result of compile or runtime crashes.
Binary size bloating. A very simple point with little-to-no need in explanation. Modern exception handling isn't native to our architectures, So as a result it causes binaries to become bloated. it is not a problem when for example, you're writing a web-server, but can become a real issue when writing something as low-level as an operating system, or a driver.

But... Is there a better way to do Errors?

The answer is... Most likely! One of the alternatives to exceptions are error values. They're implemented in a very crude way in C, usually by returning NULL from a function. Some modern programming languages expand on this idea. 2 Most prominent examples would be Go and Zig.

Go

Go is a statically typed, compiled programming language designed at Google. Among other design decisions, The Go team decided to use error values, instead of exceptions. Prior to this, Google banned the use of exceptions in their C++ Code. The way you check for errors in Go is something like the following:

val, err := function_that_might_fail()
if err != nil {
  print("Unfortunately our production servers are burning")
} // the error handling part, nil being the null value in Go

As you can see error handling in Go is really straightforward, it fixes all of the above problems of exception handling. It is easy to represent error values internally (Fixes problem 3). It is easy to omit handling the error (Fixes problem 1, 2). A good example of this would be:

val, _ = function_that_might_fail_but_itsfine()
// no error check, Go compiler and the Runtime does not complain
// even if the function returns an error

Go also introduces the defer keyword, which puts the execution of a statement at the end of a scope. It means if you open any resource and then you check for an error, you don't need to close the resource in both branches, thus, making the code clearer. example:

file, err := open_file_posix_is_cool(999)
if err != nil {
   print("Logging to our super secret database")
   return err
}
defer close_file_posix_is_cool(file)

file2, err := open_file_posix_is_cool(998)
if err != nil {
   print("Logging to our super secret database")
   return err
}
defer close_file_posix_is_cool(file2)

file3, err := open_file_posix_is_cool(2048)
if err != nil {
   print("Logging to our super secret database")
   return err
}
defer close_file_posix_is_cool(file3)

// resources are going to be properly cleaned up even if an error in one of the branches would occur

Zig

Zig is an imperative, general-purpose, statically typed, compiled system programming language designed by Andrew Kelley. Zig error values are very similar to that of Go, But they differ in some slight ways. Zig also introduces exhaustive switch statement for error sets, and keywords like try and catch (Not to be confused with try/catch in C++, Java). the try keyword checks if the given expression evaluates to an error, and if it does, returns the error from the function. catch keyword is used for giving the code to be executed in case an error was evaluated from the given expression.

Summary

To wrap things up, let's answer the question given in the introduction - are exceptions as friendly as they are presented to us? from this article we've learnt that the answer is no, and there are good reasons for that. But we've also found an alternative error handling method and showed how it solves shortcomings of exceptions.

Links, References, and further Reading