2023-12-20 14:22 UTC-0500 Ron Pinkas <ronpinkas/AT/gmail/com>
* .gitignore
+ *.json
+ contrib/hbhpdf/tests/.gitignore
+ New for this dir
+ *.c

* bin/bld_vc.bat
+ Added detection of VS2022
+ Added assignment of respective __MSC__ version

* make_vc.bat
+ Added assignment of respective __MSC__ version

* bin/bld.bat
+ Added logic to default HB_INSTALL HB_BIN_INSTALL HB_LIB_INSTTALL and HB_INC_INSTALL
based on the directory from which bld.bat was loaded.
- Removed explicit HB_LIB_INSTALL for each library in MSVC section
+ Added /LIBPATH=%HB_LIB_INSTALL% to LDFLAGS in MSVC secttion
+ Added libharu.lib hbhpdf.lib and png.lib to default libraries (if exist) in MSVC section
+ Added enclosing "" around %HB_INC_INSTALL% in -I switch in MSVC section

* winmake/common.mak
+ Added hpdf_direct and hpdf_shading to LIBHARU_LIB_OBJS
* winmake/makefile.vc
+ Added CC_CMD_HARU
* winmake/compile.mak
+ Added hpdf_direct and hpdf_shading to HBHPDF.LIB dependencies
* Changed HBHPDF.LIB dependencies to use CC_CMD_HARU instead of CC_CMD
to use C compilattion instead of C++
* winmake/msvcerr.vc
+ Added messages for __MSC__ 16 and 17

Ron Pinkas wrote:
>
> 2023-12-20 14:22 UTC-0500 Ron Pinkas <ronpinkas/AT/gmail/com>
> * .gitignore
> + *.json
> + contrib/hbhpdf/tests/.gitignore
> + New for this dir
> + *.c
>
> * bin/bld_vc.bat
> + Added detection of VS2022
> + Added assignment of respective __MSC__ version
>
> * make_vc.bat
> + Added assignment of respective __MSC__ version
>
> * bin/bld.bat
> + Added logic to default HB_INSTALL HB_BIN_INSTALL HB_LIB_INSTTALL and HB_INC_INSTALL
> based on the directory from which bld.bat was loaded.
> - Removed explicit HB_LIB_INSTALL for each library in MSVC section
> + Added /LIBPATH=%HB_LIB_INSTALL% to LDFLAGS in MSVC secttion
> + Added libharu.lib hbhpdf.lib and png.lib to default libraries (if exist) in MSVC section
> + Added enclosing "" around %HB_INC_INSTALL% in -I switch in MSVC section
>
> * winmake/common.mak
> + Added hpdf_direct and hpdf_shading to LIBHARU_LIB_OBJS
> * winmake/makefile.vc
> + Added CC_CMD_HARU
> * winmake/compile.mak
> + Added hpdf_direct and hpdf_shading to HBHPDF.LIB dependencies
> * Changed HBHPDF.LIB dependencies to use CC_CMD_HARU instead of CC_CMD
> to use C compilattion instead of C++
> * winmake/msvcerr.vc
> + Added messages for __MSC__ 16 and 17

Enrico,

I ended up "fixing" the MSVC build of libharu by simply forcing C mode
instead of C++ compilation (no -TP switch).

We can use same solution for any other compiler which compies in C++
mode and thus produces errors in void pointers which shoulld be
typed pointers.

Now I need your help with BCC - there are mulltiple different issues
to understand.

1. Some/Most BCC versions are not C99 compliant and thus produce error
on code like this:

for (HPDF_UINT32 i = 0; i < prec; i++) {
fpart_val = modff(fpart_val*10.0, &int_val);
*s++ = (char)(int_val + 0.5) + '0';
}

C Compiler need to support declaration of variable in the loop
initialization.

C99 also added modff()

You told me that you use latest BCC and yet spoke about modff() missing
but this does not make sense since current standard math.h header must
have modff(). So we need to better review and understand BCC versions.

2. Errors on incompatible pointers. This happens due to C++ compilation
and you can fix it by ssimply switching to C compilattion.

Ron

Il 20/12/2023 21:06, Ron Pinkas ha scritto:

> Enrico,
>
> I ended up "fixing" the MSVC build of libharu by simply forcing C mode
> instead of C++ compilation (no -TP switch).
> [...]

Tomorrow I will look at this message of yours carefully. Many thanks!

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

Il 20/12/2023 21:06, Ron Pinkas ha scritto:

