libs-base

gnustep/libs-base

Fork 0

mirror of https://github.com/gnustep/libs-base.git synced 2025-05-01 04:21:07 +00:00

Commit graph

Author	SHA1	Message	Date
theraven	a04ed1a9ff	Make base do unintuitive and stupid things in the name of Apple compatibility (hopefully Apple will fix their implementation in 10.7.something...). Fix some tests. git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@33687 72102866-910b-0410-8b05-ffd578937521	2011-08-03 09:04:12 +00:00
theraven	e23cad7454	On closer inspection, the runtimes / compilers were doing the right thing - the type encoding provided in Apple's documentation was wrong. git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@32945 72102866-910b-0410-8b05-ffd578937521	2011-04-29 11:11:37 +00:00
theraven	9b2b826548	Added test for property attribute encodings. These are based on the Apple documentation here: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtPropertyIntrospection.html Several of the things in the documentation are wrong: - The encoding of structures does not include the field names in property encodings. This encoding format appears to only be used in ivars (yes, it is frustrating) - Apple appears to encode long as q on LP64 platforms. This is probably a compiler bug. - The N flag is not set for non-atomic properties. This appears to be a clang bug, since the non-atomic flag is not set in the AST - both the Mac and GNUstep runtimes generate the same wrong result. git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@32944 72102866-910b-0410-8b05-ffd578937521	2011-04-29 10:50:00 +00:00

Author

SHA1

Message

Date

theraven

a04ed1a9ff

Make base do unintuitive and stupid things in the name of Apple compatibility (hopefully Apple will fix their implementation in 10.7.something...).

Fix some tests.



git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@33687 72102866-910b-0410-8b05-ffd578937521

2011-08-03 09:04:12 +00:00

theraven

e23cad7454

On closer inspection, the runtimes / compilers were doing the right thing - the type encoding provided in Apple's documentation was wrong.

git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@32945 72102866-910b-0410-8b05-ffd578937521

2011-04-29 11:11:37 +00:00

theraven

9b2b826548

Added test for property attribute encodings. These are based on the Apple documentation here:

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtPropertyIntrospection.html

Several of the things in the documentation are wrong:

- The encoding of structures does not include the field names in property
  encodings.  This encoding format appears to only be used in ivars (yes, it is
  frustrating)

- Apple appears to encode long as q on LP64 platforms.  This is probably a
  compiler bug.

- The N flag is not set for non-atomic properties.  This appears to be a clang
  bug, since the non-atomic flag is not set in the AST - both the Mac and
  GNUstep runtimes generate the same wrong result.



git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@32944 72102866-910b-0410-8b05-ffd578937521

2011-04-29 10:50:00 +00:00

3 commits