Ты забыл тэг «хочется странного»

А если он их еще введёт, пока ты «узнаешь», — засегфолтаешься?

p.s. Или может есть wchar_t аналог getline()?

wcin.getline() ?

А если он их еще введёт, пока ты «узнаешь», — засегфолтаешься?

Нет, я просто извлеку столько сколько узнаю, а остальное следующий раз.

wcin.getline() ?

Ну это же не POSIX, и забыл сказать, у меня Си.

Или может есть wchar_t аналог getline()?

Вводить по одному символу через fgetwc() и управляться самому с памятью.

truct termios term;
	tcgetattr(1, &term);
	term.c_lflag &= ~(ICANON|ECHO);
	term.c_cc[VMIN] = 1;
	term.c_cc[VTIME] = 0;
tcsetattr(0,TCSANOW,&term);

Флаги указаны, чтобы не отображать вводимые символы, а так без этих флагов будет все нормально. Тогда, когда ты нажимаешь кнопку, она сразу же возвращается например в getch, так ты можешь считать сколько ввел пользователь символов, также, если нажат backspace, то уменшить на один счетчик. Когда нажимаешь enter, то производить то, что ввел пользователь. Флаги которые я привел в примере, отключают канонический режим, я уже не помню что это значит. Но вот я писал программу, и использовал там это. https://github.com/xverizex/rfcreader

А что тебе мешает, скажем, выделить буфер в 1024 символа, да заполнять его? Если вдруг больше будет введено, сделай realloc. Ну и считай после ввода. Всегда так и делали, чего велосипед изобретать?

Задача аналогична чтению из файла неизвестной длины?

Интересный способ.

Если пользователь введет 2048 символов то придется 1. выделять новый буфер, 2. копировать в него старые символы, 1026. удалять старый буфер. Но если заранее известен размер то всего этого ненужно делать. Пока всё это происходит, где нибудь на какой нибудь линии может произойти таймаут.

Ты вообще знаешь, как работает realloc?

Да, а ты?

Если немного символов, то можно читать и обратно засовывать при помощи ungetc(), но гарантируется только 1 успешное засовывание.

Нет, я просто извлеку столько сколько узнаю, а остальное следующий раз.

Чем это отличается от ситуации с фиксированным размером буфера? Перевыделять память всё равно придётся. Premature optimization не сделает код красивее.

Если пользователь введет 2048 символов то придется 1. выделять новый буфер, 2. копировать в него старые символы, 1026. удалять старый буфер. Но если заранее известен размер то всего этого ненужно делать. Пока всё это происходит, где нибудь на какой нибудь линии может произойти таймаут.

Какие страшные сказки, не имеющие к реальности никакого отношения.

а в чём проблема считать getline()ом и затем заюзать mbstowcs()?

Шелл 2017 год, цппшники спорють о том, сколько буферóв надо, чтобы текст из stdin считать.

Давно есть библиотеки, в которых много что написано. Можно почитать книгу «Язык С в XXI веке - Бен Клеменс»

%ms спасёт отца русской демократии.

Если пользователь введет 2048 символов то придется 1. выделять новый буфер, 2. копировать в него старые символы, 1026. удалять старый буфер

Да. Современный пользователь херачит слепым 21-пальцевым методом так, что никаких буферов не напасёшься.

Видимо все таки не знаешь, ибо реаллок ОЧЕНЬ РЕДКО выделяет новый буфер и копирует туда данные. Даже на хабре это разбирали. Ну и, само собой, увеличивать буффер после каждого выхода за размер нужно не на один элемент, а на несколько.

Да неужели, и с чего бы это? Ну раз так, тогда выполни у себя код и скажи потом с какой итерации он выскажет о тебе нелестное:

#include <stdio.h>
#include <wchar.h>
#include <locale.h>
#include <stdlib.h>

int main(int argc, char* argv[])
{   
    setlocale(LC_ALL, "");
#define ITRS    10
#define PORTION 256
    size_t i, room = PORTION;
    void* p = malloc(PORTION);
    void* pprev = p, * p_another;

    room = PORTION;

    for(i=0; i<ITRS; i++) {
        p_another = malloc(PORTION);
        p = realloc(p, (room+=PORTION));

        if( p != pprev ) {
            wprintf(L"(%u) Aswed - ламер.\n", i);
            pprev = p;
        }
    }
    return 0;
}

Ты еще скажи, что когда на диске к файлу что-то дописываешь, то модуль ФС создает новый файл бóльшего размера, копирует туда первоначальный + твое, а потом старый удаляет.

Угу, угу...

ФС это не оп. память. И если ей надо будет она всё что угодно сделает.

Хороший вариант.

Потому что цель - задействовать как можно меньше лишних операций.

Задача аналогична чтению из файла неизвестной длины?

Ну если нет минималистичных решений то скорее всего да. Но getline() возвращает же единый буфер, а вдруг он знает размер введенной строки, и если да, то почему и я не могу?

Нашёл исходник. Нет, такой приём как там я не могу использовать - непереносимо.

За слово «ламер» прошу извинить, был не в себе - ляпнул.

Но getline() возвращает же единый буфер, а вдруг он знает размер введенной строки, и если да, то почему и я не могу?

Потому что вы основ не понимаете. Что значит размер введенной строки? Сколько есть в ядерном буфере? Сколько есть в буфере read(2)? Сколько есть в буфере fgets(3)? Сколько возвратит getline? Это совсем разные размеры. Даже первый размер может быть разным, например по сети приходит, часть уже готовится для передачи в пользовательский процесс, так как его надо разбудить, а часть ещё вообще пока в текущем пакете TCP и лежит в буфере стека сети.

За слово «ламер» прошу извинить

Не обижаюсь.
Тем не менее, я потому и дал ссылку на статью, что изменение адреса массива != выделение нового и копирование, из-за игр с виртуальной памятью. Если, конечно, виртуальная память в системе поддерживается.

Что значит размер введенной строки?

Это тот размер который занимает строка в конце ввода которой пользователь нажал return и она отправилась в какой нибудь там буфер ввода вывода. У нее есть четкие границы - начало и символ новой строки.

getline() работает через realloc()

А ты не можешь, потому что лень написать код.

Ога, ога. Оперативка не фрагментируется. Что за чушь?

Не оперативка, а единый выделенный фрагмент памяти.