Can you verify if this is still an issue? Using this test code, it seems that default adjustments are created.

#include <assert.h>
#include <gtk/gtk.h>
int main (int argc, char *argv[])
{
    gtk_init (&argc, &argv);
    GtkScrolledWindow *sw = gtk_scrolled_window_new (NULL, NULL);
    assert (gtk_scrolled_window_get_hadjustment (sw) &&
            gtk_scrolled_window_get_vadjustment (sw));
}

(In reply to comment #1)
> Can you verify if this is still an issue? Using this test code, it seems that
> default adjustments are created.
> 
> #include <assert.h>
> #include <gtk/gtk.h>
> int main (int argc, char *argv[])
> {
>     gtk_init (&argc, &argv);
>     GtkScrolledWindow *sw = gtk_scrolled_window_new (NULL, NULL);
>     assert (gtk_scrolled_window_get_hadjustment (sw) &&
>             gtk_scrolled_window_get_vadjustment (sw));
> }

This test case doesn't fail because the gtk_scrolled_window_get_hadjustment() and gtk_scrolled_window_get_vadjustment() called trigger the creation of the adjustments (through gtk_range_get_adjustment() calls). This means that gtk_scrolled_window_new () doesn't actually create the adjustments. 

This might be a problem is some developer creates a scrolled window and tries to directly the struct attributes "hscrollbar" and "vscrollbar" (which is not rare) expecting them to have actual adjustment instances.

If all GTK+ structs were properly sealed, this wouldn't be a problem. But this is not the case just yet...  

Now I do not understand, because this test case doesn't fail either:

  #include <assert.h>
  #include <gtk/gtk.h>
  int main (int argc, char *argv[])
  {
      gtk_init (&argc, &argv);
      GtkScrolledWindow *sw =
          GTK_SCROLLED_WINDOW (gtk_scrolled_window_new (NULL, NULL));
      GtkRange *hrange = GTK_RANGE (sw->hscrollbar);
      GtkRange *vrange = GTK_RANGE (sw->vscrollbar);
      assert (GTK_IS_ADJUSTMENT (hrange->adjustment));
      assert (GTK_IS_ADJUSTMENT (vrange->adjustment));
  }

It really seems to me that the API doc is correct in this case.

Closing as obsolete. Please reopen if you disagree.