Home/ Questions/Q 6595251
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T17:54:57+00:00

I wrote the following code: FILE *book; wchar_t bufferln[FILE_READ_BUFFER]; wchar_t buffer[FILE_READ_BUFFER]; book = fopen(file,

  • 0

I wrote the following code:

FILE *book;
wchar_t bufferln[FILE_READ_BUFFER];
wchar_t buffer[FILE_READ_BUFFER];
book = fopen(file, "r");
if(book == NULL){
    perror("Es ist ein Fehler beim lesen des Buches aufgetreten");
    return EXIT_FAILURE;
}
while(fgetws(buffer, FILE_READ_BUFFER, book) != NULL){
    if(wcscmp(buffer, L"\n") == 0){
        bufferln[0] = L'\0';
        continue;
    }
    buffer[wcsnlen(buffer, FILE_READ_BUFFER)-1] = L' ';
    wcsncat(bufferln, buffer, FILE_READ_BUFFER);
}
return EXIT_SUCCESS;

It crashes with SIGSEGV. I ran valgrind which shows the following:

==11251== Conditional jump or move depends on uninitialised value(s)
==11251==    at 0x40BD5CF: wcsncat (wcsncat.c:36)
==11251==    by 0x804865D: read_book (book.c:18)
==11251==    by 0x804872B: main (main.c:19)
==11251==  Uninitialised value was created by a stack allocation
==11251==    at 0x80485B7: read_book (book.c:3)
==11251== 
==11251== Invalid read of size 4
==11251==    at 0x40A58E2: fgetws (iofgetws.c:52)
==11251==    by 0x804867D: read_book (book.c:12)
==11251==    by 0x6D: ???
==11251==  Address 0x65 is not stack'd, malloc'd or (recently) free'd
==11251== 
==11251== 
==11251== Process terminating with default action of signal 11 (SIGSEGV)
==11251==  Access not within mapped region at address 0x65
==11251==    at 0x40A58E2: fgetws (iofgetws.c:52)
==11251==    by 0x804867D: read_book (book.c:12)
==11251==    by 0x6D: ???
==11251==  If you believe this happened as a result of a stack
==11251==  overflow in your program's main thread (unlikely but
==11251==  possible), you can try to increase the size of the
==11251==  main thread stack using the --main-stacksize= flag.
==11251==  The main thread stack size used in this run was 8388608.

I think the problem is somehow related to my usage of wcsncat (writing into *book memory maybe?) but why?
I want to read a document (UTF-8) paragraph by paragraph and then do stuff that is not in this code yet.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What could be happening is that your wcsncat() which as per documentation does :

    ”
    DESCRIPTION
    The wcsncat() function appends no more than the first n characters of the string pointed to by ws2 to the end of the string pointed to by ws1. If a NULL character appears in ws2 before n characters, all characters up to the NULL character are appended to ws1. The first character of ws2 overwrites the terminating NULL character of ws1. A NULL terminating character is always appended to the result, and if the objects used for copying overlap, the behavior is undefined.
    “

    So it keeps appending to bufferln starting by overwriting the first occurence of NULL character. So in cases where if(wcscmp(buffer, L”\n”) == 0) returns FALSE you will end up overrunning your allocated buffer of FILE_READ_BUFFER and spill the file outside the bufferln boundary and possibly end up corrupting the stack.

    In most cases stacks grow downwards and it must have reached some regions which actually FAULT because accessing the first 2 pages of your virtual address pages is not allowed on most systems. This is a moot point as to why it faulted there. But the main reason is that you have to try write the data somewhere once you have read it as your read and write buffers are of the same length.

    HTH

    • 0