Beta "hmt" source code

[prpr]

see https://github.com/hummypkg/hmt for the source

for providing it.
it doesn't compile (either on the Humax or on my Linux box).

Having tweaked a few things, it now builds cleanly on both.
Patch attached.

I won't comment at this point about using %d with unsigned variables...

 

[EEPhil]

I won't comment at this point about using %d with unsigned variables...

You just did.

 

[prpr]

Thanks @af123 From the looks of it, it should be possible to build a Windows version from that source which requires no additional depencies.

Further portability tweaks, and I now have a version that builds on Humax, Linux, and Windows (Visual Studio).
There was also a nasty buffer overwrite bug.
I'll update the patch diff shortly... done.

Oh and @prpr, point taken, I'll make sure my images are more user friendly in future!

Thanks!

 

[prpr]

I'll update the patch diff shortly... done.

And again, to fix the spelling errors in two instances of "preceeded".

 

[af123]

There was also a nasty buffer overwrite bug.

I assume that ctime() returns more characters on Windows then? The strcpy() needs adjusting regardless, thanks.
A lot of these casts look unnecessary to me, are you adding them because a toolchain is producing warnings and if so, which one?

And again, to fix the spelling errors in two instances of "preceeded".

Oops, the second must be a copy and paste error but I can't explain how the first slipped by.

 

[af123]

it doesn't compile (either on the Humax or on my Linux box).

Interesting - obviously it builds for me on the Humax but I just tried it on Debian and it built fine without changes
(there were format warnings, but it built)

 

[prpr]

I assume that ctime() returns more characters on Windows then?

It returns e.g. "Sat Dec 29 19:00:00 2018\n" which is 26 characters including the null. Your buffer was 25. I like round numbers, so made it 32.
I don't like static buffers like that anyway as a design principle - it leads to nasty things when you multi-thread.

The strcpy() needs adjusting regardless, thanks.

The rest of those tweaks were because time_t is 64 bit by default on VS2013 and passing in a pointer to a 32 bit number made ctime() return null, which obviously stuffs strcpy(). The way I did it will make it work on either 32 or 64 bit time_t.
I could go on about strcpy() and strcat() and such like regarding unchecked buffer lengths as well, but I won't. I just turned off the warning on VS on this occasion.

A lot of these casts look unnecessary to me, are you adding them because a toolchain is producing warnings and if so, which one?

It depends on how you approach these things really. Assigning a 32 bit variable to a 16 bit variable (say), quite rightly in my book, should produce a warning about potential data truncation (with the warning level set high enough - and I always turn it up from the default). It is good practice to use a cast to tell whoever is reading the code that you really meant to do this, rather than just turning the warning off and letting the compiler do it anyway.
VS moaned about it. It really does make you think more carefully about these things and is a good thing. I've fixed loads of weird behaviour and horrid bugs in things over the years by paying attention to this stuff.
I'm not generally much of a Microsoft fan, but I really like modern versions of Visual Studio and it's changed my programming life since I upgraded from VC6 and C to VS2010 and C++. This is why I like portable code too, as I can write stuff for Linux in it. I can't bear to work the old way now (old C code and text editor for source). It's just too dull and error prone.

 

[prpr]

Interesting - obviously it builds for me on the Humax

The big thing was that "inline" stuff. I'll get you the build output in a bit.
Sorry to harp on about it, but warnings are there to be fixed, not to be ignored. If only all programmers would learn this, there would be lots fewer problems in everything.

 

[af123]

Thanks for the comments, I've updated the github repository now. I preferred to put the windows specific bits in lint.h and it still builds fine on the Humax and Linux but I have not tested Windows. I also added in a missing commit for the +/-thumbnails command.

 

[prpr]

it still builds fine on the Humax and Linux but I have not tested Windows

It's now moaning about these superfluous include files:
------ Build started: Project: hmt, Configuration: Debug Win32 ------
util.c
c:\humax\hmt\util.c(12): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory
main.c
c:\humax\hmt\hmt.h(2): fatal error C1083: Cannot open include file: 'sys/param.h': No such file or directory
hmt.c
c:\humax\hmt\hmt.c(8): fatal error C1083: Cannot open include file: 'strings.h': No such file or directory
file.c
c:\humax\hmt\hmt.h(2): fatal error C1083: Cannot open include file: 'sys/param.h': No such file or directory
display.c
c:\humax\hmt\hmt.h(2): fatal error C1083: Cannot open include file: 'sys/param.h': No such file or directory
cmd.c
c:\humax\hmt\hmt.h(2): fatal error C1083: Cannot open include file: 'sys/param.h': No such file or directory

And MAXPATHLEN isn't defined in hmt.h either now.

And this, to illustrate a previous comment:
c:\humax\hmt\cmd.c(344): warning C4244: 'function' : conversion from 'uint32_t' to 'uint8_t', possible loss of data
c:\humax\hmt\cmd.c(347): warning C4244: 'function' : conversion from 'uint32_t' to 'uint16_t', possible loss of data

 

[prpr]

Added a file "portable.h"containing:

#ifdef _WIN32
#include <io.h>
#include <windows.h>

#define MAXPATHLEN MAX_PATH
#define open(a,b,c) _open(a,b,c)
#define close(a) _close(a)
#define read(a,b,c) _read(a,b,c)
#define write(a,b,c) _write(a,b,c)
#define lseek(a,b,c) _lseek(a,b,c)
#define MAP_FAILED 0
#define mmap(a,b,c,d,e,f) MAP_FAILED
#define munmap(a,b)
#define strncasecmp _strnicmp

typedef long off_t;

#else /* _WIN32 */

#include <sys/mman.h>
#include <sys/param.h>
#include <strings.h>
#include <unistd.h>

#endif /* _WIN32 */

See the attached diff for the changes to match.

 

[florca]

Just built this cleanly for a Pi4B (Raspbian Lite) and working fine (thanks..), but worth noting that the source has vanished from the github link above - tracked it down to:

https://git.hpkg.tv/hummypkg/hmt/

 

[MymsMan]

Just built this cleanly for a Pi4B (Raspbian Lite) and working fine (thanks..), but worth noting that the source has vanished from the github link above - tracked it down to:

https://git.hpkg.tv/hummypkg/hmt/

Glad you found it - Humax packages are gradually being migrated to our own git host repository