Merge branch 'master' into remove-forceErrors

doc/external-api/README.md

@@ -46,9 +46,9 @@ Nix expression `builtins.nixVersion`.
 // NOTE: This example lacks all error handling. Production code must check for
 // errors, as some return values will be undefined.
 
-void my_get_string_cb(const char * start, unsigned int n, char ** user_data)
+void my_get_string_cb(const char * start, unsigned int n, void * user_data)
 {
-    *user_data = strdup(start);
+    *((char **) user_data) = strdup(start);
 }
 
 int main()
@@ -63,7 +63,7 @@ int main()
     nix_value_force(NULL, state, value);
 
     char * version;
-    nix_get_string(NULL, value, my_get_string_cb, version);
+    nix_get_string(NULL, value, my_get_string_cb, &version);
     printf("Nix version: %s\n", version);
 
     free(version);

doc/manual/src/SUMMARY.md.in

@@ -18,6 +18,7 @@
   - [Uninstalling Nix](installation/uninstall.md)
 - [Nix Store](store/index.md)
   - [File System Object](store/file-system-object.md)
+    - [Content-Addressing File System Objects](store/file-system-object/content-address.md)
   - [Store Object](store/store-object.md)
   - [Store Path](store/store-path.md)
   - [Store Types](store/types/index.md)

doc/manual/src/command-ref/nix-collect-garbage.md

@@ -74,4 +74,4 @@ $ nix-collect-garbage -d
 ```
 
 [profiles]: @docroot@/command-ref/files/profiles.md
-[store objects]: @docroot@/glossary.md#gloss-store-object
+[store objects]: @docroot@/store/store-object.md

doc/manual/src/command-ref/nix-env/delete-generations.md

@@ -49,7 +49,7 @@ Periodically deleting old generations is important to make garbage collection
 effective.
 The is because profiles are also garbage collection roots — any [store object] reachable from a profile is "alive" and ineligible for deletion.
 
-[store object]: @docroot@/glossary.md#gloss-store-object
+[store object]: @docroot@/store/store-object.md
 
 {{#include ./opt-common.md}}
 

doc/manual/src/command-ref/nix-env/install.md

@@ -17,7 +17,7 @@
 The `--install` operation creates a new user environment.
 It is based on the current generation of the active [profile](@docroot@/command-ref/files/profiles.md), to which a set of [store paths] described by *args* is added.
 
-[store paths]: @docroot@/glossary.md#gloss-store-path
+[store paths]: @docroot@/store/store-path.md
 
 The arguments *args* map to store paths in a number of possible ways:
 

doc/manual/src/command-ref/nix-hash.md

@@ -20,16 +20,21 @@ an example.
 The hash is computed over a *serialisation* of each path: a dump of
 the file system tree rooted at the path. This allows directories and
 symlinks to be hashed as well as regular files. The dump is in the
-*NAR format* produced by [`nix-store
+*[Nix Archive (NAR)][Nix Archive] format* produced by [`nix-store
 --dump`](@docroot@/command-ref/nix-store/dump.md).  Thus, `nix-hash path`
 yields the same cryptographic hash as `nix-store --dump path |
 md5sum`.
 
+[Nix Archive]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive
+
 # Options
 
   - `--flat`\
-    Print the cryptographic hash of the contents of each regular file
-    *path*. That is, do not compute the hash over the dump of *path*.
+    Print the cryptographic hash of the contents of each regular file *path*.
+    That is, instead of computing
+    the hash of the [Nix Archive (NAR)](@docroot@/store/file-system-object/content-address.md#serial-nix-archive) of *path*,
+    just [directly hash]((@docroot@/store/file-system-object/content-address.md#serial-flat) *path* as is.
+    This requires *path* to resolve to a regular file rather than directory.
     The result is identical to that produced by the GNU commands
     `md5sum` and `sha1sum`.
 

doc/manual/src/command-ref/nix-store/dump.md

@@ -1,14 +1,14 @@
 # Name
 
-`nix-store --dump` - write a single path to a Nix Archive
+`nix-store --dump` - write a single path to a [Nix Archive]
 
 ## Synopsis
 
 `nix-store` `--dump` *path*
 
 ## Description
 
-The operation `--dump` produces a NAR (Nix ARchive) file containing the
+The operation `--dump` produces a [NAR (Nix ARchive)][Nix Archive] file containing the
 contents of the file system tree rooted at *path*. The archive is
 written to standard output.
 
@@ -33,6 +33,8 @@ but not other types of files (such as device nodes).
 A Nix archive can be unpacked using `nix-store
 --restore`.
 
+[Nix Archive]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive
+
 {{#include ./opt-common.md}}
 
 {{#include ../opt-common.md}}

doc/manual/src/command-ref/nix-store/export.md

@@ -1,6 +1,6 @@
 # Name
 
-`nix-store --export` - export store paths to a Nix Archive
+`nix-store --export` - export store paths to a [Nix Archive]
 
 ## Synopsis
 
@@ -11,14 +11,16 @@
 The operation `--export` writes a serialisation of the specified store
 paths to standard output in a format that can be imported into another
 Nix store with `nix-store --import`. This is like `nix-store
---dump`, except that the NAR archive produced by that command doesn’t
+--dump`, except that the [Nix Archive (NAR)][Nix Archive] produced by that command doesn’t
 contain the necessary meta-information to allow it to be imported into
 another Nix store (namely, the set of references of the path).
 
 This command does not produce a *closure* of the specified paths, so if
 a store path references other store paths that are missing in the target
 Nix store, the import will fail.
 
+[Nix Archive]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive
+
 {{#include ./opt-common.md}}
 
 {{#include ../opt-common.md}}

doc/manual/src/command-ref/nix-store/import.md

@@ -1,6 +1,8 @@
 # Name
 
-`nix-store --import` - import Nix Archive into the store
+`nix-store --import` - import [Nix Archive] into the store
+
+[Nix Archive]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive
 
 # Synopsis
 

doc/manual/src/command-ref/nix-store/optimise.md

@@ -12,7 +12,7 @@ The operation `--optimise` reduces Nix store disk space usage by finding
 identical files in the store and hard-linking them to each other. It
 typically reduces the size of the store by something like 25-35%. Only
 regular files and symlinks are hard-linked in this manner. Files are
-considered identical when they have the same NAR archive serialisation:
+considered identical when they have the same [Nix Archive (NAR)][Nix Archive] serialisation:
 that is, regular files must have the same contents and permission
 (executable or non-executable), and symlinks must have the same
 contents.
@@ -38,3 +38,4 @@ hashing files in `/nix/store/qhqx7l2f1kmwihc9bnxs7rc159hsxnf3-gcc-4.1.1'
 there are 114486 files with equal contents out of 215894 files in total
 ```
 
+[Nix Archive]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive

doc/manual/src/command-ref/nix-store/realise.md

@@ -25,11 +25,11 @@ Each of *paths* is processed as follows:
 
 If no substitutes are available and no store derivation is given, realisation fails.
 
-[store paths]: @docroot@/glossary.md#gloss-store-path
+[store paths]: @docroot@/store/store-path.md
 [valid]: @docroot@/glossary.md#gloss-validity
 [store derivation]: @docroot@/glossary.md#gloss-store-derivation
 [output paths]: @docroot@/glossary.md#gloss-output-path
-[store objects]: @docroot@/glossary.md#gloss-store-object
+[store objects]: @docroot@/store/store-object.md
 [closure]: @docroot@/glossary.md#gloss-closure
 [substituters]: @docroot@/command-ref/conf-file.md#conf-substituters
 [content-addressed derivations]: @docroot@/contributing/experimental-features.md#xp-feature-ca-derivations

doc/manual/src/command-ref/nix-store/restore.md

@@ -8,9 +8,11 @@
 
 ## Description
 
-The operation `--restore` unpacks a NAR archive to *path*, which must
+The operation `--restore` unpacks a [Nix Archive (NAR)][Nix Archive] to *path*, which must
 not already exist. The archive is read from standard input.
 
+[Nix Archive]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive
+
 {{#include ./opt-common.md}}
 
 {{#include ../opt-common.md}}

doc/manual/src/contributing/documentation.md

@@ -147,7 +147,7 @@ Please observe these guidelines to ease reviews:
   ```
   A [store object] contains a [file system object] and [references] to other store objects.
 
-  [store object]: @docroot@/glossary.md#gloss-store-object
+  [store object]: @docroot@/store/store-object.md
   [file system object]: @docroot@/architecture/file-system-object.md
   [references]: @docroot@/glossary.md#gloss-reference
   ```

doc/manual/src/glossary.md

@@ -1,5 +1,24 @@
 # Glossary
 
+- [content address]{#gloss-content-address}
+
+  A
+  [*content address*](https://en.wikipedia.org/wiki/Content-addressable_storage)
+  is a secure way to reference immutable data.
+  The reference is calculated directly from the content of the data being referenced, which means the reference is
+  [*tamper proof*](https://en.wikipedia.org/wiki/Tamperproofing)
+  --- variations of the data should always calculate to distinct content addresses.
+
+  For how Nix uses content addresses, see:
+
+    - [Content-Addressing File System Objects](@docroot@/store/file-system-object/content-address.md)
+    - [content-addressed store object](#gloss-content-addressed-store-object)
+    - [content-addressed derivation](#gloss-content-addressed-derivation)
+
+  Software Heritage's writing on [*Intrinsic and Extrinsic identifiers*](https://www.softwareheritage.org/2020/07/09/intrinsic-vs-extrinsic-identifiers) is also a good introduction to the value of content-addressing over other referencing schemes.
+
+  Besides content addressing, the Nix store also uses [input addressing](#gloss-input-addressed-store-object).
+
 - [derivation]{#gloss-derivation}
 
   A description of a build task. The result of a derivation is a
@@ -266,13 +285,15 @@
 
   See [installables](./command-ref/new-cli/nix.md#installables) for [`nix` commands](./command-ref/new-cli/nix.md) (experimental) for details.
 
-- [NAR]{#gloss-nar}
+- [Nix Archive (NAR)]{#gloss-nar}
 
   A *N*ix *AR*chive. This is a serialisation of a path in the Nix
   store. It can contain regular files, directories and symbolic
   links.  NARs are generated and unpacked using `nix-store --dump`
   and `nix-store --restore`.
 
+  See [Nix Archive](store/file-system-object/content-address.html#serial-nix-archive) for details.
+
 - [`∅`]{#gloss-emtpy-set}
 
   The empty set symbol. In the context of profile history, this denotes a package is not present in a particular version of the profile.

doc/manual/src/language/advanced-attributes.md

@@ -199,19 +199,23 @@ Derivations can declare some infrequently used optional attributes.
     The `outputHashMode` attribute determines how the hash is computed.
     It must be one of the following two values:
 
-      - `"flat"`\
-        The output must be a non-executable regular file. If it isn’t,
-        the build fails. The hash is simply computed over the contents
-        of that file (so it’s equal to what Unix commands like
-        `sha256sum` or `sha1sum` produce).
+    <!-- FIXME link to store object content-addressing not file system object content addressing once we have the page for that. -->
+
+      - `"flat"`
+
+        The output must be a non-executable regular file; if it isn’t, the build fails.
+        The hash is
+        [simply computed over the contents of that file](@docroot@/store/file-system-object/content-address.md#serial-flat)
+        (so it’s equal to what Unix commands like `sha256sum` or `sha1sum` produce).
 
         This is the default.
 
-      - `"recursive"` or `"nar"`\
-        The hash is computed over the [NAR archive](@docroot@/glossary.md#gloss-nar) dump of the output
-        (i.e., the result of [`nix-store --dump`](@docroot@/command-ref/nix-store/dump.md)). In
-        this case, the output can be anything, including a directory
-        tree.
+      - `"recursive"` or `"nar"`
+
+        The hash is computed over the
+        [Nix Archive (NAR)](@docroot@/store/file-system-object/content-address.md#serial-nix-archive)
+        dump of the output (i.e., the result of [`nix-store --dump`](@docroot@/command-ref/nix-store/dump.md)).
+        In this case, the output is allowed to be any [file system object], including directories and more.
 
     `"recursive"` is the traditional way of indicating this,
     and is supported since 2005 (virtually the entire history of Nix).
@@ -303,7 +307,7 @@ Derivations can declare some infrequently used optional attributes.
     [`disallowedReferences`](#adv-attr-disallowedReferences) and [`disallowedRequisites`](#adv-attr-disallowedRequisites),
     the following attributes are available:
 
-    - `maxSize` defines the maximum size of the resulting [store object](@docroot@/glossary.md#gloss-store-object).
+    - `maxSize` defines the maximum size of the resulting [store object](@docroot@/store/store-object.md).
     - `maxClosureSize` defines the maximum size of the output's closure.
     - `ignoreSelfRefs` controls whether self-references should be considered when
       checking for allowed references/requisites.

doc/manual/src/language/derivations.md

@@ -17,7 +17,7 @@ It outputs an attribute set, and produces a [store derivation] as a side effect
   A symbolic name for the derivation.
   It is added to the [store path] of the corresponding [store derivation] as well as to its [output paths](@docroot@/glossary.md#gloss-output-path).
 
-  [store path]: @docroot@/glossary.md#gloss-store-path
+  [store path]: @docroot@/store/store-path.md
 
   > **Example**
   >
@@ -141,7 +141,7 @@ It outputs an attribute set, and produces a [store derivation] as a side effect
 
   By default, a derivation produces a single output called `out`.
   However, derivations can produce multiple outputs.
-  This allows the associated [store objects](@docroot@/glossary.md#gloss-store-object) and their [closures](@docroot@/glossary.md#gloss-closure) to be copied or garbage-collected separately.
+  This allows the associated [store objects](@docroot@/store/store-object.md) and their [closures](@docroot@/glossary.md#gloss-closure) to be copied or garbage-collected separately.
 
   > **Example**
   >

doc/manual/src/language/import-from-derivation.md

@@ -2,9 +2,9 @@
 
 The value of a Nix expression can depend on the contents of a [store object].
 
-[store object]: @docroot@/glossary.md#gloss-store-object
+[store object]: @docroot@/store/store-object.md
 
-Passing an expression `expr` that evaluates to a [store path](@docroot@/glossary.md#gloss-store-path) to any built-in function which reads from the filesystem constitutes Import From Derivation (IFD):
+Passing an expression `expr` that evaluates to a [store path](@docroot@/store/store-path.md) to any built-in function which reads from the filesystem constitutes Import From Derivation (IFD):
 
 - [`import`](./builtins.md#builtins-import)` expr`
 - [`builtins.readFile`](./builtins.md#builtins-readFile)` expr`

doc/manual/src/language/operators.md

@@ -128,7 +128,7 @@ The result is a string.
 > The file or directory at *path* must exist and is copied to the [store].
 > The path appears in the result as the corresponding [store path].
 
-[store path]: @docroot@/glossary.md#gloss-store-path
+[store path]: @docroot@/store/store-path.md
 [store]: @docroot@/glossary.md#gloss-store
 
 [String and path concatenation]: #string-and-path-concatenation

doc/manual/src/language/string-interpolation.md

@@ -107,9 +107,9 @@ An expression that is interpolated must evaluate to one of the following:
 
 A string interpolates to itself.
 
-A path in an interpolated expression is first copied into the Nix store, and the resulting string is the [store path] of the newly created [store object](@docroot@/glossary.md#gloss-store-object).
+A path in an interpolated expression is first copied into the Nix store, and the resulting string is the [store path] of the newly created [store object](@docroot@/store/store-object.md).
 
-[store path]: @docroot@/glossary.md#gloss-store-path
+[store path]: @docroot@/store/store-path.md
 
 > **Example**
 >

doc/manual/src/language/values.md

@@ -124,7 +124,7 @@
   For example, assume you used a file path in an interpolated string during a `nix repl` session.
   Later in the same session, after having changed the file contents, evaluating the interpolated string with the file path again might not return a new [store path], since Nix might not re-read the file contents. Use `:r` to reset the repl as needed.
 
-  [store path]: @docroot@/glossary.md#gloss-store-path
+  [store path]: @docroot@/store/store-path.md
 
   Path literals can also include [string interpolation], besides being [interpolated into other expressions].
 

doc/manual/src/protocols/json/store-object-info.md

@@ -28,9 +28,9 @@ Info about a [store object].
 
   Content address of this store object's file system object, used to compute its store path.
 
-[store path]: @docroot@/glossary.md#gloss-store-path
+[store path]: @docroot@/store/store-path.md
 [file system object]: @docroot@/store/file-system-object.md
-[Nix Archive]: @docroot@/glossary.md#gloss-nar
+[Nix Archive]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive
 
 ## Impure fields
 

doc/manual/src/protocols/nix-archive.md

@@ -1,9 +1,10 @@
 # Nix Archive (NAR) format
 
-This is the complete specification of the Nix Archive format.
+This is the complete specification of the [Nix Archive] format.
 The Nix Archive format closely follows the abstract specification of a [file system object] tree,
 because it is designed to serialize exactly that data structure.
 
+[Nix Archive]: @docroot@/store/file-system-object/content-address.md#nix-archive
 [file system object]: @docroot@/store/file-system-object.md
 
 The format of this specification is close to [Extended Backus–Naur form](https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form), with the exception of the `str(..)` function / parameterized rule, which length-prefixes and pads strings.

doc/manual/src/protocols/store-path.md

@@ -1,12 +1,14 @@
 # Complete Store Path Calculation
 
-This is the complete specification for how store paths are calculated.
+This is the complete specification for how [store path]s are calculated.
 
 The format of this specification is close to [Extended Backus–Naur form](https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form), but must deviate for a few things such as hash functions which we treat as bidirectional for specification purposes.
 
 Regular users do *not* need to know this information --- store paths can be treated as black boxes computed from the properties of the store objects they refer to.
 But for those interested in exactly how Nix works, e.g. if they are reimplementing it, this information can be useful.
 
+[store path](@docroot@/store/store-path.md)
+
 ## Store path proper
 
 ```ebnf
@@ -113,7 +115,7 @@ where
       Note that `id` = `"out"`, regardless of the name part of the store path.
       Also note that NAR + SHA-256 must not use this case, and instead must use the `type` = `"source:" ...` case.
 
-[Nix Archive (NAR)]: @docroot@/glossary.md#gloss-NAR
+[Nix Archive (NAR)]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive
 [sha-256]: https://en.m.wikipedia.org/wiki/SHA-256
 
 ### Historical Note

doc/manual/src/protocols/tarball-fetcher.md

@@ -22,7 +22,7 @@ Link: <flakeref>; rel="immutable"
 
 *flakeref* must be a tarball flakeref. It can contain the tarball flake attributes
 `narHash`, `rev`, `revCount` and `lastModified`. If `narHash` is included, its
-value must be the NAR hash of the unpacked tarball (as computed via
+value must be the [NAR hash][Nix Archive] of the unpacked tarball (as computed via
 `nix hash path`). Nix checks the contents of the returned tarball
 against the `narHash` attribute. The `rev` and `revCount` attributes
 are useful when the tarball flake is a mirror of a fetcher type that
@@ -40,3 +40,5 @@ Link: <https://example.org/hello/442793d9ec0584f6a6e82fa253850c8085bb150a.tar.gz
 
 For tarball flakes, the value of the `lastModified` flake attribute is
 defined as the timestamp of the newest file inside the tarball.
+
+[Nix Archive]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive