sortix--sortix/doc/obsolete-stuff

Obsolete Stuff
==============

One of the primary design goals of Sortix is to be a modern Unix system with the
old cruft removed. This means that some features/functions/headers in the C API
has been removed, never implemented in the first place, or is scheduled for
future removal. This is likely inconvenient, as a lot of programs still rely on
these obsolete/broken features, which will have to be fixed. Additionally, it'll
further complicate porting programs to Sortix. However, it is our belief that
ultimately such removals will be beneficial and this is merely a transitional
period. In almost all cases, we have made available superior interfaces that can
be used instead.

It may cause problems for portable programs that these features cannot or should
not be used, as lesser operating systems may not implement the modern
replacements. Either fix such systems or add some feature detection magic.

This is a list of common features that may currently be implemented, but that
you shouldn't use and if you do, then you should fix your program before it
breaks when the feature is finally removed.

You might be tempted to use a preprocessor conditional for __sortix__ to detect
the absence of these obsolete features and the availability of their modern
replacements. Keep in mind that other systems may have the modern replacements
and also may have removed features, and that they may supply other extensions to
replace the features. If you need to be portable, you should use whatever means
to automatically detect the availability of features at compile time, rather
than hardcode cases for each platform, as your software is likely to be ported
to platforms that didn't exist when you wrote your code.

asctime, asctime_r
------------------

This function is fundamentally broken. It doesn't support locales, it adds some
useless newline character at the end, the date format doesn't comply with ISO
standards, asctime is not thread safe, and so on. Actually, the POSIX standard
supplies code that implements the function because the format simply cannot
change. The function was actually already deprecated back in 1989 when the
original C standard was released. The solution is today the same as back then,
simply use the much superior strftime function instead. asctime_r tries to make
the function thread safe, but it doesn't fix the other broken semantics. The
only use of this function is to participate in protocols that somehow manages to
use asctime formatted dates, but then you might as well just paste in the POSIX
example code and hard code it in your program.

Sortix currently implement these functions for compatibility reasons.

creat
-----

Use open() instead of this poorly named function. Additionally, open() has a
similarly poorly named flag O_CREAT that does what you need.

Sortix currently implement this function for compatibility reasons.

ctime, ctime_r
--------------

These functions are defined in terms of asctime and asctime_r. Therefore they
will need to be removed as well.

Sortix currently implement these functions for compatibility reasons.

ftime
-----

Use clock_gettime instead.

gethostbyname, gethostbyaddr
----------------------------

Use the protocol agnostic functions such as getaddrinfo(). For instance, if you
want a HTTP connection to www.example.com, do you really care how the data get
to and from there? Most of the time you want a reliable transport protocol to a
named host, but don't care much about the low-level details. If you use these
modern networking interfaces, then your program can use without modification
IPv4, IPv6, or whatever new protocol is used in the future.

getpgrp
-------

POSIX and BSD disagree on the function prototype for getpgrp. Use getpgid
instead, as everyone agrees on that.

gets
----

Use fgets or getline instead. This function has been removed in the latest C
standard, but most implementations carry it anyways. Curiously it is hated so
much that some compatibility libraries such as gnulib actively use magic to add
deprecation warnings not to use it, but these won't compile because gets isn't
declared in any Sortix headers.

gettimeofday
------------

Use clock_gettime instead.

getwd
-----

Use get_current_dir_name() or getcwd() instead. Don't rely on the existence of
PATH_MAX, but allocate buffers as needed.

isascii
-------

This function is rather pointless. If we use a character encoding that wasn't
ascii compatible, then it doesn't make sense. If we use a sane character
encoding such as UTF-8, then you can simply check if the value is at most 127.

PATH_MAX
--------

There is no such limit in Sortix. The kernel might restrict the path lengths at
some point, but that'll just be to protect against misbehaving processes. You
can use pathconf() or fpathconf() to see if a particular path has a limit, but
otherwise you should just allocate strings as much as needed. There should be
functions in place so you can use paths of any length. If you really need a
limit as a hack to fix a broken program, you can do something like:

    #if !defined(PATH_MAX) && defined(__sortix__)
    #define PATH_MAX 32768
    #endif