> I ended up "fixing" the MSVC build of libharu by simply forcing C mode
> instead of C++ compilation (no -TP switch).

Great idea! I vaguely thought about that solution but I did not apply
it. Thank you!

Now an important (at least for me) question: we have to leave all the
contribs alone or only hbhpdf? Can I continue to fix warnings in the
contrib directory or not? Please clarify.

There are still warnings for hbhpdf:

contrib\hbhpdf\hpdf_utils.c(223): warning C4244: 'function': conversion
from 'double' to 'float', possible loss of data
contrib\hbhpdf\hpdf_utils.c(236): warning C4244: 'function': conversion
from 'double' to 'float', possible loss of data

contrib\hbhpdf\hpdf_encoder.c(2766): warning C4244: 'initializing':
conversion from 'HPDF_UINT16' to 'HPDF_BYTE', possible loss of data

contrib\hbhpdf\hpdf_fontdef_tt.c(2070): warning C4389: '==':
signed/unsigned mismatch
contrib\hbhpdf\hpdf_fontdef_tt.c(2076): warning C4244: 'function':
conversion from 'HPDF_UINT32' to 'HPDF_UINT16', possible loss of data
contrib\hbhpdf\hpdf_fontdef_tt.c(2077): warning C4244: 'function':
conversion from 'HPDF_UINT32' to 'HPDF_INT16', possible loss of data
contrib\hbhpdf\hpdf_fontdef_tt.c(2087): warning C4244: 'function':
conversion from 'HPDF_UINT32' to 'HPDF_INT16', possible loss of data

contrib\hbhpdf\hpdf_font_cid.c(411): warning C4244: 'initializing':
conversion from 'HPDF_UINT' to 'HPDF_UNICODE', possible loss of data

contrib\hbhpdf\hpdf_gstate.c(73): warning C4244: 'initializing':
conversion from 'float' to 'HPDF_UINT', possible loss of data

contrib\hbhpdf\hpdf_pages.c(1192): warning C4244: 'initializing':
conversion from 'float' to 'HPDF_UINT', possible loss of data

contrib\hbhpdf\hpdf_page_operator.c(24): warning C4244: 'initializing':
conversion from 'float' to 'HPDF_UINT', possible loss of data
contrib\hbhpdf\hpdf_page_operator.c(198): warning C4244: 'function':
conversion from 'HPDF_REAL' to 'HPDF_STATUS', possible loss of data
contrib\hbhpdf\hpdf_page_operator.c(202): warning C4244: 'function':
conversion from 'HPDF_REAL' to 'HPDF_STATUS', possible loss of data
contrib\hbhpdf\hpdf_page_operator.c(1189): warning C4244: 'function':
conversion from 'HPDF_REAL' to 'HPDF_STATUS', possible loss of data

contrib\hbhpdf\hpdf_image.c(202): warning C4456: declaration of 'ret'
hides previous local declaration
contrib\hbhpdf\hpdf_image.c(176): note: see declaration of 'ret'

contrib\hbhpdf\hpdf_image_png.c(351): warning C4018: '<':
signed/unsigned mismatch

contrib\hbhpdf\hpdf_pdfa.c(154): warning C4189: 'info': local variable
is initialized but not referenced

contrib\hbhpdf\hpdf_encoder_utf.c(172): warning C4244: 'return':
conversion from 'unsigned int' to 'HPDF_UNICODE', possible loss of data
contrib\hbhpdf\hpdf_encoder_utf.c(133): warning C4100: 'code':
unreferenced formal parameter

contrib\hbhpdf\hpdf_image_ccitt.c(410) : warning C4706: assignment
within conditional expression
contrib\hbhpdf\hpdf_image_ccitt.c(469) : warning C4706: assignment
within conditional expression

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

Il 21/12/2023 11:28, Enrico Maria Giordano ha scritto:

> There are still warnings for hbhpdf:

Do I have suppress them using compiler switches like -wdxxx in my build
batch? Let me know.

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

Il 20/12/2023 21:06, Ron Pinkas ha scritto:

> 1. Some/Most BCC versions are not C99 compliant and thus produce error
> on code like this:
>
> for (HPDF_UINT32 i = 0; i < prec; i++) {
> fpart_val = modff(fpart_val*10.0, &int_val);
> *s++ = (char)(int_val + 0.5) + '0';
> }
>
> C Compiler need to support declaration of variable in the loop
> initialization.
>
> C99 also added modff()
>
> You told me that you use latest BCC and yet spoke about modff() missing
> but this does not make sense since current standard math.h header must
> have modff(). So we need to better review and understand BCC versions.

