News:

Download Pelles C here: http://www.pellesc.se

Main Menu

Recent posts

#71
Beginner questions / Re: Working Directory woes
Last post by PhilG57 - August 31, 2026, 10:15:33 PM
Finally figured this out: the problem was me.  In my attempt to leave nothing to chance, I screwed up the OPENFILENAME structure by specifying numerous parameters to it.  Now, I just obtain and insert into "lpstrInitialDir" my working directory (along with a couple fields defining where results should be placed) and GetOpenFileName works well.

What a mess; maybe the administrator can just delete this whole embarrassing thread...
Thanks.
 
#72
Bug reports / Re: optimiser emits ud2 (inval...
Last post by Michele - August 31, 2026, 12:52:04 PM
The instruction UD2 should have been designed specifically for testing.
Perhaps this is a typo from the compiler testing phase.
#73
Bug reports / Re: optimiser emits ud2 (inval...
Last post by TimoVJL - August 31, 2026, 11:50:09 AM
A smaller test:
//#include <stdio.h>
int __cdecl printf(const char * restrict format, ...);
int __cdecl main(void)
{
    int i;
    unsigned char data[200];
    for (i = 0; i < 200; i += 1) {     /* the suspect loop, verbatim    */
        data[i] = (unsigned char)(i % 256);
    }
    for (i = 0; i < 200; i++)
        printf("%i ", data[i]);
    return 0;
}
test_loop.c(8): warning #2803: Attempt to divide by zero.
#74
Bug reports / optimiser emits ud2 (invalid-o...
Last post by KEL26 - August 30, 2026, 11:09:48 PM

Hello Pelle,

First, thank you for Pelles C — it has just carried a full port of CFITSIO
4.7.0 (NASA's FITS library, 59 sources), zlib, libpng and FFTW 3.3.11 to a
clean finish, so the report below comes from a codebase your compiler
otherwise handles admirably.

SUMMARY
-------
Pelles C 14.50.0 for Windows x64, compiling the attached self-contained
program (about one screen of code), translates the loop

    for (i = 0; i < 200; i += 1) {
        data[i] = (unsigned char)(i % 256);
    }

(over a local  unsigned char data[200])  into a loop body whose FIRST
instruction is  ud2 , so the program dies with exception 0xC000001D on the
first iteration. The store that follows the trap reads  al , which no
instruction in the function ever writes — the value computation has been
deleted entirely. The statement is fully defined ISO C: i is in [0,200),
so i % 256 is well defined and non-negative, the conversion to unsigned
char is well defined, and the store is in bounds.

ENVIRONMENT
-----------
    Pelles C 14.50.0, Windows 10 x64 (build 19045)
    pocc -Tx64-coff -Ot -W1 -std:C17 -Ze pelle_repro.c
    polink -machine:x64 -subsystem:console pelle_repro.obj kernel32.lib

OBSERVED (same source, three settings)
--------------------------------------
    -Ot          RESULT : EXCEPTION 0xC000001D
    -Os          RESULT : EXCEPTION 0xC000001D
    (no -O...)   RESULT : SURVIVED   checksum 19900 (expect 19900)

DISASSEMBLY (podump /disasm of the -Ot object, the loop in full)
----------------------------------------------------------------
    [0050] 0F0B            ud2
    [0052] 4863D3          movsxd  rdx,ebx
    [0055] 888414EC000000  mov     byte ptr [rsp+rdx+0ECh],al
    [005C] 83C301          add     ebx,1
    [005F] 81FBC8000000    cmp     ebx,0C8h
    [0065] 7CE9            jl      0050

NOTES THAT MAY HELP LOCATE IT
-----------------------------
1. The mistranslation is sensitive to the surrounding frame: the identical
   loop in a different function (static buffer, checksum in a separate
   loop) compiles correctly at -Ot on the same machine. The attached
   reproducer therefore keeps the exact frame of the function in which the
   fault was first observed — the same locals in the same order, and calls
   through a volatile function pointer where the original code called into
   a library. Simplifying the frame may make the fault vanish.
2. The pattern (unsigned char)(expr % 256) appears in a dozen other files
   of the same project that compile correctly, consistent with note 1.
3. Discovered because a unit test of the CFITSIO port died with
   "CRT: unhandled exception" before its first library call; an
   __try/__except wrapper reported 0xC000001D, and podump named the ud2.

A SECOND, UNRELATED ISSUE, MENTIONED FOR COMPLETENESS
-----------------------------------------------------
The same project also hit what the evidence indicates is a stack-slot
assignment fault at -Ot in one large function of CFITSIO's imcompress.c:
two live locals (a 4-byte char array, address escaping through a pointer
array, and a 12-byte char array) appear to have shared storage, so a
12-byte strcpy destroyed the 4-byte string; rearranging the locals into
one union cured it. An isolated replica of the declarations does NOT
reproduce it — the full function seems to be needed — so I am not
attaching that one until it has a reproducer worth your time. I can supply
the full analysis on request.

With thanks and best regards,
Kelly
Attachment: pelle_repro.c
#75
Assembly discussions / Re: Find characters inside a s...
Last post by TimoVJL - August 30, 2026, 10:13:35 AM
An interesting code.
Erol, can you add a comments to that code too, so it explain register usage for bytes better.
#76
Expert questions / Re: _readdir() translates some...
Last post by TimoVJL - August 30, 2026, 10:10:24 AM
As linux support UTF-8 in it functions, it handle internet data and files well.
MS Windows and msvc have a some support for it too, codepage 65001 ?

An universal code needs special (POSIX ?) code / libraries that supports UTF-8 for MS Windows.

UTF-8 functions are naturally slower than pure ANSI / UNICODE versions.
#77
Assembly discussions / Re: Find characters inside a s...
Last post by Vortex - August 27, 2026, 01:16:02 PM
Function determining the extension of a file. FindExt is based on FindChar.

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

FindExt PROC src:DWORD

    mov     eax,DWORD PTR [esp+4]
    dec     eax
    mov     cl,'.'
@@:
    inc     eax
    mov     dl,BYTE PTR [eax]
    test    dl,dl
    setz    dh
    xor     dl,cl
    setz    ch
    or      ch,dh
    jz      @b
    retn    4

FindExt ENDP

OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef
#78
Expert questions / Re: _readdir() translates some...
Last post by John Z - August 27, 2026, 09:02:17 AM
Hi,

Well here is Mr. Sanders brief:
"The libdirtrav library provides a way to recursively read folder contents using callback functions. This is done using opendir() and readdir() functions, except for Windows where native FindFirstFile()/FindFirstFileEx() and FindNextFile() functions are used. On Windows a wide version is available which uses wchar_t* as string type for Unicode UTF-16 support"

So one sees he also recommends FindFirst etc for windows.

There are two issues 1) codepages being used for Filenames  2) codepages being used within a program or data.  #1 is most difficult to handle as you pointed out it is possible in windows which uses UTF-16 to have many different languages for filenames .  #2 is not so hard.  Most legacy programs or data files have some identifier to inform about the codepage.  VCF contact files for example before VCF 3 used CHARSET=  some name (not always standardized).  VCF3 pushed UTF-8 as a recommendation and VCF4 requires it.

Handling codepage changes within a program is not difficult.  In most cases the end user will be able to see the information is weird so can change the codepage and re-read the data.  An example dialog from my vCardz_i program for vcf contact cards for changing the code page as needed.  Data is read in as binary and and converted from the codepage into UTF-8 or UTF-16 to display.  If looks bogus another codepage can be selected, tedious to be sure and hopefully not often needed. 

John Z
#79
Expert questions / Re: _readdir() translates some...
Last post by Robert - August 27, 2026, 01:47:01 AM
Brecht Sanders has a cross-platform library specific to readdir.

https://github.com/brechtsanders/libdirtrav

Warning! I have not tried using it, so I have no idea if it will work with Pelles C.

CodePages ?
The example file, "Art of Beksiński 1978 (MHS) (2).jpg", includes Polish characters. What if the next file is "Miró's L'escala de l'evasió.jpg"? How could you know that the filename is Spanish? And even if your app could figure that out, how could you switch codepages within the app?

#80
Expert questions / Re: _readdir() translates some...
Last post by John Z - August 26, 2026, 09:34:41 PM
Hi,

You've not mentioned whether coding for DOS or Windows, Linux?
These non-std functions were provide to improve portability according to the help file.

Windows filenames are all in Unicode UTF-16.  However AFAIK all OS files are ASCII and ASCII is supported intact within the lower UTF-16 codes, so 98% of the files on the system can be opened without using wide.  The other 2% are user files which can be using any character in the UTF-16 set, which includes all (well almost all) characters sets in the world. A swag as the percentages but you get the gist.

IMO, you are better off using _wfindfirst64,  and associated functions, then you are covered for all language nuances.

Otherwise codepages are not hard to use, the hard part is figuring out which one to activate.... :(

John Z