If there is ever going to be a path limit, it'll probably be either this value
or higher. Ideally, your programs ought to work with paths of any reasonable
length.

putenv
------

This is a poorly designed interface for manipulating the environment which
interacts quite badly with interfaces such as setenv and unsetenv. The major
problem is that putenv makes the input string itself part of the environment,
but setenv makes a copy of the input string part of the environment. This means
that unsetenv (as well as putenv and setenv when changing an existing variable)
has to somehow know whether the a given entry in environ was allocated by setenv
and whether to free it. This isn't helped by the fact that the environ symbol
is publicly accessible and callers of putenv can change the environment by
editing the string the caller inserted. This means that the implementations of
setenv and unsetenv must do a considerable amount of book-keeping behind the
scenes to figure out whether a string was allocated by setenv or face memory
leaks when environment variables are changed or unset. The solution to get rid
of all the needless complexity putenv forces upon the other functions is simply:
Don't provide putenv in the first place and fix any software that uses putenv to
just call setenv instead.

sdl-config
----------

This SDL utility program is basically broken for cross-compilation and seems to
be a poor counterpart to to pkg-config. If you insist on using such config
tools, use pkg-config instead as it causes fewer problems. If you really need a
sdl-config script, implement it using pkg-config:

    pkg-config "$@" sdl

The Sortix build system actually injects such a sdl-config into the PATH to make
sure programs don't use the wrong SDL libraries when cross-compiling.

setpgrp
-------

POSIX and BSD disagree on the function prototype for setpgrp. Use setpgid
instead, as everyone agrees on that.

settimeofday
------------

Use clock_settime instead.

select
------

The fd_set system is poorly designed and the FD_SETSIZE is considerably smaller
than INT_MIN on most systems, which violates that the value of the file
descriptor shouldn't matter as long as it is between 0 and INT_MAX. It would be
better to use poll instead. There is also the problem that select uses struct
timeval instead of the superior struct timespec, though pselect solves tha
particular problem.

Sortix currently provides this function for compatibility reasons.

strings.h
---------

There must have been some confusion back in the day since this header was
created, rather than the functions just added to string.h. In sane
implementations, you can just include string.h that also declares these
functions. The strings.h header exists in Sortix for source-code compatibility,
but don't be surprised if it just includes the regular string.h.

struct timeval
--------------

This microsecond precision data structure has been fully replaced by struct
timespec, which offers nanosecond precision. All kernel APIs use struct timespec
exclusively.

Sortix currently provides this structure for compatibility reasons.

sys/param.h
-----------

This is a BSD header that contains a bunch of BSD-specific stuff and other
miscellaneous junk. The GNU libc implementation contains some uselese macros
that doesn't justify its existence. The header inclusion can often be deleted
without any problems, but older systems may require its inclusion.

sys/time.h
----------

You don't need this header and it'll be removed at some point. It is filled with
obsolete functions and macros. The only reason you might want it is to get the
declaration of struct timeval, but that data type has been replaced by struct
timespec.

Sortix currently provides this header for compatibility reasons.

sys/timeb.h
-----------

This is a header that contains the ftime function that has been replaced, this
header has been removed as well.

times
-----

This function is badly designed and the whole clock_t and sysconf(_SC_CLK_TCK)
business is insane. It doesn't help there is problem with potential overflowing
and the accuracy of the function varies between systems. You should avoid this
function in favor of clock_gettime and the Sortix extension clocks that provide
the same information as struct timespecs. If you need the atomic semantics of
times, you can use the Sortix extension timens.

Sortix currently provides this function for compatibility reasons.

tmpnam
------

There is an inherently race condition prone and has thread safely issues with a
NULL argument. Use tmpfile() instead if you can do with a file whose name you do
not know. Unfortunately, Sortix has yet no satisfying temporary file creation
function that gives you a file and its name without having to deal with silly
template strings and other problems.

utime
-----

Use utimens instead, or perhaps the more portable utimensat.

Sortix currently provides this function for compatibility reasons.

utimes
------

Use utimens instead, or perhaps the more portable utimensat.