If those are the requirements then we have no other choices than
dropping support for bcc32.exe and forcing use of bcc32c.exe. But I
don't think we have to do that. I just built xHarbour for BCC32 using
bcc32.exe and found no errors and no warnings (using only -w-prc
-w-use). So what's the problem?

> 2. Errors on incompatible pointers. This happens due to C++ compilation
> and you can fix it by ssimply switching to C compilattion.

Ok, I will keep it in mind for the future.

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

Enrico Maria Giordano wrote:
>
>
> Il 20/12/2023 21:06, Ron Pinkas ha scritto:
>
> > I ended up "fixing" the MSVC build of libharu by simply forcing C mode
> > instead of C++ compilation (no -TP switch).
>
> Great idea! I vaguely thought about that solution but I did not apply
> it. Thank you!
>
> Now an important (at least for me) question: we have to leave all the
> contribs alone or only hbhpdf? Can I continue to fix warnings in the
> contrib directory or not? Please clarify.
>
> There are still warnings for hbhpdf:
>
> contrib\hbhpdf\hpdf_utils.c(223): warning C4244: 'function': conversion
> from 'double' to 'float', possible loss of data
> contrib\hbhpdf\hpdf_utils.c(236): warning C4244: 'function': conversion
> from 'double' to 'float', possible loss of data
>
> contrib\hbhpdf\hpdf_encoder.c(2766): warning C4244: 'initializing':
> conversion from 'HPDF_UINT16' to 'HPDF_BYTE', possible loss of data
>
> contrib\hbhpdf\hpdf_fontdef_tt.c(2070): warning C4389: '==':
> signed/unsigned mismatch
> contrib\hbhpdf\hpdf_fontdef_tt.c(2076): warning C4244: 'function':
> conversion from 'HPDF_UINT32' to 'HPDF_UINT16', possible loss of data
> contrib\hbhpdf\hpdf_fontdef_tt.c(2077): warning C4244: 'function':
> conversion from 'HPDF_UINT32' to 'HPDF_INT16', possible loss of data
> contrib\hbhpdf\hpdf_fontdef_tt.c(2087): warning C4244: 'function':
> conversion from 'HPDF_UINT32' to 'HPDF_INT16', possible loss of data
>
> contrib\hbhpdf\hpdf_font_cid.c(411): warning C4244: 'initializing':
> conversion from 'HPDF_UINT' to 'HPDF_UNICODE', possible loss of data
>
> contrib\hbhpdf\hpdf_gstate.c(73): warning C4244: 'initializing':
> conversion from 'float' to 'HPDF_UINT', possible loss of data
>
> contrib\hbhpdf\hpdf_pages.c(1192): warning C4244: 'initializing':
> conversion from 'float' to 'HPDF_UINT', possible loss of data
>
> contrib\hbhpdf\hpdf_page_operator.c(24): warning C4244: 'initializing':
> conversion from 'float' to 'HPDF_UINT', possible loss of data
> contrib\hbhpdf\hpdf_page_operator.c(198): warning C4244: 'function':
> conversion from 'HPDF_REAL' to 'HPDF_STATUS', possible loss of data
> contrib\hbhpdf\hpdf_page_operator.c(202): warning C4244: 'function':
> conversion from 'HPDF_REAL' to 'HPDF_STATUS', possible loss of data
> contrib\hbhpdf\hpdf_page_operator.c(1189): warning C4244: 'function':
> conversion from 'HPDF_REAL' to 'HPDF_STATUS', possible loss of data
>
> contrib\hbhpdf\hpdf_image.c(202): warning C4456: declaration of 'ret'
> hides previous local declaration
> contrib\hbhpdf\hpdf_image.c(176): note: see declaration of 'ret'
>
> contrib\hbhpdf\hpdf_image_png.c(351): warning C4018: '<':
> signed/unsigned mismatch
>
> contrib\hbhpdf\hpdf_pdfa.c(154): warning C4189: 'info': local variable
> is initialized but not referenced
>
> contrib\hbhpdf\hpdf_encoder_utf.c(172): warning C4244: 'return':
> conversion from 'unsigned int' to 'HPDF_UNICODE', possible loss of data
> contrib\hbhpdf\hpdf_encoder_utf.c(133): warning C4100: 'code':
> unreferenced formal parameter
>
> contrib\hbhpdf\hpdf_image_ccitt.c(410) : warning C4706: assignment
> within conditional expression
> contrib\hbhpdf\hpdf_image_ccitt.c(469) : warning C4706: assignment
> within conditional expression
>

