[bug #39088] Suppressing warnings in the GSWeb build

[Graham Lee]

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

Summary: Suppressing warnings in the GSWeb build
Project: GNUstep
Submitted by: leeg
Submitted on: Mon 27 May 2013 08:27:14 PM GMT
Category: gdl2
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

GSWeb is compiled with -Werror, and the changes in the attached patch are
required to make it build successfully on Apple with the clang compiler from
Xcode 4.6.2. There are also changes to various format strings required, these
were broken out into their own bug (#39087) to investigate whether I had
handled NSUInteger in a GNUstep-friendly way.



_______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 27 May 2013 08:27:14 PM GMT Name: gsw-build.patch Size: 4kB By:
leeg

<http://savannah.gnu.org/bugs/download.php?file_id=28189>

_______________________________________________________

Reply to this item at:

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

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

[Graham Lee]

Follow-up Comment #1, bug #39088 (project gnustep):

I should have said "fixing", not "suppressing" - I've addressed the problems
rather than silenced the compiler.

[Sebastian Reitenbach]

Follow-up Comment #2, bug #39088 (project gnustep):

I'm using clang 3.2 on OpenBSD, amd64.

Your patch fixes the warnings to GSWContext.m, and to GSWMultiKeyDictionary.m.
The other warnings you may see, and what you are fixing, I don't get, with and
without your patch.
But in general, the changes to GSWeb/GSWDeclarationParser.m look good to me.

I even see some more warnings than those you are fixing. Just for the records,
they are listed below.

Will discuss with David, and then go on

thanks,
Sebastian

GSWLongResponsePage.m:312:12: warning: assigning to 'WOElement *' from
incompatible type 'id<WOActionResults>'
GSWLongResponsePage.m:315:10: warning: returning 'WOElement *' from a function
with incompatible result type 'id<WOActionResults>'

GSWLogin.m:107:14: warning: instance method '-validateLogin' not found (return
type defaults to 'id') [-Wobjc-method-access]
GSWLogin.m:110:12: warning: instance method '-validateLoginUser:password:' not
found (return type defaults to 'id') [-Wobjc-method-access]

GSWSimpleFormComponent.m:121:10: warning: instance method
'-sendActionFromComponent:' not found (return type defaults to 'id')
[-Wobjc-method-access]
1 warning generated.
GSWCacheElement.m:333:27: warning: instance method '-startCache' not found
(return type defaults to 'id') [-Wobjc-method-access]
GSWCacheElement.m:333:26: warning: incompatible pointer to integer conversion
assigning to 'int' from 'id' [-Wint-conversion]
GSWCacheElement.m:349:39: warning: instance method '-stopCacheOfIndex:' not
found (return type defaults to 'id') [-Wobjc-method-access]

WODisplayGroup.m:2105:59: warning: incompatible pointer types sending 'NSArray
*' to parameter of type 'NSIndexSet *' [-Wincompatible-pointer-types]
WODisplayGroup.m:2275:17: warning: incomplete implementation
[-Wincomplete-implementation]

[Sebastian Reitenbach]

Update of bug #39088 (project gnustep):

Status: None => Need Info
Assigned to: None => buzzdee

_______________________________________________________

Follow-up Comment #3:

Hi Graham,

i applied all chunks of the patch, but one, where I think its wrong.

In the last hunk in your patch to -GSWeb/GSWMultiKeyDictionary.m, you cast
from a superclass to a subclass, which I think its not safe. AFAIK, casting is
only fiddling with pointers, but its not
really changing the type of class that you are casting. So if someone now
calls a method implemented in NSMutableArray, it will probably fail miserably.
Only when you are sure, nothing in the code will call methods from the
subclass, then it might be safe to cast from superclass to subclass. But in
the code I see some lines below in -nextObject, calling -removeLastObject on
the casted class, and I guess that would fail then.
I think casting is only safe the other way around, casting from a subclass to
a superclass.

Anyways, so instead of your cast:
ASSIGN(_objects,(NSMutableDictionary *)[_dictionary allValues]);

I'd better correctly initialize an mutable array:
_objects = [NSMutableArray arrayWithArray:[_dictionary allValues]];

But since memory management is still something I not fully grasped yet, it may
be I have to add a -retain to the line, or some autorelease or whatnot?

Attached my version of solving the problem. If somebody can tell me its OK, or
if I need a retain or something, then I'd go on commit that instead. Or if
someone tells me that my assumptions are totally wrong above, and your patch
is just right ;)

cheers

(file #28208)
_______________________________________________________

Additional Item Attachment:

File name: patch-GSWeb_GSWMultiKeyDictionary_m Size:0 KB

[Graham Lee]

Follow-up Comment #4, bug #39088 (project gnustep):

I, and the original author of that code, were relying on the fact that
-[GSWMultiKeyDictionary allValues] _does_ in fact return a mutable array
although its signature says it returns an array. I think you're correct though
and your patch is better: client code that wants the array to be mutable
should arrange that itself rather than relying on an implementation detail in
the dictionary class.

Cheers,
Graham.

[Sebastian Reitenbach]

Update of bug #39088 (project gnustep):

Status: Need Info => Fixed

_______________________________________________________

Follow-up Comment #5:

last patch applied to svn rev 36684.

thanks

[Sebastian Reitenbach]

Update of bug #39088 (project gnustep):

Open/Closed: Open => Closed