• src/uifc/uifc32.c

    From Deucе@VERT to Git commit to main/sbbs/master on Sun Nov 3 11:14:25 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/32fb9b77db11ec82231e4cee
    Modified Files:
    src/uifc/uifc32.c
    Log Message:
    More malloc() return checks

    ---
    ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net
  • From Deucе@VERT to Git commit to main/sbbs/master on Wed Nov 13 22:38:06 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/056304ed9e73c847a08102bb
    Modified Files:
    src/uifc/uifc32.c
    Log Message:
    Fix bug reported by DigitalMan

    It looks like this has been a long-standing UIFC bug (pre-3.0)

    If a uifc list that can scroll is showing the bottom-most line,
    and an option that is not the last is deleted, and both *cur and
    *bar are left untouched, *bar would be adjusted to be too high,
    resulting in various highlight bar corruption issues.

    This commit just rewrites that logic to be comprehensible, and
    ensures that if bar is set such that the list would end before the
    bottom of the window, it gets moved up. This makes delete do the
    right thing (didn't test with insert, that may do weird things).

    Also, since I figured out a good definition of what bar actually
    represtens, add a comment to that effect.

    ---
    ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net
  • From Deucе@VERT to Git commit to main/sbbs/master on Wed Nov 13 23:26:48 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/2e47ac987d5f1f1add45e5f7
    Modified Files:
    src/uifc/uifc32.c
    Log Message:
    Just overhaul this who chunk of code.

    ---
    ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net
  • From Deucе@VERT to Git commit to main/sbbs/master on Sat Jan 4 21:51:35 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/d63dd43c9b9a1cc24b268829
    Modified Files:
    src/uifc/uifc32.c
    Log Message:
    Prevent dereferencing NULL bar or cur with WIN_DYN

    This would be an API violation, but we shouldn't crash about it.

    ---
    ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Jan 9 18:53:52 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/935afe75ac88dd8094e58e71
    Modified Files:
    src/uifc/uifc32.c
    Log Message:
    Fix buffer overflow when upop() is called with a string > 73 chars

    result in segfault (e.g. adding long filenames using fileman.js)

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Jan 9 20:22:12 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/d55686a5ef0d1f9706d17b18
    Modified Files:
    src/uifc/uifc32.c
    Log Message:
    A more complete fix for the upop() issue with long strings

    Completely remove the 80 column screen width assumption/limit.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Tue Jan 14 17:42:18 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/ad84aa032681df2b5a7eb06d
    Modified Files:
    src/uifc/uifc32.c
    Log Message:
    Resolve MSVC warning

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deucе@VERT to Git commit to main/sbbs/master on Mon Feb 10 14:43:09 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/f55039de28c9dfc30450fec8
    Modified Files:
    src/uifc/uifc32.c
    Log Message:
    Only base drag-select highlight on the legacy attribute.

    The fg/bg values all have multiple representations, and some bits
    have extra meanings, so inequality there doesn't mean they're not
    the same colour.

    This fixes an issue where the *second* drag select on a screen
    would not highlight blue backgrounds correctly. The background
    colour gets the "pixels set" bit flown because of how
    restorescreen() works, which caused this to "know" it's not blue
    and use a blue background.

    A (good) argument could be made that savescreen()/restorescreen()
    shouldn't result in any changes, but since uifc32 doesn't directly
    use colours that aren't represented by legacy attributes, there's
    no need for it to get tricky here.

    ---
    ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net