My answer is a mix bag :)

1. Code in contrib that is part of xHarbour (like wrappers), in separate
sources, should always be fixed.

2. Original 3rd party sources of live projects should not be modified,
instead it shoulld be reported to respective maintainers (like GitHub
issue). Or, creative fixes that do not modify ooriginal sources.

3. Code borrowed from dead, unmaintained projects should be fixed.

This is just my idea, I hope it makes sennse.

Ron

Enrico Maria Giordano wrote:
>
>
> Il 21/12/2023 11:28, Enrico Maria Giordano ha scritto:
>
> > There are still warnings for hbhpdf:
>
> Do I have suppress them using compiler switches like -wdxxx in my build
> batch? Let me know.
>

I would not supress so we don't hide things we do need to fix. I think
we should report it, and possibly suggest a pull request with proposed
fixes.

Ron

Il 21/12/2023 16:58, Ron Pinkas ha scritto:

> My answer is a mix bag :)
>
> 1. Code in contrib that is part of xHarbour (like wrappers), in separate
> sources, should always be fixed.
>
> 2. Original 3rd party sources of live projects should not be modified,
> instead it shoulld be reported to respective maintainers (like GitHub
> issue). Or, creative fixes that do not modify ooriginal sources.
>
> 3. Code borrowed from dead, unmaintained projects should be fixed.
>
> This is just my idea, I hope it makes sennse.

Yes, it makes perfect sense. Only one more question: how to recognize a
xHarbour contrib code? Is the presence of #include "hbapi.h" enough?

Please confirm.

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

Il 21/12/2023 17:01, Ron Pinkas ha scritto:

>>> There are still warnings for hbhpdf:
>>
>> Do I have suppress them using compiler switches like -wdxxx in my build
>> batch? Let me know.
>
> I would not supress so we don't hide things we do need to fix. I think
> we should report it, and possibly suggest a pull request with proposed
> fixes.

Don't look at me. :-)

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

Enrico Maria Giordano wrote:
>
>
> Il 20/12/2023 21:06, Ron Pinkas ha scritto:
>
> > 1. Some/Most BCC versions are not C99 compliant and thus produce error
> > on code like this:
> >
> > for (HPDF_UINT32 i = 0; i < prec; i++) {
> > fpart_val = modff(fpart_val*10.0, &int_val);
> > *s++ = (char)(int_val + 0.5) + '0';
> > }
> > C Compiler need to support declaration of variable in the loop
> > initialization.
> >
> > C99 also added modff()
> >
> > You told me that you use latest BCC and yet spoke about modff() missing
> > but this does not make sense since current standard math.h header must
> > have modff(). So we need to better review and understand BCC versions.
>
> If those are the requirements then we have no other choices than
> dropping support for bcc32.exe and forcing use of bcc32c.exe.

I do not beleive in forcing anything. :) I simply propose that we point
users to the multiple FREE compilers instead of trying to "fix" code
that is not broken, when such code is NOT ours, and its better for us
to not keep modifyinbg it when updating to newewr versions.

> But I
> don't think we have to do that. I just built xHarbour for BCC32 using
> bcc32.exe and found no errors and no warnings (using only -w-prc
> -w-use). So what's the problem?

Sure. We are not going to force anything, we can keep xHarbour code
compliant with even older compilers. It's only 3rd party code (in
conribs) that might not compile by all compilers. If we prefer to keep
using latest versions of 3rd party in contribs then we have to
understand that such code migh not support old compilers.

There is one mre choice that I much prefer:

- NOT bring 3rd part code that is available as librarries at all
User should simply install such library, and contrib will only
include the wrappers and builld script to link such libs. We already
have such appriach in place with some libs.

This is all just a balance game of comfor and preferences.

> > 2. Errors on incompatible pointers. This happens due to C++ compilation
> > and you can fix it by ssimply switching to C compilattion.
>
> Ok, I will keep it in mind for the future.

Cool.

Ron

Enrico Maria Giordano wrote:
>
>
> Il 21/12/2023 17:01, Ron Pinkas ha scritto:
>
> > > > There are still warnings for hbhpdf:
> > >
> > > Do I have suppress them using compiler switches like -wdxxx in my build
> > > batch? Let me know.
> >
> > I would not supress so we don't hide things we do need to fix. I think
> > we should report it, and possibly suggest a pull request with proposed
> > fixes.
>
> Don't look at me. :-)
>

