Портировал я давеча один непутевый код с SUN на Linux

  int a;
  ...
  a = 1;
  a = 1;

КВА>

close(fd);
fd = -1;

if (f)
{
    fclose(f);
    f = NULL;
}

int *a = 0xdeadbeaf;
*a = 17;

*** glibc detected *** double free or corruption (top): 0x0804a008 ***

The behaviour of fclose() is undefined if the stream parameter is an
illegal pointer, or is a descriptor already passed to a previous invo-
cation of fclose().

ERRORS
EBADF The file descriptor underlying fp is not valid.

The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.

NAME
fclose — close a stream
...

DESCRIPTION
...
[CX] [Option Start] The fclose() function shall mark for update the st_ctime and st_mtime fields of the underlying file, if the stream was writable, and if buffered data remains that has not yet been written to the file. The fclose() function shall perform the equivalent of a close() on the file descriptor that is associated with the stream pointed to by stream. [Option End]
...
After the call to fclose(), any use of stream results in undefined behavior.

The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.

NAME
close — close a file descriptor
DESCRIPTION
The close() function shall deallocate the file descriptor indicated by fildes. To deallocate means to make the file descriptor available for return by subsequent calls to open() or other functions that allocate file descriptors. All outstanding record locks owned by the process on the file associated with the file descriptor shall be removed (that is, unlocked).
...

When all file descriptors associated with an open file description have been closed, the open file description shall be freed.
...

Prior list-based lock-free set algorithms involve one or more
serious problems: dependence on the DCAS (double-compareand-
swap)1 atomic primitive that is not supported on any
current processor architecture [5, 14], susceptibility to livelock
[25], and/or dependence on problematic memory management
methods [6, 14, 25] (i.e., memory management methods
that are impractical, very inefficient, blocking (not lockfree),
and/or dependent on special operating system support).
The use of universal lock-free methodologies [1, 2, 8, 11,
22, 24] for implementing hash tables or sets in general is too
inefficient to be practical.
This paper presents a lock-free list-based set algorithm that
we use as a building block of a lock-free hash table algorithm.
The algorithm is dynamic, allowing the object size
and memory use to grow and shrink arbitrarily. It satisfies
the linearizability correctness condition [9].
It uses CAS (compare-and-swap) or equivalently restricted
LL/SC (load-linked/store-conditional)

if(fclose(file) == EOF) log("what the f...?");

A>if(fclose(file) == EOF) log("what the f...?");
A>

A>Ты сперва придумываешь за меня что-то, а потом доблесно с этим сражаешься. Зачем?

int
my_fclose(FILE *file)
{
    if (!is_valid_file(file)) {
        log("Attempt to close closed file");
        return(EBADF);
    }

    delete_from_valid_files(file);

    return fclose(file);
}

FILE *
my_fopen(const char *path, const char *mode)
{
    FILE *file;
    if ((file = fopen(path, mode)) != NULL) {
        add_valid_file(file);
        return file;
    }

    return NULL;
}

В высшей степени странное утверждение! Функция glibc fclose соответствует стандарту ANSI C, и в манах черным по белому написано, что ее поведение не определено в случае передачи ей инвалидного указателя (что, кстати, полностью соответствует стандарту).

Вообще непонятно, как ты хочешь обрабатывать передачу инвалидного УКАЗАТЕЛЯ функции, на нем что написано, что он кривой.

A>Повторюсь специально для тебя. fclose удаляет указатель из списка валидных. Зачем хранить 1000000 значений указателей для УЖЕ ЗАКРЫТЫХ файлов я не очень понимаю.

f1 = fopen();
f2 = f1;
fclose(f1);
f1 = fopen(); // Допустим второй вызов fopen вернёт тот же указатель, что и первый вызов. Почему бы и нет?
fclose(f2); // Здесь не сломается,
fclose(f1); // а вот здесь сломается, хотя после всех "улучшательств" должно быть наоборот.

E>f1 = fopen();
E>f2 = f1;
E>fclose(f1);
E>f1 = fopen(); // Допустим второй вызов fopen вернёт тот же указатель, что и первый вызов. Почему бы и нет?
E>fclose(f2); // Здесь не сломается,
E>fclose(f1); // а вот здесь сломается, хотя после всех "улучшательств" должно быть наоборот.
E>

// Начало работы. Список открытых файлов пуст.

f1 = fopen();
// f1 == 0x00100000, в списке (0x00100000)

f2 = f1;
// f1 == 0x00100000, f2 == 0x00100000, в списке (0x00100000)

fclose(f1);
// f1 == 0x00100000, f2 == 0x00100000, в списке ()

f1 = fopen(); // Допустим второй вызов fopen вернёт тот же указатель, что и первый вызов. Почему бы и нет?
// f1 == 0x00100000, f2 == 0x00100000, в списке (0x00100000)

fclose(f2); // Здесь не сломается,
// f1 == 0x00100000, f2 == 0x00100000, в списке ()

fclose(f1); // а вот здесь сломается, хотя после всех "улучшательств" должно быть наоборот.
// f1 == 0x00100000, f2 == 0x00100000, в списке (), указатель переданный в fclose отсутсвует в списке - ошибка распознана.

f1 = fopen();
f2 = f1;
fclose(f1);

f3 = fopen();
fclose(f2);
fclose(f3);