[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bugs #10950] GSFormat with %C, regression between 1.3.2 and 1.10.0
From: |
Adam Fedor |
Subject: |
[bugs #10950] GSFormat with %C, regression between 1.3.2 and 1.10.0 |
Date: |
Thu, 02 Dec 2004 22:33:30 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.11 |
This mail is an automated notification from the bugs tracker
of the project: GNUstep.
/**************************************************************************/
[bugs #10950] Latest Modifications:
Changes by:
Adam Fedor <fedor@gnu.org>
'Date:
Fri 12/03/2004 at 03:20 (US/Mountain)
What | Removed | Added
---------------------------------------------------------------------------
Assigned to | None | fedor
Status | Open | Analyzed
------------------ Additional Follow-up Comments ----------------------------
It appears that on MingW, wint_t is a short, which is technically allowed.
However, it would be promoted to int in va_args. This patch fixes the problem:
Index: Source/GSFormat.m
===================================================================
RCS file: /cvsroot/gnustep/gnustep/core/base/Source/GSFormat.m,v
retrieving revision 1.32
diff -u -r1.32 GSFormat.m
--- Source/GSFormat.m 1 Nov 2004 08:25:04 -0000 1.32
+++ Source/GSFormat.m 3 Dec 2004 03:15:51 -0000
@@ -993,7 +993,7 @@
break
T (PA_CHAR, pa_char, int); /* Promoted. */
- T (PA_WCHAR, pa_wchar, wint_t);
+ T (PA_WCHAR, pa_wchar, int); /* Sometimes promoted. */
T (PA_INT|PA_FLAG_SHORT, pa_short_int, int); /* Promoted. */
T (PA_INT, pa_int, int);
T (PA_INT|PA_FLAG_LONG, pa_long_int, long int);
Although I wonder if I should be more robust and check to see if wint_t could
possibly be larger than an int. I'm also not sure why it worked before, but
doesn't work now. Perhaps a change in MingW?
/**************************************************************************/
[bugs #10950] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10950>
Project: GNUstep
Submitted by: 0
On: Tue 11/09/2004 at 10:24
Category: Base/Foundation
Severity: 5 - Average
Item Group: Change Request
Resolution: None
Privacy: Public
Assigned to: fedor
Status: Analyzed
Summary: GSFormat with %C, regression between 1.3.2 and 1.10.0
Original Submission: Hi all,
GSFormat causes a crash when used with format "%C".
This is something that used to work with GNUstep 1.3.2 and crashes with GNUstep
1.10.0 using MinGW. It works on OSX.
Using this code (appends an unichar 'A' to a mutable string):
On Mac OS X:
cougar:/tmp fred$ cat AppendUnichar.m
#import <Foundation/Foundation.h>
int main()
{
NSAutoreleasePool *thePool = [[NSAutoreleasePool alloc] init];
NSMutableString *theString = [NSMutableString string];
[theString appendFormat:@"%C", (unichar)0x41];
NSLog( @"[%@]", theString );
[thePool release];
return 0;
}
cougar:/tmp fred$ cc -o AppendUnichar -framework Cocoa AppendUnichar.m
cougar:/tmp fred$ ./AppendUnichar
2004-10-26 18:37:35.982 AppendUnichar[766] [A]
cougar:/tmp fred$
On GNUstep 1.3.2 on mingw, with gcc 3.2:
fred@FLEA /c/tmp/AppendUnichar
$ shared_obj/ix86/mingw32/gnu-gnu-gnu/AppendUnichar.exe
2004-10-26 18:44:03.988 AppendUnichar.exe[2020] [A]
fred@FLEA /c/tmp/AppendUnichar
On GNUstep 1.10.0:
AppendUnichar.e caused an Access Violation at location 6de58669 in
module gnustep-base_d.dll Reading from location ffffffff.
Registers:
eax=0022e7e0 ebx=00000000 ecx=0022e7e0 edx=00000002 esi=00000108
edi=0022e060
eip=6de58669 esp=0022e7d0 ebp=0022f718 iopl=0 nv up ei pl zr na
po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00000246
Call stack:
6DE58669 gnustep-base_d.dll:6DE58669 GSFormat GSFormat.m:985
...
T (PA_CHAR, pa_char, int); /* Promoted. */
> T (PA_WCHAR, pa_wchar, wint_t);
T (PA_INT|PA_FLAG_SHORT, pa_short_int, int); /* Promoted. */
T (PA_INT, pa_int, int);
...
6DE69D71 gnustep-base_d.dll:6DE69D71 _i_GSMutableString__appendFormat_
GSString.m:2803
...
#endif
}
> GSFormat((GSStr)self, fmt, ap, nil);
_flags.hash = 0;// Invalidate the hash for this string.
if (fmt != buf)
...
004013AE AppendUnichar.exe:004013AE main AppendUnichar.m:8
...
NSMutableString *theString = [NSMutableString string];
> [theString appendFormat:@"%C", (unichar)0x41];
NSLog( @"[%@]", theString );
...
0040122D AppendUnichar.exe:0040122D
00401258 AppendUnichar.exe:00401258
7C581AF6 KERNEL32.dll:7C581AF6 GetVolumeInformationA
Of course, there are plenty of workarounds, but I definitely don't understand
what is going on there in GSFormat.m
Thanks for all the great work you all do on GNUstep,
--andre
Follow-up Comments
------------------
-------------------------------------------------------
Date: Fri 12/03/2004 at 03:19 By: Adam Fedor <fedor>
It appears that on MingW, wint_t is a short, which is technically allowed.
However, it would be promoted to int in va_args. This patch fixes the problem:
Index: Source/GSFormat.m
===================================================================
RCS file: /cvsroot/gnustep/gnustep/core/base/Source/GSFormat.m,v
retrieving revision 1.32
diff -u -r1.32 GSFormat.m
--- Source/GSFormat.m 1 Nov 2004 08:25:04 -0000 1.32
+++ Source/GSFormat.m 3 Dec 2004 03:15:51 -0000
@@ -993,7 +993,7 @@
break
T (PA_CHAR, pa_char, int); /* Promoted. */
- T (PA_WCHAR, pa_wchar, wint_t);
+ T (PA_WCHAR, pa_wchar, int); /* Sometimes promoted. */
T (PA_INT|PA_FLAG_SHORT, pa_short_int, int); /* Promoted. */
T (PA_INT, pa_int, int);
T (PA_INT|PA_FLAG_LONG, pa_long_int, long int);
Although I wonder if I should be more robust and check to see if wint_t could
possibly be larger than an int. I'm also not sure why it worked before, but
doesn't work now. Perhaps a change in MingW?
-------------------------------------------------------
Date: Tue 11/23/2004 at 00:03 By: Fred Kiefer <FredKiefer>
Corrected Category.
-------------------------------------------------------
Date: Tue 11/09/2004 at 10:48 By: 0 <None>
wrong group. how do i change this to 'base'?
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=10950>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [bugs #10950] GSFormat with %C, regression between 1.3.2 and 1.10.0,
Adam Fedor <=