[gdal-dev] stricmp in cpl_port.h

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] stricmp in cpl_port.h

Andrew C Aitchison-2

I have developed a gdal driver plugin on Linux and am now attempting to
build it on Windows.
I am using the conda gdal, WIN10 SDK and the mingw-m64 clang11 compiler
(all installed this week, latest versions I believe), but am open to
other suggestions for building a windows gdal driver plugin.

I get a deprecation warning from cpl_port.h when I use the EQUALS macro:
----------------------------------------------------------------------
qed.cpp:569:31: warning: 'stricmp' is deprecated: The POSIX name for this
item is deprecated. Instead, use the ISO C and
        C++ conformant name: _stricmp. See online help for details.
[-Wdeprecated-declarations]
      if( magic == qed_magic &&
EQUAL(CPLGetExtension(poOpenInfo->pszFilename),"qed")) {
                                ^
C:\ProgramData\Miniconda3\Library\include/cpl_port.h:576:36: note:
expanded from macro 'EQUAL'
#  define EQUAL(a,b)              (STRCASECMP(a,b)==0)
                                     ^
C:\ProgramData\Miniconda3\Library\include/cpl_port.h:565:38: note:
expanded from macro 'STRCASECMP'
#    define STRCASECMP(a,b)         (stricmp(a,b))
                                       ^
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt\string.h:544:20: note: 'stricmp' has
been explicitly
        marked deprecated here
      _Check_return_ _CRT_NONSTDC_DEPRECATE(_stricmp)
                     ^
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt\corecrt.h:414:50: note: expanded from
macro
        '_CRT_NONSTDC_DEPRECATE'
          #define _CRT_NONSTDC_DEPRECATE(_NewName) _CRT_DEPRECATE_TEXT(
\
                                                   ^
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include\vcruntime.h:310:47:
note:
        expanded from macro '_CRT_DEPRECATE_TEXT'
#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
                                                ^
1 warning generated.
-----------------------------------------------------------------------

Should cpl_port be updated to use _stricmp or is there a better
alternative (I wondered about strcasecmp but don't see it) ?

I see that
  frmts/mrsid_lidar/makefile.vc
sets
  EXTRAFLAGS = $(MRSID_INCLUDE) -D_CRT_SECURE_NO_WARNINGS /Zc:wchar_t-
but I would rather not turn off warnings, since my code is clean enough to
use  -Wall -Wextra -Weverything on linux.

Thanks.

--
Andrew C. Aitchison Kendal, UK
  [hidden email]
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: stricmp in cpl_port.h

andrew.bell.ia@gmail.com
Dare I suggest getting rid of EQUAL?

On Wed, Apr 7, 2021 at 10:25 AM Andrew C Aitchison <[hidden email]> wrote:

I have developed a gdal driver plugin on Linux and am now attempting to
build it on Windows.
I am using the conda gdal, WIN10 SDK and the mingw-m64 clang11 compiler
(all installed this week, latest versions I believe), but am open to
other suggestions for building a windows gdal driver plugin.

I get a deprecation warning from cpl_port.h when I use the EQUALS macro:
----------------------------------------------------------------------
qed.cpp:569:31: warning: 'stricmp' is deprecated: The POSIX name for this
item is deprecated. Instead, use the ISO C and
        C++ conformant name: _stricmp. See online help for details.
[-Wdeprecated-declarations]
      if( magic == qed_magic &&
EQUAL(CPLGetExtension(poOpenInfo->pszFilename),"qed")) {
                                ^
C:\ProgramData\Miniconda3\Library\include/cpl_port.h:576:36: note:
expanded from macro 'EQUAL'
#  define EQUAL(a,b)              (STRCASECMP(a,b)==0)
                                     ^
C:\ProgramData\Miniconda3\Library\include/cpl_port.h:565:38: note:
expanded from macro 'STRCASECMP'
#    define STRCASECMP(a,b)         (stricmp(a,b))
                                       ^
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt\string.h:544:20: note: 'stricmp' has
been explicitly
        marked deprecated here
      _Check_return_ _CRT_NONSTDC_DEPRECATE(_stricmp)
                     ^
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt\corecrt.h:414:50: note: expanded from
macro
        '_CRT_NONSTDC_DEPRECATE'
          #define _CRT_NONSTDC_DEPRECATE(_NewName) _CRT_DEPRECATE_TEXT(
\
                                                   ^
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include\vcruntime.h:310:47:
note:
        expanded from macro '_CRT_DEPRECATE_TEXT'
#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
                                                ^
1 warning generated.
-----------------------------------------------------------------------

Should cpl_port be updated to use _stricmp or is there a better
alternative (I wondered about strcasecmp but don't see it) ?

I see that
        frmts/mrsid_lidar/makefile.vc
sets
        EXTRAFLAGS = $(MRSID_INCLUDE) -D_CRT_SECURE_NO_WARNINGS /Zc:wchar_t-
but I would rather not turn off warnings, since my code is clean enough to
use  -Wall -Wextra -Weverything on linux.

Thanks.

--
Andrew C. Aitchison                                      Kendal, UK
                        [hidden email]
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
Andrew Bell
[hidden email]

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: stricmp in cpl_port.h

Andrew C Aitchison-2

On Wed, 7 Apr 2021, Andrew Bell wrote:

> Dare I suggest getting rid of EQUAL?

Since the purpose of EQUALS is to compare two strings, that would
be passing the buck. Without it developers would have to solve this
issue for each platform each time, making it more likely that someone
would break a platform that they don't use.


> On Wed, Apr 7, 2021 at 10:25 AM Andrew C Aitchison <[hidden email]>
> wrote:
>
>>
>> I have developed a gdal driver plugin on Linux and am now attempting to
>> build it on Windows.
>> I am using the conda gdal, WIN10 SDK and the mingw-m64 clang11 compiler
>> (all installed this week, latest versions I believe), but am open to
>> other suggestions for building a windows gdal driver plugin.
>>
>> I get a deprecation warning from cpl_port.h when I use the EQUALS macro:
>> ----------------------------------------------------------------------
>> qed.cpp:569:31: warning: 'stricmp' is deprecated: The POSIX name for this
>> item is deprecated. Instead, use the ISO C and
>>         C++ conformant name: _stricmp. See online help for details.
>> [-Wdeprecated-declarations]
>>       if( magic == qed_magic &&
>> EQUAL(CPLGetExtension(poOpenInfo->pszFilename),"qed")) {
>>                                 ^
>> C:\ProgramData\Miniconda3\Library\include/cpl_port.h:576:36: note:
>> expanded from macro 'EQUAL'
>> #  define EQUAL(a,b)              (STRCASECMP(a,b)==0)
>>                                      ^
>> C:\ProgramData\Miniconda3\Library\include/cpl_port.h:565:38: note:
>> expanded from macro 'STRCASECMP'
>> #    define STRCASECMP(a,b)         (stricmp(a,b))
>>                                        ^
>> C:\Program Files (x86)\Windows
>> Kits\10\Include\10.0.19041.0\ucrt\string.h:544:20: note: 'stricmp' has
>> been explicitly
>>         marked deprecated here
>>       _Check_return_ _CRT_NONSTDC_DEPRECATE(_stricmp)
>>                      ^
>> C:\Program Files (x86)\Windows
>> Kits\10\Include\10.0.19041.0\ucrt\corecrt.h:414:50: note: expanded from
>> macro
>>         '_CRT_NONSTDC_DEPRECATE'
>>           #define _CRT_NONSTDC_DEPRECATE(_NewName) _CRT_DEPRECATE_TEXT(
>> \
>>                                                    ^
>> C:\Program Files (x86)\Microsoft Visual
>> Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include\vcruntime.h:310:47:
>>
>> note:
>>         expanded from macro '_CRT_DEPRECATE_TEXT'
>> #define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
>>                                                 ^
>> 1 warning generated.
>> -----------------------------------------------------------------------
>>
>> Should cpl_port be updated to use _stricmp or is there a better
>> alternative (I wondered about strcasecmp but don't see it) ?
>>
>> I see that
>>         frmts/mrsid_lidar/makefile.vc
>> sets
>>         EXTRAFLAGS = $(MRSID_INCLUDE) -D_CRT_SECURE_NO_WARNINGS
>> /Zc:wchar_t-
>> but I would rather not turn off warnings, since my code is clean enough to
>> use  -Wall -Wextra -Weverything on linux.
>>
>> Thanks.
>>
>> --
>> Andrew C. Aitchison                                      Kendal, UK
>>                         [hidden email]
>> _______________________________________________
>> gdal-dev mailing list
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
> --
> Andrew Bell
> [hidden email]
>

--
Andrew C. Aitchison Kendal, UK
  [hidden email]
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: stricmp in cpl_port.h

Even Rouault-2
In reply to this post by Andrew C Aitchison-2
You're welcome to submit a pull request changing stricmp by _stricmp so
that we can check that our CI is happy with that. Given than we only
support MSVC >= 2015 nowadays, I'd expect this to run smoothly.

Le 07/04/2021 à 16:24, Andrew C Aitchison a écrit :

>
> I have developed a gdal driver plugin on Linux and am now attempting
> to build it on Windows.
> I am using the conda gdal, WIN10 SDK and the mingw-m64 clang11 compiler
> (all installed this week, latest versions I believe), but am open to
> other suggestions for building a windows gdal driver plugin.
>
> I get a deprecation warning from cpl_port.h when I use the EQUALS macro:
> ----------------------------------------------------------------------
> qed.cpp:569:31: warning: 'stricmp' is deprecated: The POSIX name for
> this item is deprecated. Instead, use the ISO C and
>        C++ conformant name: _stricmp. See online help for details.
> [-Wdeprecated-declarations]
>      if( magic == qed_magic &&
> EQUAL(CPLGetExtension(poOpenInfo->pszFilename),"qed")) {
>                                ^
> C:\ProgramData\Miniconda3\Library\include/cpl_port.h:576:36: note:
> expanded from macro 'EQUAL'
> #  define EQUAL(a,b)              (STRCASECMP(a,b)==0)
>                                     ^
> C:\ProgramData\Miniconda3\Library\include/cpl_port.h:565:38: note:
> expanded from macro 'STRCASECMP'
> #    define STRCASECMP(a,b)         (stricmp(a,b))
>                                       ^
> C:\Program Files (x86)\Windows
> Kits\10\Include\10.0.19041.0\ucrt\string.h:544:20: note: 'stricmp' has
> been explicitly
>        marked deprecated here
>      _Check_return_ _CRT_NONSTDC_DEPRECATE(_stricmp)
>                     ^
> C:\Program Files (x86)\Windows
> Kits\10\Include\10.0.19041.0\ucrt\corecrt.h:414:50: note: expanded
> from macro
>        '_CRT_NONSTDC_DEPRECATE'
>          #define _CRT_NONSTDC_DEPRECATE(_NewName) _CRT_DEPRECATE_TEXT( \
>                                                   ^
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include\vcruntime.h:310:47:
> note:
>        expanded from macro '_CRT_DEPRECATE_TEXT'
> #define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
>                                                ^
> 1 warning generated.
> -----------------------------------------------------------------------
>
> Should cpl_port be updated to use _stricmp or is there a better
> alternative (I wondered about strcasecmp but don't see it) ?
>
> I see that
>      frmts/mrsid_lidar/makefile.vc
> sets
>      EXTRAFLAGS = $(MRSID_INCLUDE) -D_CRT_SECURE_NO_WARNINGS /Zc:wchar_t-
> but I would rather not turn off warnings, since my code is clean
> enough to use  -Wall -Wextra -Weverything on linux.
>
> Thanks.
>
--
http://www.spatialys.com
My software is free, but my time generally not.

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: stricmp in cpl_port.h

andrew.bell.ia@gmail.com
In reply to this post by Andrew C Aitchison-2


On Wed, Apr 7, 2021, 11:48 AM Andrew C Aitchison <[hidden email]> wrote:

On Wed, 7 Apr 2021, Andrew Bell wrote:

> Dare I suggest getting rid of EQUAL?

Since the purpose of EQUALS is to compare two strings, that would
be passing the buck. Without it developers would have to solve this
issue for each platform each time, making it more likely that someone
would break a platform that they don't use.

You could write something generic that wouldn't need specialization for different architectures, eliminating this kind of problem. That's all I was meaning.


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Merging TIFF files creates offset / deformation

Hotmail
In reply to this post by Andrew C Aitchison-2
Hi,

I have a PNG library (524288 tiles of 256px * 256px) which I georeferenced via GDAL.

# This first part works correctly.
•  ullr:

> ulx = (360 * (column / 1024)) - 180
> uly = 90 - (180 * (line / 512))
> lrx = ulx + 0.3515625
> lry = uly - 0.3515625
> ULLR = ulx + '' + uly + '' + lrx + '' + lry

> gdal_translate -of VRT -a_srs EPSG:4326 -co NBITS=1 Path/Of/Input.png Path/Of/Output.vrt -a_ullr + ULLR
>
> gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -co NBITS=1 Path/Of/Input.vrt Path/Of/Output.tiff

# The second part works correctly too
I merge the tiles of a row (1024 TIFF tiles) using a VRT then from it I create the TIFF file

> #!/bin/bash
>
> for i in `seq 0 1 511`;
> do
>         gdalbuildvrt Path/Of/lines_vrt/map_$i.vrt Path/Of/tiff/map_11_*_$i.tiff
>         gdal_translate -co NBITS=1 Path/Of/lines_vrt/map_$i.vrt Path/Of/lines_tiff/map_$i.tiff
> done

Here if I use gdal_merge.py, either I get an invalid file (1.xMo while the lines are approx 60Mo) or I observe a offset / deformation ... (In QGIS)

# The last part doesn't work properly (and I don't know why ...)
Here I am merging all the lines (TIFF files) into a global TIFF file using the same method as before. (with a list.txt file)

> #!/bin/bash
>
> gdalbuildvrt -input_file_list Path/Of/lines_tiff/list.txt Path/Of/global_vrt/map_global.vrt
> gdal_translate -co NBITS=1 Path/Of/global_vrt/map_global.vrt Path/Of/map_global.tiff

and I observe a offset / deformation. (In QGIS again)

I wonder what am I doing that is wrong

My final goal is to use the global file (TIFF) with gdal2tiles.py (Tiles overlay on GMaps / OSM)

Thanks
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev