Opened 14 years ago

Closed 9 years ago

Last modified 9 years ago

#3801 closed defect (wontfix)

Some CPL conditions lead to dead code

Reported by: Mateusz Łoskot Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: svn-trunk
Severity: normal Keywords:
Cc:

Description

There are a few conditions in CPL which logically make no sense due to use of unsigned integer types. This conditions wrap code that will never execute, thus checking those conditions is unnecessary.

For instance, cpl_conv.cpp:120, cpl_conv.cpp:174, cpl_conv.cpp:2172. There may be more similar places I haven't found.

Change History (5)

comment:1 by Even Rouault, 14 years ago

This is interesting topic. I've made a few researchs and here are my findings :

  • C99 states that size_t must be unsigned
  • GCC before version 2.4 used sys/types.h that could be a signed type on some Unix systems

So we don't have problems with GCC since at least GCC 3.4.something is required for compiling C++ stuff.

So the question finally sums up as : are there non-gcc compilers able to compile GDAL that would still use sys/types.h on those Unix systems ? ... and if so, do we care about those exotic beasts ;-)

comment:2 by Mateusz Łoskot, 14 years ago

The problem with GCC 2.4 was that it mixed two worlds POSIX and GCC C. Here is full quote form the old GCC manual:

There is a potential problem with the size_t type and versions of GCC prior to release 2.4. ANSI C requires that size_t always be an unsigned type. For compatibility with existing systems' header files, GCC defines size_t in stddef.h' to be whatever type the system's sys/types.h' defines it to be. Most Unix systems that define size_t in `sys/types.h', define it to be a signed type. Some code in the library depends on size_t being an unsigned type, and will not work correctly if it is signed.

The GNU C library code which expects size_t to be unsigned is correct. The definition of size_t as a signed type is incorrect. Versions 2.4 and later of GCC always define size_t as an unsigned type, and GCC's fixincludes' script massages the system's sys/types.h' so as not to conflict with this.

A side note, GCC 2.4 was released in 1993. I don't really believe there are any users of GDAL 1.6+ using this compiler. Impossible.

Here is a decent analysis of size_t status and related issues: Using size_t may be awkward for some programmers, but using it still solves more problems than it creates, 2007

comment:3 by Jukka Rahkonen, 9 years ago

Even, does your comment mean that this ticket could be closed?

comment:4 by Even Rouault, 9 years ago

Resolution: wontfix
Status: newclosed

I wouldn't mind if someone removed the conditions in the code that might indeed by dead code on 99% of the systems on which GDAL can be compiled. But this ticket will probably remain as dead as the code before someone takes action... Closing as "wontfix (by me), if anyone wants to deal with it, fine for me"

comment:5 by Mateusz Łoskot, 9 years ago

Apart from discussion the comments above, I actually postponed it expecting Even or Frank to decide what to do, to patch or to close as wontfix.

Note: See TracTickets for help on using tickets.