This is all volunteer work, so no :), but since you already made the
fixes, I think you sure can make the contribution available as a pull
request proposal. You do deserve the credit.

Ron

Enrico Maria Giordano wrote:
>
>
> Il 21/12/2023 16:58, Ron Pinkas ha scritto:
>
> > My answer is a mix bag :)
> >
> > 1. Code in contrib that is part of xHarbour (like wrappers), in separate
> > sources, should always be fixed.
> >
> > 2. Original 3rd party sources of live projects should not be modified,
> > instead it shoulld be reported to respective maintainers (like GitHub
> > issue). Or, creative fixes that do not modify ooriginal sources.
> >
> > 3. Code borrowed from dead, unmaintained projects should be fixed.
> >
> > This is just my idea, I hope it makes sennse.
>
> Yes, it makes perfect sense. Only one more question: how to recognize a
> xHarbour contrib code? Is the presence of #include "hbapi.h" enough?
>
> Please confirm.
>

Yes in general this should be true. Sadly contribs have been maintained
in a loose manner and I suspect there are some "mix" sources. So I think
if someone care enough then reading the copyright and general review of
the code should make it clear. I would try to at least not ADD such mix
code. The best choice is to keep 3rd party sources separate and
unmodified.

Ron

Il 21/12/2023 17:28, Ron Pinkas ha scritto:

>> Don't look at me. :-)
>
> This is all volunteer work, so no :), but since you already made the
> fixes, I think you sure can make the contribution available as a pull
> request proposal. You do deserve the credit.

No, thanks. I'm not interested.

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

Il 21/12/2023 17:34, Ron Pinkas ha scritto:

>> Yes, it makes perfect sense. Only one more question: how to recognize a
>> xHarbour contrib code? Is the presence of #include "hbapi.h" enough?
>>
>> Please confirm.
>
> Yes in general this should be true. Sadly contribs have been maintained
> in a loose manner and I suspect there are some "mix" sources. So I think
> if someone care enough then reading the copyright and general review of
> the code should make it clear. I would try to at least not ADD such mix
> code. The best choice is to keep 3rd party sources separate and
> unmodified.

Ok, I will look carefully at the source code before fixing the warnings.

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

Il 21/12/2023 17:17, Ron Pinkas ha scritto:

>> I just built xHarbour for BCC32 using
>> bcc32.exe and found no errors and no warnings (using only -w-prc
>> -w-use). So what's the problem?
>
> Sure. We are not going to force anything, we can keep xHarbour code
> compliant with even older compilers. It's only 3rd party code (in
> conribs) that might not compile by all compilers. If we prefer to keep
> using latest versions of 3rd party in contribs then we have to
> understand that such code migh not support old compilers.

I do not understand. Why I'm not getting any errors building current
repository with BCC32? What am I missing? Is the modff() problem
vanished into thin air?

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

Enrico Maria Giordano wrote:
>
>
> Il 21/12/2023 17:17, Ron Pinkas ha scritto:
>
> > > I just built xHarbour for BCC32 using
> > > bcc32.exe and found no errors and no warnings (using only -w-prc
> > > -w-use). So what's the problem?
> >
> > Sure. We are not going to force anything, we can keep xHarbour code
> > compliant with even older compilers. It's only 3rd party code (in
> > conribs) that might not compile by all compilers. If we prefer to keep
> > using latest versions of 3rd party in contribs then we have to
> > understand that such code migh not support old compilers.
>
> I do not understand. Why I'm not getting any errors building current
> repository with BCC32? What am I missing? Is the modff() problem
> vanished into thin air?
>

I beleieve its because I made change to common.mak using a compile
command CC_CMD_HARU that was not yet implemented in makefile.bc so
it may have not compiled it at all. I just fixed to use CCC_CMD which
is defined in all compilers make files, and I am now testting.

Ron

Il 21/12/2023 23:18, Ron Pinkas ha scritto:

>> I do not understand. Why I'm not getting any errors building current
>> repository with BCC32? What am I missing? Is the modff() problem
>> vanished into thin air?
>
> I beleieve its because I made change to common.mak using a compile
> command CC_CMD_HARU that was not yet implemented in makefile.bc so
> it may have not compiled it at all. I just fixed to use CCC_CMD which
> is defined in all compilers make files, and I am now testting.

Ah, ok.

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg