bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #50895] Change to size of NSComparisonResult breaks custom sort fro


From: David Lobron
Subject: [bug #50895] Change to size of NSComparisonResult breaks custom sort from 1.24.8 to 1.24.9
Date: Fri, 28 Apr 2017 16:10:05 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

URL:
  <http://savannah.gnu.org/bugs/?50895>

                 Summary: Change to size of NSComparisonResult breaks custom
sort from 1.24.8 to 1.24.9
                 Project: GNUstep
            Submitted by: dlobron
            Submitted on: Fri 28 Apr 2017 08:10:03 PM UTC
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

When we tried to migrate our company's software from gnustep-base-1.24.8 to
1.24.9, we found that custom sort routines built with the 1.24.9 headers
failed when we ran them with the 1.24.9 runtime.  The sort code was OK if
built with 1.24.9.  

We traced this to the fact that the enum type used for NSComparisonResult
changed from 4 bytes to 8.  We are building in 64-bit mode (-m64) on
GNU/Linux.  The exact point of failure is in GSTimSort.m, at line 350: it
compares the result of GSCompareUsingDescriptorOrComparator to the
NSOrderedAscending constant, and the comparison returns false when it should
return true, because it's expecting 8 bytes and the function is returning
2^^32 - 1 (set in the lower-order 4 bytes), which of course returns false when
compared with -1.

This means that code compiled against an previous version of gnustep will fail
to do custom sort routines when run in 1.24.9.  This seems like a larger ABI
change than we would expect from a minor version bump.  Was this intentional? 
If not, could we restore the old definition, at least pending more notice?

I've attached a program that reproduces the bug.  When built and run with
either 1.24.8 or 1.24.9, it sorts correctly:

2017-04-28 19:41:32.645 mincase[28527:28527] Sorted array contents:
2017-04-28 19:41:32.646 mincase[28527:28527] 0
2017-04-28 19:41:32.646 mincase[28527:28527] 1
2017-04-28 19:41:32.646 mincase[28527:28527] 2
2017-04-28 19:41:32.646 mincase[28527:28527] 5

but when built with 1.24.8 and run with 1.24.9, the sort fails:

2017-04-28 19:48:59.271 mincase[7338:7338] Sorted array contents:
2017-04-28 19:48:59.271 mincase[7338:7338] 0
2017-04-28 19:48:59.271 mincase[7338:7338] 1
2017-04-28 19:48:59.271 mincase[7338:7338] 5
2017-04-28 19:48:59.271 mincase[7338:7338] 2




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Fri 28 Apr 2017 08:10:03 PM UTC  Name: mincase.m  Size: 793B   By:
dlobron
Minimal reproducer
<http://savannah.gnu.org/bugs/download.php?file_id=40530>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?50895>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]