luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-01-12 07:26:15 +01:00
Code Issues Packages Projects Releases Wiki Activity

all: s/availible/available/

Browse Source
This commit is contained in:
Bastien Nocera 2012-03-27 11:01:00 +02:00
parent ec55b19da5
commit 9b0734a09c
2 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
gio/gresource.c
View File

@ -116,10 +116,10 @@ G_DEFINE_BOXED_TYPE (GResource, g_resource, g_resource_ref, g_resource_unref)
* the resource data. * the resource data.
* *
* There are two forms of the generated source, the default version uses the compiler support for constructor * There are two forms of the generated source, the default version uses the compiler support for constructor
* and destructor functions (where availible) to automatically create and register the #GResource on startup * and destructor functions (where available) to automatically create and register the #GResource on startup
* or library load time. If you pass --manual-register two functions to register/unregister the resource is instead * or library load time. If you pass --manual-register two functions to register/unregister the resource is instead
* created. This requires an explicit initialization call in your application/library, but it works on all platforms, * created. This requires an explicit initialization call in your application/library, but it works on all platforms,
* even on the minor ones where this is not availible. (Constructor support is availible for at least Win32, MacOS and Linux.) * even on the minor ones where this is not available. (Constructor support is available for at least Win32, MacOS and Linux.)
* *
* Note that resource data can point directly into the data segment of e.g. a library, so if you are unloading libraries * Note that resource data can point directly into the data segment of e.g. a library, so if you are unloading libraries
* during runtime you need to be very careful with keeping around pointers to data from a resource, as this goes away * during runtime you need to be very careful with keeping around pointers to data from a resource, as this goes away

4
glib/gmain.c
View File

@ -2067,7 +2067,7 @@ g_get_monotonic_time (void)
* 32bit msec counter, updated each ~15msec, wraps in ~50 days * 32bit msec counter, updated each ~15msec, wraps in ~50 days
* - GetTickCount64 (GTC64) * - GetTickCount64 (GTC64)
* Same as GetTickCount, but extended to 64bit, so no wrap * Same as GetTickCount, but extended to 64bit, so no wrap
* Only availible in Vista or later * Only available in Vista or later
* - timeGetTime (TGT) * - timeGetTime (TGT)
* similar to GetTickCount by default: 15msec, 50 day wrap. * similar to GetTickCount by default: 15msec, 50 day wrap.
* available in winmm.dll (thus known as the multimedia timers) * available in winmm.dll (thus known as the multimedia timers)
@ -2094,7 +2094,7 @@ g_get_monotonic_time (void)
* However this seems quite complicated, so we're not doing this right now. * However this seems quite complicated, so we're not doing this right now.
* *
* The approach we take instead is to use the TGT timer, extending it to 64bit * The approach we take instead is to use the TGT timer, extending it to 64bit
* either by using the GTC64 value, or if that is not availible, a process local * either by using the GTC64 value, or if that is not available, a process local
* time epoch that we increment when we detect a timer wrap (assumes that we read * time epoch that we increment when we detect a timer wrap (assumes that we read
* the time at least once every 50 days). * the time at least once every 50 days).
* *